Differentiators. Heroku's key differentiator is its maturity. It has been publicly available for a number of years, and it enjoys a large marketplace of plug-ins. The company said more than 2.35 million apps are running live on the platform today. It noted that its official support for nine languages, and its many more community contributed languages and frameworks, differentiate Heroku from other PaaS offerings.
Lock-in. Heroku describes its PaaS as a 100 percent open platform that offers a native developer experience for both IDE-centric and command-line centric developers. In response to the lock-in question, the company said that code written to run on Heroku around modern best practices can easily run on any other standards-based platform, in-house or in the cloud.
Indeed the risks of lock-in do not seem more significant than with other PaaS offerings. We were able to deploy the Granny application without significant changes. However, it would be interesting to see how easy or difficult it is to dump data from a PostgreSQL or MySQL instance on Heroku.
Security. Heroku publicly lists its security compliance, noting mainly that it sits on Amazon Web Services infrastructure and Amazon is compliant with ISO 27001, SOC 1/SSAE 16/ISAE 3402, PCI Level 1, FISMA Moderate, and Sarbanes-Oxley (SOX). PCI compliance is provided by offloading credit card processing to a compliant third-party service.
Who's using it? Heroku said that it sees adoption from small startups through the largest enterprise customers in the world. It lists a good number of reference accounts, including social and Facebook apps, digital media sites, corporate marketing sites, city government sites, and more. In addition to those listed on the website, the company pointed to "exciting adoption" by Macy's, which is building Java apps on Heroku.
How did it do? Heroku was easier to work with than OpenShift but harder than CloudBees or Cloud Foundry. The documentation was fairly straightforward. In addition to uploading your WAR file, you have to log into your account and set up your database, then return to Eclipse to complete the process. This swapping between the Web GUI and Eclipse makes Heroku a less attractive option than Cloud Foundry. Heroku lacks the polish of some of the other offerings despite its maturity.
Conclusions. Heroku is a "safe" choice because it's well established, with a growing marketplace of add-on services. It isn't the easiest or hardest to work with. For a Ruby app, it might be our first choice. Our initial test was less positive, but after Heroku released improvements to the Java platform on Sept. 19, deploying Granny proved much more seamless. Heroku wouldn't be our first choice for a legacy application, but it's not bad at all.
Windows Azure is Microsoft's take on Amazon Web Services, encompassing both IaaS and PaaS offerings. In addition to .Net language support, there are SDKs for Java, Python, PHP, and Node.js.
Differentiators. First off, this is Microsoft -- your .Net apps can come here too. Further, Microsoft points out that Azure supports almost any developer language that's popular today, and more are being added. Unlike most competitors, which are AWS underneath, Azure runs on Microsoft's own cloud. Additionally, Azure is available for production today with publicly available pricing.
We don't consider Azure to be a true PaaS because the Azure tools actually deployed our entire Tomcat instance. On one hand, this is one way of answering the lock-in question. On the other hand, the whole idea behind choosing a PaaS is to be freed from having to manage your own application server.
Lock-in. According to Microsoft, making use of a PaaS solution means writing to a set of runtime libraries designed for that specific PaaS. This has excellent effects on scale, agility to write, and performance but requires custom work to move to another PaaS. The company notes that data migration is a simpler proposition because there are many ETL patterns supported by Windows Azure and other PaaS platforms.
In other words, we'd be careful to test elsewhere. Interoperability has never been a strong point for Microsoft, which focuses more on ease of entry. Then again, Microsoft does not have a history of price gouging its customers even when they're locked in. For software-freedom-loving open source guys like us, that's a hard admission, but for the most part we think that it is true.
Security. Microsoft has extensive documentation on Windows Azure's security certifications and procedures. These include ISO 2700, SSAE 16 ISAE 3402, EU Model Clauses, and HIPAA BAA. Frankly, this is how you get big government and corporate contracts, so we would expect no less. Microsoft goes above and beyond the certifications by not only penetration testing its product but offering penetration testing to its customers with seven days advanced notice.
Who's using it? Microsoft claims many thousands of Azure customers, from students to single-developer shops to Fortune 500 companies. It also notes that some legacy apps can pose a problem -- for example, an extremely stateful application with a frozen or nonmaintained code base that would preclude the architectural changes necessary to support the PaaS frameworks and its scalable tiers, availability sets, queuing across instances, and so on.
Microsoft sent us a number of published case studies. At the moment, these are mainly schools and municipalities. They don't appear to be specific to Azure either, let alone its PaaS offering. Additional case studies are available on the Azure site, but we're using Google Chrome on Ubuntu 12.04 and the site requires Silverlight.
How did it do? Microsoft called very shortly after we signed up and offered assistance. This is great customer service and honestly belongs among the differentiators. In this era of retail Internet service, "Can I help you?" can sway a decision.
Deploying Granny to Azure showed plenty of rough edges. Azure's Eclipse plug-in didn't work; in fact, it directed us to an EXE file, which obviously wasn't going to work on Linux. The Linux SDK also did not work. On Windows, deploying the application on Azure was only partially PaaS-like. Instructions for deploying the example "Hello, world" Web application include pointing the setup wizard to the local copy of your favorite application server and JDK. The app server is then merely copied to a Windows Server 2008 VM. After that, you can fairly easily have your application use Azure's SQL Server instance.
Conclusion. If you have legacy apps not based on .Net, then Azure probably won't be your first choice. However, with that hands-on approach to both customer service and security, Microsoft could go a long way.
We honestly expected a bit more from the Linux SDK and the Eclipse plug-in. Despite the talk of interoperability and all of the tweeting from OpenAtMicrosoft, Microsoft didn't shine here. Certainly, Microsoft has the wrong messaging on PaaS lock-in for our taste. That said, if you have a mixed infrastructure of .Net, Java, Ruby, Python, and PHP and can do some tweaking but prefer not to rewrite, Azure may be the best choice.
Red Hat OpenShift
Differentiators. OpenShift runs Java applications on the JBoss Enterprise Application Platform (JBoss EAP), Red Hat's commercial distribution of JBoss. Red Hat considers Java Enterprise Edition 6 (Java EE 6) to be a compelling differentiator, along with allowing developers to choose the best tool for the job, whether it's Java EE 6, Ruby, Python, PHP, Node.js, Perl, or even a custom language runtime.
In the coming months, Red Hat will be launching the first commercial, paid, supported tier of the OpenShift service. Red Hat said it will also release an on-premises version for enterprises that can't run in the public cloud due to security, governance, and compliance restrictions.
Lock-in. "No lock-in" was one of the foundational principles used in the design and development of OpenShift, according to Red Hat. The company noted that OpenShift uses no proprietary APIs, languages, data stores, infrastructure, or databases, but is built with pure vanilla open source language runtimes and frameworks. This means, for example, that an application built with Python and MySQL on OpenShift will seamlessly port to Python and MySQL running on a stand-alone server or in another cloud (assuming the language versions are the same). Likewise, a JBoss Java EE 6 application running on OpenShift can be moved to any JBoss server.
Security. Red Hat publicly lists OpenShift's security compliance information. The company said that Red Hat's Security Response Team (the same team that continuously monitors Linux for vulnerabilities) is involved with the design and implementation of OpenShift and that the OpenShift OnLine PaaS service is continuously patched and updated by the OpenShift Operations team at the instruction of the Security team. Red Hat also noted that OpenShift runs SELinux, the security subsystem originally developed by the NSA.
Who's using it? Red Hat said a wide cross-section of companies are using OpenShift today, ranging from hobbyist developers to technology startups building their businesses in the cloud to systems integrators and service providers to Fortune 500 enterprises. The company noted that classic legacy applications that are running on mainframes or other legacy platforms are not great candidates for migration to a PaaS.
Because OpenShift is considered a "developer preview" -- Red Hat's term for beta or alpha -- the company didn't feel comfortable releasing any information about existing deployments.
How did it do? It was a lot more work than we expected to get Granny deployed to OpenShift. Swapping between the command-line deployment tool and the Web-based provisioning and management console lacked the user-friendliness of CloudBees or Cloud Foundry. The Red Hat Developer Studio plug-ins didn't work with our application out of the box. Ultimately, we had to edit a lot more descriptor files both inside and outside of the application than we did with other solutions.
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
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 CloudFoundry.com, 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.
Who's using it? Cloud Foundry is well positioned to meet the needs of companies that want a combination of public and private PaaS. Its focus on an ecosystem of Cloud Foundry providers is a strong point, especially with regards to lock-in. Cloud Foundry is clearly aimed at Ruby, Node.js, and JVM-based languages. If you have a more diverse technology base, this may not be your first choice.
VMware pointed me to several published case studies, including Intel, Diebold, AppFog, Cloud Fuji, and others.