Welcome to the world of cloud tenancy – where we (we being people who use the cloud as opposed to people who provide the cloud) are shared tenants of increasingly powerful virtual, agile, api-driven and anonymous compute and storage mechanisms. This is an area where I continue to see confusion in how people look at the world of IaaS (hereafter called “cloud” in this post). In the picture below is CohesiveFT's (CFT) simple model of the market structure where we have the physical layer (been around for ever), the virtual infrastructure layer (been around in growing forms for 10+ years, dominated by VMware), and the user-cloud or cloud-tenant layer (relatively new). By user-cloud, I don't mean the end user of the application, rather the person or team responsible for the application topology being run on the cloud.
The new "separation of concerns"
If you think about it, when you are using AWS – the team of people running the physical infrastructure have no direct interaction with your application topology; and you don't want them to.
The teams of people running your virtual infrastructure at AWS have ALMOST no interaction with your application topology; and you don't want them to. The virtual infra provider team might be making snapshots of your VM's and Storage as part of their cloud service. They might do some sort of LAN-based server motion where they move your VM's 10 to 50 feet from Server A to Server B, if it appears Server A is about to fail. Other than that – you don't want their involvement – what could they do? They see your topology from “below”, they see a clump of x86 VM workloads, and have no knowledge of the semantics of your application topology, and in fact shouldn't.
You, in the user-cloud, know the semantics of your application, you know how it scales, you know where it came from, where it is going, and whether it can migrate from region to region or country to country. And to date you have used either your own self-developed knowledge of EC2, private Eucalyptus, Terremark, etc.., or you used Rightscale or CohesiveFT, or one of the other tooling sets that fit in the category Gartner calls “Cloud Management Platform”.
I believe this is an industry wide trend, and basically creates a new “separation of concerns” in how IT functionality is provided both by vendors and IT staffs, and how IT functionality is consumed. The Enterprise IT environment has vacillated for decades between centralize, decentralize, centralize, etc.. This new separation of concerns allows for the gradual evolution of a hybrid IT organization where there is a logical, and purposeful bit of both models.
There are now three distinct control planes; physical, virtual, and customer/user.
Physical infra is a centralized activity, at the very least at the geographic level.
Virtual infra will be centralized at the virtual infra layer, with the newer versions of virtual infrastructure software offering some interesting geographical federation capabilities. It is possible one might be running both VMware and Xen virtual infrastructure globally, and those virtual infra's will likely be in the control of either one IT group, or one IT group per vendor solution.
Application topologies ideally run “when” (in time) and “where” (in geography) they are most useful to a business. This means detailed knowledge of the wants, needs, beliefs, and fears of the consuming business units. If this is a global customer database without a predominant business unit owner – then that application topology itself might be managed by a centralized “common applications” team.
If it is a cornerstone application for a company's Swiss Private Client group – then I am guessing it will be managed by a business line oriented IT group in Switzerland, likely to be running on a piece of Swiss-domiciled virtual infrastructure.
They key here is to realize that there are distinct products/vendors for each layer of your cloud infrastructure, and there are distinct buyers/users for each layer of your cloud infrastructure.
To me this sets up nicely to fit into the UK idiom of “horse for courses”.
*However, in part two of this topic I will address the problematic nature of the new separation of concerns. The gist of the issue is there is a temptation in the “enterprise cloud” or “private cloud” to violate them, not recognizing that there are now consumers of each level's vendor offerings, as well as a desire of course by vendors to be the single source of all cloud computing capabilities for an enterprise (not necessarily a bad thing) by providing one monolithic product that serves all levels (a bad thing).
(pat k)
