Breaking Apart the Private Cloud Debate

I have been spectating throughout the ongoing private vs. public cloud debate taking place among the Clouderati. It often feels like watching medieval knights lumbering about the jousting field, sweating and grunting and smashing each other over the head with their maces. Recently, however, Christian Reilly mentioned the phrase “private PaaS”, which switched on a lightbulb for me about how to make the conversation more useful.

I have been spectating throughout the ongoing private vs. public cloud debate taking place among the Clouderati. It often feels like watching medieval knights lumbering about the jousting field, sweating and grunting and smashing each other over the head with their maces. Recently, however, Christian Reilly mentioned the phrase “private PaaS”, which switched on a lightbulb for me about how to make the conversation more useful.

What is The Advantages of Private Paas?

Technical Support Customer Service Business Technology Internet Concept.

While “private cloud” feels controversial, “private PaaS” feels like a no-brainer. Enterprise IT groups have to support multiple applications built by multiple development groups. They are on the hook for operational excellence, but are at the mercy of the development groups for application code and architecture that makes operational excellence possible. A private PaaS could give back control to IT over the area for which it’s accountable. It could also help development by letting them focus on their core competency, which is application functionality.

The Defenition Of Private Paas

The term “private PaaS” has wider conceptual implications, though. It breaks open the monolithic “private vs. public cloud” debate into a layered discussion. IMHO it enables a much more interesting set of conversations and combinations. Netflix, for example, migrated its website infrastructure to AWS, which is a public IaaS. At the same time, though, they wrote their own internal-use PaaS platform to run on top of AWS. In other words, Netflix is a case of private PaaS on top of public IaaS. An enterprise, on the other hand, might choose to run a private PaaS on top of a private IaaS. In the future, that same enterprise might decide to migrate that private PaaS to run on top of a public IaaS. If they happened to be using CloudFoundry as their PaaS, they could also transparently migrate the PaaS layer from their private deployment to one of the public CloudFoundry-based PaaS providers.

What about the SaaS layer?

Some would argue SaaS is not cloud. For the purposes of this discussion, at least, I don’t think it matters. Software services like enStratus let customers choose whether to use vendor-hosted or self-hosted instances. If a SaaS application were built on top of a PaaS, then the enterprise could make dynamic private vs. public deployment choices all the way up and down the XaaS stack.

We are well into the age where layering and loose coupling are considered software architecture stock-in-trade. It’s ironic that we seem to have forgotten our own methodology. As far as I can tell, the private vs. public cloud debate is really about private vs. public IaaS. I’m not going to wade into that argument – my mace and helmet are nowhere near sufficiently sturdy. I do believe, though, that rephrasing the cloud debate in terms of its component layers will let us argue about things more precisely, flexibly, and productively.

Post Comment