Reflections on the PaaS Marketplace

Cairn from the Canadian Arctic Expedition

Entering the PaaS marketplace in 2010 resembled a polar expedition near the turn of the last century. Lots of preparation and fundraising required, not a lot of information about what you’d encounter on the journey, life-and-death decision making along the way, shifting and difficult terrain in unpredictable conditions and intense competition for the prize. At least we didn’t have to eat the dogs.

In case you missed it, CloudBees announced that we’ll no longer offer our runtime PaaS, RUN@cloud. Instead, we’re focusing on our growing Jenkins Enterprise by CloudBees subscription business - on-prem, in the cloud, and connecting the two - and the continuous delivery space where Jenkins plays such a key role. Jenkins has been at the core of our PaaS offering all the way along, so in some ways, this is less of a pivot than a re-focusing. Still, it’s an important event for CloudBees customers, many of whom rely on our runtime services and the integrated dev-to-deployment model we offer. We’ll continue to support those customers on RUN@cloud for an extended period and help them transition as painlessly as possible to alternatives (read our FAQ about the RUN@cloud news). Given our open PaaS approach and the range of offerings in the marketplace, the transition will be non-trivial, but manageable (read our transition documentation). Given that background, I wanted to share some thoughts behind our move and what we see going on in the PaaS marketplace.
 

A Platform, Of Sorts By Agrant141 [CC-BY-SA-3.0]

As a team, we come from a platform background. To us, cloud changes the equation in how people build, deploy and manage applications. So, the platforms we’re all used to building on top of - like Java - need to change scope and style to be effective. That idea has driven a lot of what we delivered at CloudBees. It’s why Jenkins was such a big part of the offering, because from our perspective Continuous Integration and Continuous Delivery really needed to be integral to the experience when you’re delivering as-a-service with elastic resources, on-demand. I think we have been proven right. Doubts? Take a look at what Google is doing with the Google Cloud Platform . They agree with us and they built their solution around Jenkins. This is also why primarily runtime-deployment-focused PaaS offerings like Pivotal’s Cloud Foundry partner with us on Jenkins.

What’s changed, then?

• Service - IaaS platform affinity . IaaS providers, but particularly AWS and Google, are moving up-stack rapidly, fleshing out a wider and wider array of very capable services. These services often come with rich APIs that are part of the IaaS-provider’s platform. Google Cloud Services is a good example. If you’re an Android developer, it’s your go-to toolbox to unlock location and notification services. It also incentivizes you to use Google identity and runtime GAE services. The same is true on AWS and Azure with some different slants and degrees of lock-in. Expect the same on any public cloud offering that aims to succeed longer term. This upstack march by the IaaS vendors blurs the line on PaaS value. PaaS vendors like CloudBees can make it easy to consume these IaaS-native services, but how the value sorts itself out for end-users between “PaaS-native” services and those coming directly from the IaaS provider is unclear.
• What’s a platform? Who’s to say that AWS Elastic Beanstalk is less of a platform than what CloudBees offers? I’d like to think I have some experience and credibility to speak to the topic, and I can assure you ours is superior in all ways that matter technically. But in the end, if a bunch of Ruby scripts pushing CloudFormation templates make it as simple to deploy, update, and monitor a Java app as CloudBees does, those distinctions just don’t matter to most users. This is not to say that Beanstalk is functionally equivalent to CloudBees today, because it isn’t. But it’s a lot closer than it was two years ago. The integration with VPC is front-and-center, because, well, they are AWS and as an end-user, you’re using your own account with it, while we are managing the PaaS on your behalf. My point here is that our emphasis on platform value, which was very much a differentiator two years ago, is less of one today and will continue to decrease even as we add feature/functionality. Is that because we are being outpaced by competitors who were behind? No, it’s because as IaaS-native services expand their scope and the platform itself changes (see next point), the extra value that can be added by a pure-play PaaS gets boxed-in.
• Commoditization of platform. There is a lot going on in this area that is hard to capture succinctly. First, there is the Cloud Foundry effect. Cloud Foundry has executed well on an innovate-leverage-commoditize (ILC) strategy using open source and ecosystem as the key weapons in that approach. Without any serious presence in public cloud, Pivotal Cloud Foundry has produced partnerships with the largest, established players in enterprise middleware and apps. In turn, that middleware marketplace ($20B) is prime hunting ground for PaaS, and Cloud Foundry has served up fresh hope to IT people searching desperately for a private cloud strategy with roots in open source. Glimmers of hope for success in on-prem private PaaS in the enterprise act as a damper on public cloud PaaS adoption, making a risk-averse enterprise marketplace even more sluggish. Second, thanks to Docker , the containerization of apps - a mainstay implementation strategy of PaaS providers like CloudBees - is becoming “standard” and simple for everyone to use. It’s been embraced by Google as a means to make their offering more customizable, and even Amazon hasn’t been able to ignore it . This shift changes the PaaS equation again, because combining Docker with infrastructure automation tools like Chef and Puppet starts to look a lot like PaaS. New tools like Mesos also change the landscape when combined with Docker. Granted for those paying attention to details, Docker still has some holes in it, but don’t expect those to remain unplugged for long.
• It’s about service. There is a clear dividing line among PaaS players between fully-managed (think: CloudBees, Heroku) and self-managed (think: any on-prem solution, AWS Elastic Beanstalk). Broadly speaking, the startups and SME customers tend to lean toward the fully-managed side, while the larger enterprises lean toward the self-managed side. The platform changes I was covering above continue to make self-service easier, while reducing the perceived value of the fully-managed approach. I say “perceived” because the gap between the perceived and actual effort to implement a PaaS and operate it at scale is huge. It’s something that is hard for people to understand, especially if they haven’t lived through it. But, perception is reality at the buying stage, even if the reality bites at delivery. The technology and organizational investment of Heroku and CloudBees to operate at scale and to deliver deep, quality service is significant, but the perception gap leads people to equate it to the labor associated with answering PagerDuties and Nagios alerts. Furthermore, as the IaaS players move more up-stack, and customers consume a broader mixture of self-service and fully-managed value-add services, the gap increases. The other difference between fully-managed vs. self-service centers around the delivery model. When you deliver as-a-service, like we do with the CloudBees PaaS, you have advantages that are not available to on-prem software delivery and support models. But, from a CloudBees perspective, with a large, growing business delivering to on-premise Jenkins Enterprise users, we really need to think of our fully-managed Jenkins more as a SaaS, not just a component of a broader PaaS offering.

What does all this change mean to the PaaS marketplace? In addition to the moves I noted earlier, you can already observe some of the impact:

• Google consolidated their PaaS GAE and IaaS GCE stories into a single, powerful developer-savvy Google Cloud Platform story, with more consistency no doubt on the way from the mobile side of the house.
• CenturyLink bought AppFog and Tier3 , putting the combined IaaS and PaaS pieces in place to move up from being just a hosting provider.
• IBM moved all SmartCloud Enterprise efforts onto Softlayer and consolidated PaaS efforts behind the Cloud Foundry based BlueMix to extend the life of WebSphere in the cloud. At the same time, the introduction of UrbanCode gives them DevOps coolness, at least as much coolness as a blue shop can handle.
• Microsoft blurred the line between Azure PaaS and a real public IaaS, a clear recognition that combined there is more value and better ways to appeal to a broader audience.
• DotCloud pivoted to become Docker, re-purposing their internal containerization investments and de-emphasizing their PaaS business.
• Heroku aligned more closely with the Salesforce side of the house in Heroku1 - you know, the part with access to enterprise companies with deep pockets who already trust Salesforce with some of their most sensitive information.
• Rackspace , caught in the middle without a IaaS or PaaS card to play, is floundering and looking for a buyer.
• In a classic enemy-of-my-enemy confederation, traditional enterprise players have lined up behind OpenStack . Because of its open source heritage, Red Hat is well positioned to grab the leadership ring in what appears to be a contentious, political, but perhaps too-big-to-fail mess.
• Looking to avoid the messiness of OpenStack but to obtain an aura of community governance around its Cloud Foundry efforts, Pivotal created a new pay-to-play Cloud Foundry Foundation and notched up a broad range of enterprise participants.
• Amidst all this, Amazon just continues their relentless pace to add more services, the latest onslaught being aimed at mobile and collaboration .

Taken together, these changes demonstrate market consolidation, platform commoditization, a continued strength of on-prem solutions in the enterprise, and the important strategic leverage to be obtained by combining IaaS, PaaS and managed service offerings. Longer term, it calls into question whether there will even be a PaaS marketplace that is identifiable except by the most academic of distinctions. These are not trends we can ignore, particularly when we have a successful and growing business centered on Jenkins.

 

 

 

 

Steven Harris is senior vice president of products at CloudBees (and a fan of Roald Amundsen).
Follow Steve on Twitter.