In my last blog I wrote about Cloud Management platforms, and how they enable integration of multiple clouds (public and private).
One purpose of this is to drive standardisation of infrastructure. This is the usual drive for standards, strategies, life cycling and consolidation that has been with us for years.
Tech-heads get excited about new stuff like node.js, ruby on rails, Ubuntu, skinless servers etc., but in isolation these technologies provide absolutely no benefit to a company. They cost money to buy, build and support. When these component technologies are combined with application logic and data though, they can add immense value. This value must exceed – by a decent margin – the sunk cost of deployment and support.
IT vendors move between mass standardisation/commoditisation and differentiation – sometimes doing both things at the same time. AWS, GCE, and Azure strive to provide a base server at the cheapest cost – ie. commoditisation – but at the same time offer differentiated, non-standard services like Azure Service Bus and Redshift – to get the customers in (and keep them).
Also, over time enterprises accumulate legacy bits and pieces that are too old, too important or too expensive to replace. There they (dis)gracefully age until something serious happens.
All these drivers work against simplification and standardisation. A good friend I use to work with was asked by the IT Group Manager what he would do if, in his role as IT Infrastructure Manager, he had a blank cheque and infinite time. He said something like trash the whole lot and start again. From scratch. Clean out the “detritus”.
If you’re an established enterprise you’ve probably spent the last couple of years trying to understand The Cloud and what it means. The years before that you probably virtualised the hell out of everything on some hypervisor, and before that you tried to get everything on commodity servers. Along the way you migrated many workloads to the latest and greatest, but not everything. You probably still have non-cloud, non-virtualised, non-commodity gear around. Do you really believe all workloads will end up on IaaS?
(If you’re a start-up, it probably makes sense to start in one cloud. As you grow though you may end up getting stuck using their proprietary technology. That may be ok, or not. Ask yourself, could Netflix migrate off AWS, and what cost?)
You have standards for deploying servers in-house (something like Linux or Windows on a hypervisor), you have standard network switch configurations and whatever passes for standards in the storage space.
You don’t want to manage a second (or third or fourth) set of standards for your IaaS provider(s).
Comparing some pretty standard IT infrastructure objects against some AWS objects:
|In-house technology||AWS technology|
|Firewall policy||Security Groups|
At best they are only packaged differently (VMs vs AMIs) and their guts are pretty similar. At worst, they have different capabilities, configurations, and therefore standards and expertise (load balancers vs ELB).
If you buy the Hybrid cloud direction we’re heading according to Gartner and your own observations then…
It’s two – or more – standards trying to be one, and that’s possibly double the work for IT.