Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Which freaking PaaS should I use?

Andrew C. Oliver and Lifford Pinto | Oct. 10, 2012
Most of the buzz around the cloud has centered on infrastructure as a service (IaaS). However, IaaS is no longer good enough. Sure, you can forgo buying servers and run everything virtually on Amazon's EC2 server farm. So what? You still have to manage it, and to do that you'll have a growing IT bureaucracy. Companies that want to focus on writing their code and not have to think about application servers at all are now looking to platform as a service (PaaS).

Had we deployed a Java EE-compliant app, I'm sure OpenShift would have been friendlier. But when the command-line tool told me to run a command, then warned me that the command was deprecated, it left a bad taste in my mouth. This is truly a "developer preview" and rough around the edges.

Conclusions. If you're already developing JBoss applications, OpenShift may be a good fit. It's worth a preview now, but if you're looking to deploy to a PaaS today, it's not ready. Red Hat should continue to trumpet the Java EE compliance as a differentiating factor. However, even by 2006 when Andrew worked at JBoss, he noticed that most applications deployed in JBoss were written to the Spring Framework. Supporting Red Hat's existing customer base is all well and good, but greatness and business success will come from seamless deployment of applications developed by people who are not already in the Red Hat camp.

VMware Cloud Foundry

VMware bought SpringSource in 2009. Therefore, it isn't surprising that our "legacy" application, which was already based on the Spring Framework, worked seamlessly on Cloud Foundry. Although Cloud Foundry is still beta, it was very polished and worked well.

Differentiators. A key differentiator is the native support of the Spring framework. According to VMware, Cloud Foundry was built in collaboration with the SpringSource engineering team to ensure a seamless development, deployment, and management experience for Java developers. VMware also noted that Cloud Foundry is "unique in its multicloud approach," allowing developers to deploy the same application, without code or architectural changes, to multiple infrastructures both public and private. In fact this isn't unique, as OpenShift is similar, but VMware is uniquely positioned to do it. Unlike CloudBees, Heroku, and Red Hat, VMware has built its own cloud rather than building on Amazon Web Services.

Lock-in. VMware addressed the question of lock-in to my satisfaction. Because the platform is open source and there's a broad ecosystem of compatible providers (examples include, Micro Cloud Foundry, AppFog, and Tier3), developers can easily move applications between Cloud Foundry instances, both on public clouds or private infrastructures. VMware noted that in addition to the multicloud flexibility, this open source flexibility ensures that developers and customers aren't locked into one cloud or one platform. As proof, the company pointed me to a blog post on extracting data using the Cloud Foundry data tunneling service, which is far and above "You can dump it to CSV and port it yourself."

Security. We were unable to find any published documentation on security certifications (PCI, SAE, and so on) for Cloud Foundry. VMware pointed me to its User Authentication and Authorization service, which appears to be a single sign-on scheme based on OAuth2. This could be a helpful service for application developers, but government organizations and large companies are going to require VMware to provide documentation of security certs before migrating to its cloud.


Previous Page  1  2  3  4  5  6  7  8  9  10  Next Page 

Sign up for Computerworld eNewsletters.