Red Hat Acquires PaaS Cloud Provider Makara
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:
- Ability to move between cloud providers like Amazon EC2 and vCloud. Though at the moment only EC2 is supported by the "on demand" edition and vCloud is only available for private clouds, so that portability is partially just a theory.
- An integrated suite of performance monitoring tools that include historical performance metrics
- Log aggregation similar to what Splunk offers
- A file browser, including an embedded version-differ to see what changed between releases on a file-by-file basis
- Surprising access to expert configurations, including Apache rewrite rules, arbitrary JVM parameters and every JBoss configuration file
- ssh access to cluster machines
- Root access to MySQL
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.
More than jClouds
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.