For over a year now, a large number of industry experts have been asking questions like “is PaaS becoming just a feature of IaaS?,” “is PaaS dying?,” “do you really need a PaaS?,” and “is PaaS dead?” This has raised great deal of passionate debate in Twitter-land and other social media outlets, although supporters of stand-alone PaaS solutions are mostly those who are employed by vendors of those solutions. Most people and companies believe in the value of Platforms as a Service. I wrote about my belief that PaaS is a game changer earlier last year. A blog post titled PaaS winners and losers, so far, might surprise you, by Nancy Gohring, discusses some interesting numbers from a recent report from Gartner, which tells a troubling story for many of the PaaS vendors delivering development Platforms as a Service. According to Gohring:

“…where the Gartner report gets more interesting is among the vendors with fewer customers. That’s because some of them are very big names. For instance, Gartner wrote that IBM’s SCAS offering is estimated to have fewer than 50 customers worldwide. SAP, Gartner said, has fewer than 100 customers. Red Hat, which is front and center talking about its OpenShift offering, has ‘few paying customers,’ according to Gartner.”

Newer entrants to the market are in some cases doing better than their giant, established brethren. CloudControl, a German company serving the European market, says it has 400 paying customers. Docker has 500 paying customers. If I do some simple math, I am shocked to discover that Docker, which officially launched only this past summer, already has more paying customers than the combination of Red Hat, IBM, and SAP PaaS platforms combined. The interesting thing to me is that most people, I believe, have a better understanding of what the value of PaaS is than even know what Docker and containers are. So why are companies so slow to embrace standalone PaaS solutions? I have some theories:

  1. Confusing marketing message
  2. Lack of maturity
  3. Limitations.

Let’s discuss each one of these in more detail.

Confusing Marketing Message

Recently, I gave a presentation based on a previous article, The Many Faces of PaaS. I described a number of different PaaS options (see image below) and the pros and cons of each. Based on the questions I received, not only from this webinar, but also in my day to day encounters, it is obvious that there is still a great deal of confusion about what PaaS really is. There are public PaaS providers like Heroku, Google, and Microsoft; there are private and hybrid PaaS solutions like Apprenda, OpenShift, Pivotal, WSO2, and many others; and then there are domain-specific PaaS solutions that focus on very distinct areas like mobile, big data, social, etc.

paas-manyfaces

Click to expand

IaaS providers are offering many PaaS-like services, such as AWS’s Elastic Beanstack and others. To make things more confusing, both Google and Microsoft now have IaaS offerings along with their PaaS offerings. Not a day goes by when I don’t see people trying to compare Microsoft Azure, a PaaS, to AWS, an IaaS solution. To make matters worse, even “experts” can’t get it right. Look at Clouds360.com’s list of Top 20 PaaS Vendors; it includes AWS and OpenStack, two IaaS solutions, and even RightScale, a cloud management solution. Then, there is the whole public vs. private PaaS discussion. The original goal of PaaS was to provide an abstraction layer over the infrastructure and the cloud stack (operating system, application server, database server, and programming language) so that IT could focus on writing code and get away from managing and patching the stack and the infrastructure. Well, many companies still shy away from putting various workloads in a public cloud, so they have turned to private PaaS providers. Now all of the sudden, they are back in the infrastructure and cloud stack management business. Even worse, they now also have to manage a PaaS solution as well. Many are finding that the effort and complexity required to provide their developers an abstracted development layer is much more involved than their vendor’s pretty PowerPoint slides said it would be.

Lack of Maturity

Many public PaaS solutions have been around for while, like Heroku, Engine Yard, Google, and others, but their traction in large enterprises is not overwhelming yet. The private PaaS solutions are much newer and have many fewer customers, although they are starting to penetrate the enterprise market. The challenge for PaaS is that both SaaS and IaaS are already enterprise-worthy in the eyes of many customers, and they much more trusted within the enterprise (or at least AWS is). PaaS is where AWS was back in 2008, when most consumption was coming from startups and SMBs. There are some impressive enterprise success stories, but not in large numbers.

Limitations

The other day, I attended a meetup where the presenter was discussing Heroku lessons learned. I was amazed to learn how many work-arounds are required to get some of these Platforms as a Service to scale and provide high availability. There is a perception that you simply jump on these PaaS solutions and start cranking out code. That may be true, but if you want code that works, you must have a deep understanding of PaaS limitations and architect around them. For example, Heroku has dynos, which you can think of as virtual containers holding all of your infrastructure and your stack. Heroku randomly recycles dynos when it feels that it is appropriate to do so, and it gives you a whole ten seconds to deal with the error code. This is one of many nuances within the platform that are required to keep the platform stable and scalable for all of its tenants. Well, all of a sudden, your code starts to get very specific to the target PaaS platform, creating a form of lock-in that you probably were not expecting. PaaS platforms make sense for some workloads but not all of them. There are very few examples of applications deployed on PaaS that have reached massive scale. Yes, there are some, and I am sure I will get nastygrams on this comment, but at what cost? The amount of work required to work around the limitations of most PaaS architectures and the costs of consuming so many abstracted resources often makes it difficult, too expensive, and sometimes even impossible. At most times, extremely high-volume applications are better served on an IaaS solution for which resources are not throttled like they are on a PaaS. With private PaaS, I can argue that you can’t truly autoscale. Sure, the PaaS can increase and decrease resource consumption, but you still have to procure enough physical hardware on-premises to meet the demand. To me, that is not really autoscaling.

Is PaaS Dying or Dead?

In my opinion, it is not. It is simply not as mature as SaaS and IaaS, and it is going through the same growing pains that those two service models did. The problem with PaaS is that it is still too complex and not clearly understood by the masses of potential paying customers. However, I wonder what the future for standalone PaaS vendors is. The numbers from Gartner paint a bleak picture for some of them. Enterprises are embracing IaaS and SaaS at record levels, and the fears of the public cloud from a security standpoint are gradually easing. IaaS providers are adding increasingly more PaaS-like services to their portfolio each day. Are we blurring the line between PaaS and IaaS layers? As consumers of cloud services, do we really care or want to get PaaS and IaaS services from different vendors? Only time will tell.

Summary

PaaS has the potential to be a game changer. Unfortunately, the masses have not yet embraced PaaS, due to market confusion, lack of maturity, and limitations of the PaaS architectures. Customers want to spend less time mucking around with infrastructure and application stacks, and will flock to PaaS solutions once they become easier to use and are acceptable target endpoints for more enterprise workloads. PaaS is not dead: in fact, it is just in its infancy, waiting to take the market by storm. The problem is that in its current form it is not quite what many enterprises are willing to put their chips on yet.

Share this Article:

Share Button
Mike Kavis (41 Posts)

Mike is a VP/Principal Architect for Cloud Technology Partners. Mike has served in numerous technical roles such as CTO, Chief Architect, and VP positions with over 25 years of experience in software development and architecture. A pioneer in cloud computing, Mike led a team that built the world's first high speed transaction network in Amazon's public cloud and won the 2010 AWS Global Startup Challenge. An expert in cloud security, Mike is currently writing a book for Wiley Publishing called "Architecting the Cloud: Design Decisions for Cloud Computing Service Models (IaaS, PaaS, SaaS)" which is expected to be released in late 2013.

Connect with Mike Kavis:


Related Posts:

6 comments for “The War on PaaS

  1. January 21, 2014 at 11:44 AM

    I think your assessment is largely correct, in that PaaS is currently just not a mature space at this point. What I hope, is that PaaS vendors focus on application lifecycle management, and allow the IaaS providers (projects) to support their needs with modular services. Frankly, if an IaaS cloud can provide database services, why should the PaaS layer spend time on that requirement? PaaS should be about service composition (or even container composition, if their customers want that), with easy to use hooks into underlying services like DB’s, Cache, etc…

  2. January 21, 2014 at 12:57 PM

    Not all PaaS vendors started out with that vision and some even attempted to be the cloud service provider of choice by completely hiding the IaaS services underneath. The reality is that consumers are thinking about things in the opposite fashion. The IaaS providers are the main source of cloud services and they are looking for PaaS solutions to complement their IaaS solutions. I think PaaS providers with a vision similar to what you laid out in your comments are the ones that will thrive in the long run. Thanks for your comment.

Leave a Reply

Your email address will not be published. Required fields are marked *


+ seven = 15