Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Tim Cull on Dec 06, 2010
This week, Red Hat announced it acquired Makara, a cloud based, platform as a service (PaaS) company. Makara is unusual among PaaS providers in that it doesn't have any infrastructure of its own. Instead, it operates as a virtual layer on top of other cloud providers and exposes a simplified set of tools for deployment, scaling and monitoring. Think of it as an itinerant PaaS, or as a tightly integrated and publicly hosted set of cloud management tools that serve as a cloud facade.
Red Hat states that its motivation with the purchase is: "By integrating the JBoss Enterprise Middleware infrastructure with Makara's Cloud Application Platform, Red Hat can offer a more comprehensive PaaS solution that allows organizations to quickly transition their applications to both public and private clouds with minimal modifications."
In theory, any development shop could implement a Makara-like management portal using tools like JClouds (which Makara appears to use itself), but one advantage with using Makara is that the company has already made many decisions for developers ahead of time with an eye towards auto-scaling and management.
Deploying a JBoss application on Makara involves giving it cloud credentials (i.e. your Amazon EC2 access key and secret key), telling it what size cluster to deploy the application into, uploading the contents of the application's JBoss deploy folder, and adding database tables. Once done, Makara will monitor log files and scale up or down accordingly.
Sifting through the marketing-heavy web site makes figuring out what, exactly, Makara does and does not do difficult, especially for those not willing to sign up for a trial account. So, InfoQ signed up for a Makara trial account and discovered that, among other things, it distinguishes itself from other PaaS providers with:
In spite of all of the above, Makara offers auto-scaling and monitoring for applications deployed on their clusters. In the background, their service monitors the application and automatically scales it up or down to accommodate load. Developers can use default scaling strategies or specify their own based on things like average CPU load or the number of requests per second hitting each server.
There are some unexpected aspects to Makara, however. First, since Makara effectively outsources the infrastructure part of a developer's application to other cloud providers then developers have to provide Makara private access keys even though Amazon says "for your protection, you should never share you secret access keys with anyone" right on the AWS account page. And, billing is done through the underlying cloud provider, not through Makara. Lastly, presumably there are ways to use the ssh access and root MySQL access Makara gives developers that break the monitoring, log aggregation and auto-scaling value that Makara adds.
Makara also supports deploying non-JBoss applications like those written in PHP. However, Red Hat owns JBoss and the press release never mentioned PHP, leaving PHP's future under Red Hat unknown.
The WebSphere Liberty Profile for Developers: An Introduction
Early Access! Download JBoss Developer Studio 5.0 now, with packages for Mac, Windows or Linux!
Banking Case Study: Scaling with Low Latency using NewSQL
Combining Inspections, Static Analysis, Testing to Achieve >95% Defect Removal Efficiency
Introducing SQLFire: a memory-optimized, high performance SQL database
VMware vFabric SQLFire - Test drive the data management system with memory speed, horizontal scalability and a familiar SQL interface
Thanks for the thoughtful writeup, Tim! As I explained in a blog post last week, we are very excited about Red Hat's cloud vision as well as our role in that vision and the open source community in general.
Just one correction: while I agree in theory with your claim that anyone could ("in theory") implement such a platform, there is actually considerably more going on under the hood than just "jClouds" or related tools. Most of our tooling--from log aggregation to clustering and performance monitoring happens right at the application level, not the infrastructure level. Which is why we can e.g. report on time spent in the app server vs backend calls, broken down by transaction class etc. So it's a bit more involved than your description suggests to me.
We are currently focusing on the on-demand version of the product. However, the platform is very much designed with deployments behind the firewall in mind. Witness e.g. us managing cloud credentials, which, while perfectly safe in the on-demand version, feels very natural in a private cloud scenario.
On the PHP front, we will continue to support PHP and are very much interested in supporting other languages as well.
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Andrew Watson talks about the work of the OMG, where CORBA is alive and well (hint: in your car), UML and UML Profiles vs. custom Modeling languages, DDS and other middleware, and much more.
Sohil Shah discusses creating iPhone and Android enterprise mobile applications based on cloud services using the open source platform OpenMobster.
Paul Sanford presents the transformations supported by data throughout its life cycle, and how that can be better done with Splunk, an engine for monitoring and analyzing machine-generated data.
A common “best practice” for unit tests is to only write a one assertion in each test. I intend to question this advice by showing that multiple assertions per test are both necessary and beneficial.
John Rauser presents the architectural and technological evolution of Amazon retail websites starting with 1994 and ending with adopting Amazon Web Services.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
1 comment
Watch Thread Reply