If I look at these numbers, my first question is: what do we actually mean with PaaS? The specific definitions vary a lot and the growing popularity of PaaS also comes with some PaaS-washing (vendors putting the PaaS moniker on their existing technology in an attempt to eat part of the market). In my opinion the popular SPI-model of the cloud landscape, which divides it into Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS), is simplifying reality way too much. A couple of months back I proposed a more sophisticated framework to categorize the cloud landscape. In my humble opinion it helps a lot in categorizing and comparing the different offerings in the market. I will use it in this article to structure the discussion around competitive cloud stacks based on OpenStack and Cloud Foundry.

The new OpenStack Havana release sends strong signals to the industry that Platform-as-a-Service (PaaS) vendors may suddenly have “irrelevant” stamped on their backs. No matter how elaborate or venerable your existing business may be, proving your value inside the rapidly expanding OpenStack ecosystem is no easy task. This time it is the established PaaS vendors like Cloud Foundry and OpenShift who are feeling the heat. A fun guessing game is naming the established players who are next in the stack to get crushed.

Alex compares the innovation curve of OpenStack with what AWS has gone through. AWS started with a focus on low-level infrastructure services, but quickly pushed up the stack by offering PaaS-level services. I don’t want to sound like a broken record, but what does “PaaS-level services” mean? Before we dissect what OpenStack and AWS actually offer (spoiler: it’s not PaaS), let’s first have a look at the response by the “PaaS community” to this controversial post.

How the PaaS community reacted

If the Alex’ goal was to start a fire, he succeeded. The blowback on his post was huge, especially from the Cloud Foundry community. The main debate circled around the statement of Alex that his customers prefer “a combination of Heat for orchestration, Trove for the database, LBaaS for elasticity, then glu[ing] it all together with scripts and Python code” over PaaS implementations like Cloud Foundry. However, as Jesse Proudman duly noted, the leading contributors in OpenStack all have (or invest in) complementary PaaS implementations. RedHat has OpenShift, and IBM, HP (via ActiveState), SAP, and NTT all support Cloud Foundry. So, it seems unlikely that the OpenStack community will invest a lot in “PaaS-level” services.

In addition to that, the whole idea of PaaS is that you completely abstract the underlying infrastructure. So, a bit more automation/orchestration is not the same as PaaS. PaaS is application-centric, rather than infrastructure-centric and aims to eliminate all system administration tasks for its target user, the developer. The differences between IaaS and the different flavors of PaaS are clearly explained in my overview of the cloud landscape.

In summary: there is a bit more involved in a PaaS than what the average 3-sentence definition suggests.

Solum, another PaaS initiative from the OpenStack community

But, it gets even more interesting. During the debate around Alex’ blog post, another OpenStack project was announced: Solum. To be clear: there is no relation at all with the blog post of Alex, just unfortunate timing, I guess. This project aims to ease the pain associated with:

Application development and deployment

Application lifecycle management across dev, test and production environments

Portability between public and private clouds

And yes, this sounds exactly as another attempt to move OpenStack towards higher-level services (and more clearly as the situation described before, if you ask me). I think the same argument as before applies here: why would the leading OpenStack contributors invest in such a project, while they are already investing in separate PaaS open source projects (OpenShift, Cloud Foundry)?

It all depends on the direction and implementation of course. Proponents state that Solum could utilize some services in OpenStack (Heat, Nova’s Docker driver, etc.), build on top of that and provide PaaS players with an API to ease the interaction with the infrastructure (why this is necessary is beyond me, as open source PaaS implementations are already covering this space and I don’t see clear differentiators). Another way of looking at it is that, as far as I know, Solum is not part of OpenStack, it is just related and therefor offers a choice for vendors that want to run a PaaS on top of OpenStack. Either way, it doesn’t bring clarity, as the firestorm of reactions over the last months clearly shows.

The importance of focus and the value of ecosystems

This whole controversy leads to questions about the focus of the OpenStack community. In my opinion, there is enough ground to cover on the IaaS layer. OpenStack-based providers do not play a big role yet in the IaaS market (only IBM is showing some significant revenue, but most of that is not from their OpenStack offering, but from software and related services as well as SoftLayer – which is not OpenStack unless you install it yourself on the bare metal offering). Proprietary offerings from Amazon (AWS), Microsoft (Azure), and Google (Compute) are leading the charge. Google was late to the party, but they are showing how to do it: focus on the problem that you want to solve with a true R&D approach. Google Compute isn’t trying to copy AWS, they analyzed the weak points of AWS and improved on that. Here are 10 examples of things that Google Compute does better (purely from an IaaS perspective).

Another aspect related to this is the value of ecosystems. By adding PaaS-level functionality to OpenStack a certain part of the community seems to suggest that OpenStack wants to do it all. If there is one thing that kills an ecosystem, it is chasing away partners that add value to a platform (and thereby bring customers on the platform) – and this is exactly what OpenStack did via the article of Alex by declaring war on Cloud Foundry and OpenShift. OpenStack in itself doesn’t bring business value. Only if it is part of a business solution it brings value. There are mainly two ways towards this “business value”: adding higher-level services or having partners that build on top of the platform. To me it seems that there is neither agreement nor clear choice in the OpenStack community on the path to choose. That’s not entirely a surprise, though.

Moving from IaaS and PaaS towards a clearly defined cloud landscape

It starts with a lack of clarity on what IaaS and PaaS actually are. In this way the debate can go on for ages, and it will, because there is a large grey area in between. We need to clearly identify the elements of the entire cloud stack and only then we can have a proper discussion about the focus of OpenStack, Cloud Foundry, OpenShift, and the likes.

Image 1: a categorization of the cloud landscape that shows how complementary the core elements of OpenStack (blue) and Cloud Foundry (green) are.

Image 1 shows a categorization of the cloud landscape that I introduced and explained in this article. The image clearly shows how complementary the core elements of OpenStack and Cloud Foundry actually are. By using two dimensions to describe the landscape and a distinction between “foundational PaaS” and aPaaS, the discussions around functionality in OpenStack vs PaaS-players like Cloud Foundry can get much more specific which hopefully leads to the much needed clarity in the community.

OpenStack and the road to business value

Let me offer my two cents about what path the OpenStack community (and thus vendors having an OpenStack based offering) should pursue. First, the OpenStack community should focus on all three elements of IaaS (or: the software-defined datacenter): compute, networking, and storage. They should do it extremely well and raise the bar (as argued above, OpenStack is behind at the moment).

Second, PaaS implementations on top of OpenStack (amongst others, PaaS should be cross-IaaS) should be welcomed and supported. OpenStack has a clear advantage here due to its openness. There are good examples like Ubuntu that brings a Cloud Foundry-based PaaS to OpenStack implementations. In addition to the aPaaS offerings that are often referred to when people talk about PaaS, partnerships that could bring services like dbPaaS, iPaaS, and baPaaS should be actively pursued.

Third, vendors and enterprise that want to make their OpenStack offering a success need to think about who their buyer is. Lydia Leong clearly explained that traditional IT operations folks are not the buyers of IaaS. IaaS providers, or better said AWS, created a new market and a new buyer. To quote Lydia “the vast majority of the dollars spent on cloud IaaS are much more heavily influenced by developer desires than by IT operations concerns — and that means that market share currently favors the providers who appeal to development organizations”.

I would want to take that one step further. If you look at who is actually deciding to go to the cloud it is the business itself in most cases. Due to the nature of cloud services, budgets are swinging towards recurring operating expenses and thus a new economic buyer: the business unit. Tired with the lack of speed and agility in their IT departments they decide to build apps themselves, empowered by modern cloud-based application development platforms. In 2009 Gartner predicted that by 2014 25% of new business applications would be written by people outside the IT department. These people are often called “citizen developers” (but I like to include professional developers that are working in the business unit here). These numbers might not have come true entirely, but fact is that a vast number of applications are built by business-level developers (which is not entirely “new” as the popularity of tools like Microsoft Access and Sharepoint within business units suggest).

So, the question for OpenStack providers is: how will you get to the buyer? How to make sure developers and citizen developers start to build and deploy applications on your platform? Or, in other words, how are you going to bridge the gap between layer 1 and 6 (see image 1)?

It is not only key to win the hearts and minds of the developer (you deploy where you build), but to add additional differentiating layers of service (e.g. Mendix aPaaS for rapid cloud app development) on top of what is quickly becoming a commodity. My prediction: the next battle will be the one to win the hearts of the business engineers and citizen developers.

4 Comments Added

Loved this article. It’s thoughtful commentary on what is happening publicly. I also think you should give some consideration to Apache Stratos. It’s reaching a mature phase, has a number of real enterprise customers who adopt it, and mature corporate backers. This is a legtimate offering, too.

Insightful! Business has been taken development to out-source and off-shore developers, to SaaS, to and IaaS. If IaaS is GREAT enabling business taking greater and more direct control, then PaaS will be a PERFECT.

PS – The diagram not only help clarify the different but also look like a food chain pyramid for IT career LOL. Loving it!

Search

Search for:

About

I'm Johan den Haan, CTO at Mendix. I am interested in model driven software development (MDE, MDD, DSL), cloud, PaaS, social, agile, and team leadership. This blog is personal, all opinions are mine and should be taken with a pinch of salt.