OpenStack and its PaaS strategy: a deeper look under the covers

Clearly my original OpenStack Havana blog has hit a nerve. My dramatic tone galvanized the PaaS community and several people vehemently disagreed with many of the points I made.

Thankfully the next day several publications picked up the controversy and raised the real question: as IaaS technologies mature and move up the stack into the PaaS layer, how will this affect the existing PaaS landscape? Barb Darrow at GigaOM covered the issue particularly well in her article, OpenStack: is it a PaaS killer? The week in cloud. And Jesse Proudman from BlueBox posted one of the better articles on the controversy. He suggested that OpenStack and Cloud Foundry are meant to live happily with one other.

PaaS is relevant. Cloud Foundry is solid. I’m sorry!

While I am happy that the subject I raised has gotten that much attention, I want to get move away from the heat of the arguments and focus on the real topic at hand. Some readers have grossly misinterpreted my original blog as an attack on the relevancy of PaaS and, specifically, Cloud Foundry. I may have not used the right wording to express my points and want to apologize to anyone who was offended by it.

For the record, neither I nor Mirantis have anything negative to say about PaaS in general and Cloud Foundry in particular. On the contrary, I contend that it is because of their very success with application developers that makes the IaaS community so interested in PaaS.

…but OpenStack IS moving into PaaS. Sorry.

Let us take a look under the hood of what is happening inside OpenStack in the area of application enablement and orchestration?

Let us start with Heat, one of the most active areas in development in OpenStack and the project that our production customers find especially interesting. Heat is the main project in the OpenStack Orchestration initiative whose mission is to “create a human- and machine-accessible service for managing the entire lifecycle of infrastructure and applications within OpenStack clouds.” As we can read just a few lines below, project Heat implements the “orchestration engine to launch multiple composite cloud applications based on templates” and further “Heat also endeavors to provide compatibility with the AWS CloudFormation template format”.  Here is an example of the Heat/Software blueprint that takes Heat’s orchestration even further.

This looks to me like a serious movement in the direction of PaaS, including the interoperability component.

History shows that PaaS vendors should pay attention

Companies that control parts of the stack tend to fight for expanding their control. These fights typically start with the incumbent asserting their control over the foundational elements of the stack and then moving up. The story of Microsoft’s ascension in the 80s and 90s is a great illustration of that point. Starting with the control of the operating system on the IBM PC platform, Microsoft swiftly moved to woo the application developers by taking over the development tools space that integrated to its OS better and ahead of its competitors. Along the way they took out very good and popular players like Borland who at the time possessed a much stronger and certainly more popular set of development tools (anyone here old enough to remember Turbo C/C++ and the almost religious following it had from the developer community – the author of this blog included) but who could not compete on the OS integration. And since the apps that people developed had to run well on MS-DOS and MS Windows, that integration was essential for application developers and application owners alike.

Does this story sound familiar?

While a long way from Microsoft yet, OpenStack is no exception to this rule. After all, as Jesse Proudman has correctly contended, many of the companies behind it are technology vendors (like IBM, HP and Red Hat) who know very well the value of controlling the complete stack. And if we were to agree with what Peder Ulander (@ulander) wrote in his tweet to me, “the further down you are in this model, the less relevant you are,” the OpenStack movement has no choice but to make a serious effort to get closer to application developers and owners.

PaaS vendors are discounting the threat

Despite all this evidence, a number of PaaS developers pointed out that the PaaS functionality in Havana with the IaaS community is minimal and cannot possibly be compared to the innovation occurring in the PaaS community.

While these pundits may be right about the facts as of today, I think they are missing the more important point. I agree that OpenStack’s PaaS functionality is nowhere near that offered by the mature PaaS products. Yet. But focusing on customers who love Cloud Foundry and who are buying it is old news.

Where we should be focusing is on those potential customers who love it and do not buy it.

I shared the story about some of our customers evaluating Cloud Foundry and deciding to stick with the minimal functionality built into to OpenStack for their application development needs. It may be a fluke, but it also maybe the start of the real competitive trend that should be acknowledged and perhaps addressed early?

My point is that it is a threat. And the evidence of it is not the current functionality that one can find in OpenStack Havana but the direction where the development is heading and the players who are taking it there.

A day or two ago we witnessed the announcement of a new OpenStack project called Solum, backed by RedHat, Rackspace, eBay, dotCloud and Cumulogic. The backers describe it as “an OpenStack Related Project designed to make cloud services easier to consume and integrate into your application development process." Solum is natively designed for OpenStack clouds and leverages numerous OpenStack projects, including Heat, Keystone, Nova, Trove, and more.”

Now, we can argue how much of this mission has already been implemented, but it is clear that this mission is very similar to the mission of any commercial PaaS, including the interoperability aspect of it, and that it is native to OpenStack and is tightly integrated with other OpenStack infrastructure projects.

The Solum announcement created its own significant stir in Twitter. Even @cloudpundit (aka Lydia Leong from Gartner) said that Solum is going to directly compete with Cloud Foundry on OpenStack.

Don’t discount it: Join it! Own it!

With that, let me return to the point that Jesse Proudman makes: that vendors who have a vested interest in PaaS solutions like CloudFoudry and OpenShift will not move to cannibalize themselves by means of OpenStack.

The data we see points to the contrary. Despite its massive investment in OpenShift, Red Hat is leading the effort of accelerating OpenStack moving into a full-fledged PaaS, as evidenced by the Heat and Solum projects.

Red Hat is an open source veteran that understands the market trends well, and I suggest that others should learn from its example. I want to point your attention to what Red Hat is doing with OpenShift, the position that is eloquently explained by one of the OpenShift developers in his blog –http://mattoncloud.org/.

“While we can run OpenShift very well on OpenStack and are even enabling better integration through projects like Heat and Neutron, we’ve had the feeling that there is a more fundamental set of capabilities in our platform today that could be native to OpenStack itself.  And in doing that, we could drastically improve the operational experience.”

The takeaway, I believe, is that rather than discounting the OpenStack movement up the stack, the open source PaaS providers should engage with the OpenStack community and see how they can join in. If you cannot prevent the revolution – join it!