Over the last few months, we have identified a trend towards “diversity” in the PaaS provider marketplace. Platform as a Service has become Platforms as a Service, the providers are offering multiple choices at each layer of the platform infrastructure, and seeing their role as automating the provisioning of properly configured instances as required at each layer of the stack.
On Aug 2nd, there was another entrant to this “diverse” PaaS provider marketplace called Cumulogic, a startup with a PaaS cloud positioned alongside Red Hat OpenShift and VMware CloudFoundry that we identified earlier.
We have identified five facets to this diversity
- Diversity of programming language – Java and its derivatives, Ruby, PHP,Python etc. also .NET
- Diversity of infrastructure – typically PaaS are built on one or more underlying IaaS infrastructures, although they may also be self-contained.
- Private vs Public vs Hybrid deployment models
- Diversity of application platform: Application Server, Database etc
- The ability to extend the platform with application platform components that are not provided by the PaaS provider
Diverse PaaS requires significant investment on the part of providers to ensure all of the various components interoperate and all the current PaaS clouds are “work in progress”. Indeed, the endpoint for PaaS may end up close to the endpoint of another trend we have identified, IT as a Service, which is addressing similar problems from the Enterprise side.
The requirement for diversity comes from the fact that organizations will have built applications using different platforms that they wish to deploy to the platform, or will have skill-sets which are best matched to certain application platform components. It makes the choice of PaaS provider much more independent of the choice of PaaS. It is also important to enterprises to avoid lock-in and to allow second-sourcing of PaaS clouds.
Cumulogic does very well in terms of the five facets of diversity we outline above.
Programming language diversity
Cumulogic’s current weak spot is in the diversity of language coverage. Being populated with ex-Oracle ex-Sun people, it is focused on Java – at the moment only Java and other Java-derived languages are supported. If, however, you are working with a Java application, the level of diversity in the other layers exceeds that of the other players, and Java Support should allow me to deploy my Groovy application which I have been porting around the various IaaS providers, so I hop to bring practical experience to a future blog post.
Diversity of infrastructure
One key area of diversity is the IaaS layer. Cumulogic may be deployed to Amazon, (and a Eucalyptus -based private cloud which emulates Amazon), Cloud.com or vSphere with plans to support OpenStack . OpenShift Flex does offer diversity of IaaS layer, but the only option is currently Amazon. This is in contrast to CloudFoundry where the IaaS layer is vSphere.
Private/Public
Cumulogic offer either private or public cloud versions. Presumably hybrid is possible but they don’t explicitly mention it.
Application platform diversity
Cumulogic has good support for various application platform components required for Java applications: CumuLogic supports Apache and Nginx web servers, Red Hat JBoss and IBM WebSphere containers, and MySQL and DB2 databases. The various diverse PaaS cloud providers all have different priorities and roll-out schedules for components. Cumulogic is at least as diverse as the other players at the application platform layer, with comparatively good support for IBM platform technologies (which isn’t a priority for either Red Hat or VMware).
Platform Extensibility
This is one area where Cumulogic has moved ahead of its rivals, in the ability to package and configure components so that they are deployed and managed by the platform. Most of the other PaaS plays have taken the view that they can focus on specific components, and that there will be enough customers who want only those components, and that they needn’t allow customers to extend the platform with their own server-side components. Indeed, one can argue that a pure-play PaaS is characterized by the customer’s inability to go in behind the scenes, install some server-side component and thereby break the platform. As indicated in my previous post on OpenShift experience, there is no root access to the IaaS layer. This contrasts with an Amazon Elastic Beanstalk approach where you get the platform, plus the ability to go in and do whatever you like to your Amazon images behind the scenes.
Neither approach is, however, entirely satisfying. You really want to configure the Platform to deploy the components you require in a well-defined way, that doesn’t require you to go into the IaaS layer. Cumulogic offers this facility through an extensible application catalog where you can define your own components.