Disclaimer: I am talking about IaaS when I use the term "cloud" in this post.
A quick recap from Part 1 where I was outlining what I see as:
The new "separation of concerns"
If you think about it, when you are using a public cloud like Amazon Web Services (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. 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 (pictured below).
But this gives rise to the question....
Where should my virtual infrastructure and its providers fit in?
We know that a Public Cloud as my underlying physical infra provider cannot take any specific knowledgeful action on my applications, nor do I want them to. It is the same with Public Cloud companies in the role as my virtual infrastructure provider, other than a nominal number of very narrow geographic recovery actions.
What about in my Private Cloud? Today the Private Cloud (agile virtual infrastructures running in my own datacenters or co-lo centers) is often mimicking existing centralized IT behaviors. In this model, a line of business (LOB) or application owner has to go “hat in hand” to centralized IT to make deployments happen.
I would argue this is an evolutionary artifact which will succumb in the face of Enterprise IT successfully evolving into comprehensive virtual infra providers. Imagine if you will, the “private cloud pixies” come overnight and magically transform all of your available x86 hardware stock into one global, integrated/federated, api-driven, virtualized fabric. All of a sudden you would realize how the "frozen chunks of metal" in your physical layer (servers, storage arrays, routers, switches, etc.) had come to define the structure of your business, your control mechanisms, and your attempts at knowledgeful centralization of the application layers. As these devices become only a conveyance for virtualized compute, virtualized storage and virtualized networking – instantly the application layer accelerates to a speed and fluidity that provides poor grasp for IT staff and even less tractable control for an ISV infrastructure that perceives reality from below.
Application owners, managing from “above” know their application, its topology and are best able to deploy it to some set of described resources. These described resources (available VM slots at the simplest) probably are detailed with respect to computer power, memory availability, geography if not legal jurisdiction, storage availability, LAN speed, network edge speed, etc..
The IT operations team (which could report to centralized IT or the LOB) which knows the application best, is best positioned to bring agility and satisfaction to the application owners.
This is the next battleground for the hearts and minds of the buyers of virtual infrastructure in the enterprise. On one hand, public cloud vendors viscerally perceive the new separation of concerns. They do not want their physical infra or virtual infra staff concerned with the discrete details of any one customer's application workload.
Yet, the private cloud vendors and the incumbent virtual infrastructure providers (centralized Enterprise IT) are aligned in wanting to manage the application topology (and accordingly the Line of Business) from the middle as it were. For the IT team running the virtual infrastructure – they are avoiding “giving up” of something they fear to give up. For the virtual infra ISV, they avoid having to find and negotiate with a new buyer. They avoid having to engineer products from the top, that can integrate with their products from the middle.
This picture shows the current trend. Virtual infra providers bringing to market feature sets from the middle (as pictured vDog, vCat and vMagic) putatively to meet the needs of the user-cloud, the cloud tenants.
I don't like this approach. Perhaps, in a self serving sense, I am against this because it means more competition for CFT and others in the Gartner-dubbed "Cloud Management Platform space". But it is more than that. It is a violation of the new and powerful separation of concerns which is playing out quite nicely in AWS / Public Cloud space today and should have its chance in the private cloud space as well.
I am not against the virtual infra ISVs coming up with products for the user-cloud. I am happy for them to deliver a line of “u” products (user-cloud products); uDog, uCat and uMagic that use the public, published APIs of their “v” product counterparts.
What are examples of good "vDogs" or "uDog" counterparts? For one I would say Amazon's SimpleDB. It is a platform service provided from the middle, owned, operated and controlled from the middle - and can be used by application creators to create their own user-cloud applications which they can control. From the same vendor comes a good "uDog", Amazon RDS (Relational Database Service). It is provided at the user-cloud level and it is managed and controlled by the application owner. Another good "vDog" is Amazon VPC (virtual private cloud). Again, it is owned and operated in the midldle, powerful, yet comes with lessened customer control just like its database counterpart. Amazon's ecosystem provides the corresponding "uDog", CohesiveFT's VPN-Cubed; owned, operated, and controlled in the user-cloud level. As I said in my previous post, horses for courses (vHorses?). I won''t point out bad vDogs and vCats here - but they are out there and I recommend thinking through their usage and their violation of the operational planes of control public and private cloud is now affording us.
When we give the cloud application owners control from above, and virtual infrastructure providers stick to managing at the workload level from below, I believe it encourages innovation in enterprise IT organization, innovation in features and functions for managing application topologies, and better interoperability and integration between cloud vendors; whether from the virtual infra or user-cloud perspective.
If we take advantage of the new separation of concerns being afforded us by the emergence of three distinct planes of operational control; physical, virtual and user, then I think we have a chance of maximizing enterprise agility and ROI as they engage in the world of public, private and hybrid cloud infrastructures.
If you are looking for me, you will find me with the rest of the CFT team, in the user-cloud.
