Should you pass on PaaS?

It’s funny to watch all the predictions on how fast different parts of the cloud market will grow – but also how some analysts “adjust” their forecast from 30+ CAGR to meager single low digits within just a few months or go from multi-ten billion market sizes to just a couple of billions. All these adjustments reveal one key thing: there’s a large degree of uncertainty with regards to how fast the cloud market will grow (no one really question the enormous growth potential) and where the focus will really be within a couple of years.

No other area reflects this better than Platform as a Service (PaaS). Once it has been touted as the main source of growth; nowadays it’s more a necessary add on for successful IaaS providers. 451 research recently released a research note highlighting the movements in the market and how PaaS solutions are really used – that is, which got acquired by whom. So, should anyone care about PaaS? Or should we just pass on it?

It’s always good to remind ourselves what PaaS really is. Essentially, any self-respecting PaaS solution offers three types of services: application life cycle management, application run time environments and services (which, in most cases, can be extended by other, user defined services). Typically life cycle management includes staging, termination, scaling (auto-scaling), policy based SLA enforcement – just what you would expect from any serious cloud management solution. On the run-time environment side you will find support for Ruby, JavaScript, Java, Python and the likes. As for services, security, database, messaging are typically present in most solutions.

Before answering the question, let me make an attempt to lay out a few ground truths and principles around PaaS:

1. Just as for programming languages, don’t expect a PaaS standard anytime soon. It may be sparser or thicker, but still a jungle it will be and portability will be a pain
2. Services will be used on a “need to have” as well portability basis. An LDAP based security service is a safe bet. An esoteric say messaging service less so.
3.¬†If your app works with one PaaS, it’s not guaranteed that it will work with another one. Staging, policy enforcement, service usage will differ – it may start, but may fail miserably along the road
4. Be sure you use an application framework that is widely supported: node.js, JVM based ones, Ruby, Python are good. Other, not so much.
5. PaaS will not replace a cloud management solution, it adds an extra layer to be managed

So, should you just pass on PaaS and stay with IaaS and whatever application framework you use?

The answer is yes and no. Yes, you should pass on the dream of a “universal PaaS” that would allow you to run your application on “any” cloud and get the same services. This will simply not happen – cloud providers will work towards making sure to provide you with a PaaS layer, but a PaaS layer that is tailored for their particular cloud infrastructure. AWS has one, VMWare (for their private cloud) have another one (Cloud Foundry), for RedHat based clouds you have OpenShift. Moving these around and getting the same level of service is hard, if not impossible.

The answer is also No. No, it’s not a good idea to pass on PaaS. It does provide a platform that insulates the application from some complex¬†aspects of cloud (VM management, scale-out/in, fault management) and allows the programmer to focus on the task at hand – if you are developing a new application. Given the tendency of cloud providers to offer a bundled PaaS solution, the real question to answer is the same old one: which cloud is right for you? Public or private? VMWare based or Linux/KVM/OpenStack or CloudStack based or Azure based? Redhat or some other distro? Once you answered those questions, you implicitly made the choice of PaaS too – in fact, it may be one of the decision criteria.

Just don’t expect “seamless” portability and interoperability. Go for performance, low cost or ease of migrating your legacy – whichever is more important for you.

Comments are closed.