(MODAClouds) CloudFoundry

Overview

At a high level Cloud Foundry can be seen as a younger brother of Heroku, both part of the classical PaaS family. Similar with the previous solution, Cloud Foundry allows the developer to run almost unchanged any conventional application --- one that uses the most common frameworks and respects the common best practices --- also providing support for the most common resources (such as relational databases).

Two important highlights of Cloud Foundry are the fact that its source code is released under an open-source license, and that there is a Micro CloudFoundry [CloudFoundry-4] solution that enables the developer to have a local deployment and testing environment that simulates the hosted platform.

Because Cloud Foundry is at the same time both a hosted PaaS (by VMWare), and an open-source product, in this survey we focus especially on the hosted platform, because many of these limitations and constraints depend solely on the choices made by the hosting provider; meanwhile the open-source variant allows anyone that wants to deploy it, to add support for new programming languages, services or raise limitations.

Unfortunately unlike Heroku it is not production ready yet, allowing only limited resources to the applications, providing a very small set of additional resources or services, and constraining the supported programming languages and frameworks.

However, compared with Heroku and other PaaS's, in what regards the possible application architectures and the HTTP routing layer, it promise to offer more flexibility.

Characteristics

Limitations

OS resources (per instance):

Network connections:

Notes

Much that can be said about Cloud Foundry was already written in the overview section above, and could be summarized as:

• it could be considered as an alternative to Heroku; [1]
• its major advantage over the other PaaS's is its open-source license;
• there is a solution that offers the developer a simulator of the hosted platform;
• overall it is a promising solution, but currently in beta status;

Regarding the support of programming languages and supported frameworks, it is more strict than Heroku: only the available ones can be used, and there isn't an option to customize the build and packaging process (without the developers intervention).

The limitations are clearly described, and on par with Heroku. Unfortunately, due to its current beta status, it can't host any real world application, because all the applications (or an application's instances) summed total memory cant be over 2 GiB [CloudFoundry-1], and there doesn't seem to be support for domain names others than *.cloudfoundry.com. Moreover, the limitation on file descriptors of 256 could be worrying, because it implies that each instance can't have more than 256 [2] concurrent HTTP requests, which for real-time web-applications (such as using web-sockets) would be a show-stopper.

Although the deployed applications must fit the 2-tier model (i.e. monolithic process and database or middleware layer), CloudFoundry has a unique feature that allows different applications to share the same services or resources, thus allowing the user to obtain a n-tier model by splitting his application in multiple ones when deploying to CloudFoundry.

ModaClouds integration

(Again we stress the fact that the following statements apply mainly to the hosted solution (by VMWare), because in a self-deployed Cloud Foundry environment the operator has many other choices.)

From ModaClouds' perspective, CloudFoundry currently has less to offer than Heroku, as it has the following major disadvantages, especially when thinking about how to run the additional support services that ModaClouds require:

• it is backed by VMWare's IaaS solution (presumably VMWare vSphere), but in a private cloud; this implies that we won't be able to provision any VM's for our support services, that would be able to interact with the running application --- not without latency and costs;
• currently the supported services and resources is a very small set, and there isn't any (practical and cost effective) way to add other;
• the limitation imposed on the applications --- the total amount of memory used by the entire application is only 2 GiB --- makes it difficult for any real world application to be run;
• because we are limited to a hand full of programming languages, if we would like to deploy the support services as other applications, it imposes large restrictions on what we are able to effectively use;

On the positive side it does offer some advantages, although marginal compared with the drawbacks:

• it does provide basic monitoring information (memory, CPU, disk) at instance level;
• it allows the user to upgrade the application without interrupting the service --- through manipulation of the HTTP routes, and only if the old and new versions of the application are capable of handling it;

But all in all we could still manage to use it as a run-time platform for the applications, provided that we host the support services in another provider, not without performance degradation or cost increases.

References