Which Part of the Public vs. Private Cloud Elephant Are You Touching?

Jun 10, 2011 by Sinclair Schuller

The private/public cloud discussion is something that has been getting lots of attention. I think one of the big issues is that different perspectives are causing people to speak differently about the same thing, and confusion around what public vs. private really is (e.g., what is a Private PaaS running on public IaaS) adds fuel to the fire. Maybe a parable can help. One of my favorite (albeit overused) parables is that of the Blind men and an elephant. The story is as follows: four blind men discover an elephant for the first time. Since they have never encountered an elephant before, they each touch a part of the elephant that they are closest to, feeling about so that they can assess what it is they are touching. One man grabs the elephants trunk, and determines that he is clearly touching a snake. Another grabs the tail, and concludes that it is a rope. The third, wrapping his arms around the leg, announces that it is clearly a tree. Last but not least, the fourth blind man runs his hands along the elephants side and determines that they have discovered a wall.

Clearly, they’re each interacting with the elephant, but are also each describing the elephant (based on their individual perspectives) in drastically different ways.

This is extremely relevant to today’s cloud computing discussion. Essentially, the problem we have is that cloud computing is our elephant, and although we are each interacting with cloud computing, we are suffering from the same problem as the four men in the parable; our “perspective blindness” causes us to only base our understanding on what we are capable of assessing, thereby failing to see cloud computing as a whole. This was extremely apparent after I wrote a post for GigaOM. Both in comments and in Twitter, I had people supporting and rejecting the notion of cloud technologies transplanted into private settings (such as deploying private IaaS or private PaaS). Some argued that public cloud provided X, and Y, and Z while private didn’t. At the end of the day, both public and private cloud can provide significant value to the various constituents in enterprise IT. To understand why private cloud might make sense to some and not others, we need to understand the relationships between the various parties in enterprise IT in the context of cloud computing:

(bigger)

Granted, the diagram doesn’t capture the finer grained details of the relationships, but it does define a framework to work off of. Each constituent in enterprise IT has a “primary” role when considering the application as the first class citizen of  the system:

1. Consumption
2. Application Development
3. Infrastructure Management

Each constituent is analogous to one of the blind men touching the elephant that is cloud computing. Let’s look at this more specifically. If you are a business end user that needs to source a certain application X, you can either a) use a solution that the developers within your organization have built on some private cloud or b) use an external SaaS provider (which apparently is  a growing trend in IT). From the business end users perspective, they don’t care if an app is running in a private cloud or public cloud, or is a custom solution coming from LOB developers within the enterprise or an external SaaS provider. They need an app for some specific business function to create value and solve problems. We can find lots of tangential reasoning as to why they should use public cloud only, but from a practical perspective, they just need to know that whatever app they are using fulfills all of their requirements (and constraints). If the app is provided by their own LOB developers and is deployed to the private cloud, that’s fine. If  they are using a public SaaS app, that’s fine too. Some apps might provide additional value in a public form factor, but it shouldn’t be the deciding factor.

Similarly, from the perspective of enterprise developers who build custom apps within the enterprise, they want to know if they can quickly and easily deploy their apps and get functionality from an underlying stack. The current IT model is broken: each dev team builds an app a different way, when it’s time to deploy, they contact IT and wait 30-60 days for a server to be provisioned, they manually configure the app, and manually deal with the app’s lifecycle using the same cumbersome approach that was used to get it up and running. Cloud (particularly PaaS)  presents a very agile model with blazing fast time to market, advanced architecture qualities, and little friction. Developers are simply looking to get past this antiquated approach; they might want to deploy to a public PaaS like Azure, but if central IT offered a private PaaS, they might prefer that because it’s less friction in terms of adoption and from their perspective, they get the same major benefits: upload and deploy apps at a button click, get scalability for free, and get other benefits like distributed caching as services. From the developer’s perspective, they’d get what they need, regardless of the form factor. It gets even more difficult parse if you consider that central IT could deploy a private PaaS to either their own private cloud, or to a public IaaS provider like EC2. Is that a public or private PaaS? Clearly, the IT team owns the Amazon account and is deploying their own PaaS layer to public infrastructure. From the developers perspective, it’s a private PaaS (as in owned by their organization), from central IT’s point of view, they are using public cloud. For me, this is a very real topological distinction since our customers can license SaaSGrid and deploy it to their own bare metal infrastructure and get a private PaaS, on their private virtualization cloud and get private PaaS, or on something like EC2 and expose a PaaS to their internal developers. We don’t necessarily care, but the lines are clearly blurry as to which is “more public”:

1. Private PaaS on Private Cloud
2. Private PaaS on Public IaaS
3. Public PaaS

Is number 2 more public or more private? This highlights the absurdity of the debate that continues to come up in nearly every public/private conversation. At the end of the day: who cares? If the end users in an organization want a specific offering provided in a SaaS fashion: great. If they use an offering built by their LOB developers and deployed to their private PaaS on their private cloud, or their private PaaS deployed on public IaaS, they’d be just as happy.

In some instance, public cloud makes the most sense, in others private cloud. Sometimes, real costs of adopting public cloud severely impact it’s ROI, so private cloud gives some of the benefits with less costs, causing private cloud ROI to be higher. In other cases, public cloud can be adopted using little friction and is the way to go. I think the sooner we recognize that the fierce debate of whether the elephant is a snake, a rope, a wall or a tree is silly, and that we should each be comfortable with the fact that our perspectives might influence or judgment, the sooner we can all focus on extracting value from cloud tech.

Do you agree that both public and private cloud are relevant? Are you passionate that cloud is public only or nothing? If so, why?