(MODAClouds) CloudFoundry

Important

This document is part of the MODAClouds deliverable D6.1, thus superseded by it.

Important

This document was created in March 2013, thus its contents might be currently outdated.

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

type PaaS
suitability emerging
application domain web applications
application architecture 2-tier applications (but see the notes)
application restrictions container
programming languages Java, Ruby, NodeJS [CloudFoundry-3]
programming frameworks popular frameworks (Spring, Java Servlets, Rails), plus standalone
scalability manual
session affinity sticky-sessions [CloudFoundry-1]
interaction CLI, WS, API
disponibility hosted, simulated, deployable open-source
portability out-of-the-box
services MySQL, PostgreSQL, MongoDB, Redis, RabbitMQ [CloudFoundry-2]
monitoring coverage basic
monitoring level container
multi-tenancy multiple organizations, single organization
resource sharing n:1
providers VMWare (private solution)

Limitations

OS resources (per instance):

memory 2 GiB [CloudFoundry-1]
disk 2 GiB [CloudFoundry-1]
descriptors 256 [CloudFoundry-1]
CPU's 4 [CloudFoundry-1]

Network connections:

inbound HTTP exclusively
outbound allowed (with exceptions) [CloudFoundry-1]
internal unspecified

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.

[1]There are already commercial providers that leverage Cloud Foundry, like AppFog: How We Built AppFog Using Cloud Foundry.
[2]Actually the limit is even lower, because opened files or database connections do count as file descriptors.

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

[CloudFoundry-1](1, 2, 3, 4, 5, 6, 7) Cloud Foundry -- FAQ
[CloudFoundry-2]Cloud Foundry -- Services
[CloudFoundry-3]Cloud Foundry -- Frameworks
[CloudFoundry-4]Micro Cloud Foundry