I spend a lot of time talking to customers and prospective customers about how to deliver on the benefits ascribed to cloud computing within their enterprise.
Often, I find myself talking to folks that don’t care for the term “cloud” at all, given how over-hyped the term has become. Our conversations focus instead on the benefits they are seeking to deliver with improved business agility derived from improved application delivery. Naturally, given rPath’s role in the automation space, we spend a lot of time talking about software delivery and how to most effectively impact those processes.
So you’d expect terms like IaaS and PaaS to turn up a lot, wouldn’t you? And they do — but not the way many industry pundits might expect.
Who’s calling what, what in the cloud
Much like the term cloud itself, the various acronyms that we toss around so easily on the vendor side are frequently of little use in talking about the problems enterprises face in changing their operations model. That’s not to say that IaaS is of no use in the discussion, but it’s mentally substituted for “self-service VMs” in pretty much every conversation. Whatever nuances or other scope we might like to ascribe to it, “VMs on demand” are the core of IaaS for most folks. And by and large, that suffices. IaaS is the “hardware.” Easy.
SaaS is also generally a straightforward topic. After all, it’s the entire app, available on demand. Public, or sometimes private, the business process and value impacts are relatively easy to circumnavigate.
The problem is the stuff in between: the no-man’s land of in-house developed apps, platforms and operating systems. The DIY integration game every larger enterprise plays…and plays…and plays. It is more often in this layer where the mission-critical, value-added differentiation comes from — the in-house developed apps that support the uniquely “us” business activities, a layer that while hard to define, can’t be ignored.
Software stacks: The roadblock to business value
That’s why the far more interesting part of the cloud conversation comes when we start to talk about the bottlenecks holding up delivery of business value — all of which revolve around software. Whether it’s the app being developed by this team or that team, the middleware those apps rely on, the myriad of configuration settings of that middleware or the software that supports it all (aka the operating system, runtime libraries, etc.); it is the software stack that causes the most pain today.
It is this software stack that begs the answer to basic questions. What is the software? Who is responsible for it? What versions do we have? Where are they? Which layers go together for this app or that app? What parts does operations own? Who patches what, and when? What licenses are we accepting? What license fees are we liable for? All of these questions and more play a role in daily software management.
Related to their cloud aspirations, one of the first big questions regarding this “stack” is where to draw the line between what Ops will provide on the cloud versus what Dev will bring. It’s not just who installs the bits into the VM; its who manages their ongoing life cycle, ensures the correct configuration and supports the tailored needs of the applications.
Generally, all of this stuff is called the “platform.” So, it would seem natural to talk about PaaS as the road forward for the enterprise seeking to deliver private cloud capabilities. After all, isn’t that what the public cloud evolution has done? First VMs on demand, then software platforms on demand.
Kinda. Here’s the rub: What the modern enterprise needs from a usable platform as a service is largely at odds with what the current crop of PaaS offerings deliver.
Eh? Why’s that?
Well, there’s a big topic lurking inside the PaaS discussion: Choice.
The speed bump that is choice
As many have pointed out, limiting choice is the key to cloud scaling. Randy Bias recently wrote a good piece on how this is actually one of the hidden lessons of the Amazon success story. Limit choices if you want to deliver fast, reliable self-service IT capabilities.
SaaS limits choices very neatly. Either use the app or not. Customize only within limited degrees of freedom, predefined by the SaaS provider. Upgrade when you like or when we tell you to via a push of a button. Nice.
Similarly, when it comes to choice, IaaS has nothing like the degrees of freedom of the software stack to deal with. Hardware is pretty much hardware. CPU. Memory. Storage and bandwidth (x86 won the choice game for the piece that really mattered). The number of parameters is small and the menu of combinatorial choices can be easily constrained. Plus hardware doesn’t evolve all that rapidly even when virtualized. Indeed, the version of your virtual hardware is probably of little concern to your app.
But choices — OS, middleware, libraries, languages — and versions play a massive role in the software space. There are enormous degrees of freedom (liberties, one might say) and software is constantly changing, across its myriad of components. Worse, any given component is highly dependent on the versions of the other components, despite the very best efforts of software engineers to make it not so. One choice leads to another until pretty soon you’re mired in the choices that you have made.
Now in the public cloud context, for PaaS, the choices have been limited by the PaaS provider. Nice, clean modern stacks of software have been assembled, mostly for modern development languages like Ruby, Python, PHP and Java. But, especially in the case of Java, it’s largely been without the application server the enterprise assumes WebLogic or WebSphere. And to meet the economy of scale driver necessary to make this a profitable business for the PaaS provider, versions of these software platforms are necessarily limited.
Curiously, almost as if to offset this reduction in choice, PaaS providers have thrown a lot of extra “goodies” into their offerings to tempt developers. After all, if you’re going to have to rewrite your app to eliminate dependence on the choices you made before in order to use a PaaS provider’s choices instead, you may as well adopt even more of that PaaS provider’s choices. Caching, messaging and more have all become part of the PaaS platform. Indeed, PaaS as currently used in the public cloud context, is at core a set of architectural services — not just software stacks. It’s a much more powerful abstraction for cloud-scale deployment than what we have had so far.
Public PaaS offerings have limited software component choice while seeking to offset that with further powerful software abstractions. It’s like the temptation of the devil: Trade me your free will and your immortal soul, and I’ll give you more (fill in your heart’s desire here) for a while. But then you’ll be stuck.
The enterprise is well familiar with this game, having been locked into any number of vendor-supplied software platforms in the past. As a result, enterprise application portfolios depend on a myriad of different software platforms often with unique sensitivity to the versions of those stacks. Only a handful of which can be thrown away and rewritten to leverage the next-gen capabilities of the public PaaS offerings. (Don’t forget that lock-in deal!)
So who should be making these choices in the enterprise context?
Choice and utility: Where the rubber meets the road
The enterprise needs to limit choice, but it can’t necessarily do it without severely limiting the utility of its cloud offering. IaaS is easily consumable by anyone who can bring his or her own software — and maintain all of it. But a narrowly restricted PaaS will only be useful for that narrow subset of apps that is already written to the specific architecture and choices that the ops team offers.
So what are you to do? Offer only IaaS as a private cloud and stall in the pursuit of real business benefits? Offer PaaS of one form or another and tell folks to rewrite their apps to use the cloud?
How do you have your cake and eat it to?
These are the kinds of issues I find enterprises struggling with when it comes to talking about delivering platform as a service within their private cloud context. What they really want is some large-ish set of software stacks that matches their current app requirements, delivered on demand, in a self-service, automated way…ideally, without armies of people doing manual work or maintaining fragile scripted automation the way they do today. And it needs to be capable of handling disparate versions and frequent customization.
Over time, they will then pursue the goal of whittling down the number of choices available and steering new application development along more constrained pathways.
And don’t forget all those questions alluded to above: Who, what, where, and when are various software components deployed? One customer describes this as controlling the supply chain for software – a manufacturing metaphor I’ve certainly riffed on before.
So this is the challenge that the enterprise faces with platform-as-a-service. And given the very different nature of the problems involved in providing it, I find most of the operations architects I talk to reject the term PaaS as a descriptor, clarifying, “That’s not what we are trying to do here.”
So what term should we be using to refer to this messier problem? Platform on demand? Enterprise PaaS? Private PaaS? Stacks as a service? (Acronym collision with that last one.)
Let me know what you’re hearing.
