Is it self-serviced? Is it APIed?
With VMware and Microsoft now really entering the Private (and Hybrid) Cloud market, we’ll see an increased drive towards software-controlled DCs and IT-aaS. No surprise, hence, that many legacy DC providers and outsourcers seek their place on that battlefield also with their offerings.
Their way of doing so is to embrace this new technology “Cloud” which is brought onto a more comprehensive, digestable level with vCloud, SystemCenter and the like. Next steps seen from those on that path are normally e.g.:
- Establish partnerships with those vendors – mainly to get their urgently needed discounts
- Create a reference architecture which looks surprisingly similar to the diagrams provided by the above vendors
- Re-organize their network, storage and server teams to jointly create the new data center
- Create a GTM strategy which uses “Cloud” at least once on every slide
Now, what’s their offering?
Utlimately it is a virtualized datacenter infrastructure, supported by the resource pooling models that the mentioned technologies provide. Who’s using this new datacenter infrastructure? The provider himself. Essentially, this is no false approach – by no means; but! – it is no full approach.
Let’s simply mirror against the esential characteristics of cloud computing *):
- broad network access: “broad” is not only meant in a sense that the (Cloud) DC is accessible form anywhere but that the service is accessible from anywhere, with any device, in any function. Apart form the fact that connectivity into the DC is seldomly changed from the provider’s earlier offerings, the newly established “Cloud” service is less than seldomly accessible from anything other than a PC.
- resource pooling: yes, that’s what vCloud and SystemCenter (and maybe others as well) really know how to do – if there are enough of
- rapid elasticity: yes, by embracing an infrastructure management framework like the above, rapid elasticity may be provided in a sense that the pooled resources can be provisioned to consumers in an instant – if there are enough of. Question is: Who’s provisioning it? And by which process? We’ll come back to that shortly
- measured: The point of a “measured” cloud service is not that the provider monitors his performance. The point is that the consumer is offered full transparency of the provider’s compliancy with the agreed SLA in terms of performance, availability, realiability and cost. Key here: “transparency” of metered, measured and monitored services and components
- on-demand self-service: BOOM! Fullstop here. Most of the offerings which are called “Cloud” and are provided by legacy DC providers offer the cloud capabilities internally within the providers’ DC. I tend to believe the slides about reference architecture, building block and service capabilities. But – this functionality is not brought to the customer. The contracting is not changed. Provisioning takes place in a ticket-based manner through service desk personal. Measurement is hidden. Rapidity is reduced. Elasticity and pooling are controlled by the provider. Guys, you’re not cloud. Period.
Why is this a problem?
Because, the world has long moved on. Cloud consumers are not asking for a cloud-based delivery of services out of a legacy DC. Cloud consumers wanna have it in their hands. Cloud consumers expect to gain control over their resources without(!) paying for resource guarantees upfront (btw: guaranteeing a certain amount of resources to cloud consumers is most rarely a way to offer higher service quality to the consumer but rather to gain higher level of control over resources for the provider).
What Cloud consumers will ask, as of now, is:
- Can I self-service my IT when I run it with you?
- Does it have an API exposed to the extern, that I can use to integrate?
Alex Williams predicts a hard time for “Cloud Washers” in this post on techcrunch. But what he even more predicts is consumers’ expectations regarding a new way of production, the moving of apps rather than VMs, a losely coupled mesh of services and consumers’ expectation to on-demand self-service these. Overall, this is going far beyond self-service and a featured API as such. Eventually it aims at process centric service (deployment) automation.
“Look out cloudwashers”, he says, “it’s just going to get worse. This shake up is happening faster than anyone realized.”
I’d like to add a wish: Cloudwashers, when embracing an inherently great technology for building your cloud offering, build it fully. Embrace and offer all of the essential characteristics!
*) Cloud Computing essential characteristics according to NIST Special Publication 800-145 „The NIST Definition of Cloud Computing“, Recommendations of the National Institute of Standards and Technology