Things are gearing up in some local debates about where to move datacenter strategies, and there are too many pointy hairs running around shouting “the cloud, the cloud!”. I wanted to delineate some terms.##Virtualization vs. Cloud
So, we have virtualization in our DC. Yay. But the provisioning is manual, based on public ips (sigh, yes), slow and inefficient. Storage tier, well, let’s not even go there. And I’m running around calling it a cloud for everyone’s political benefit as well, but I caused quite the ruckus when I asked for our latest high-profile app to be built in an *elastic* fashion. Even the bloody vendor thought that what I wanted was to clone the prod server and have a back-up in standby for, *cough, cough* HA.
Virtualization is necessary but not sufficient for having a cloud. So, with your virtualization, we have multiple VMs running on each node, or host. But for cloud, we need to enable automatic provisioning and de-provisioning, as well as the movement/management of these VMs. This requires a programmatic interface, accessed through an API ideally, to be driven by the controller. This is going to push us into questions of storage, private ips for fast allocation of network resources, etc.
Our collection of compute, storage and network resources, solely for us, the sole tenant, but controlled via our nifty API endpoint (v. supra).
as per the private cloud, but multi-tenant, thus, not just us in there.
environment that spans one or more public clouds AND one or private clouds.
environment spans two or more clouds of any type.
We want to go private and probably hybrid for some of our elastic compute needs. Storage of data at rest needs to stay in our tenancy. High demand I can see off loading into a public cloud, and I want to leverage some of the public cloud services for rapid development since, at this point, I’m convinced that they would be quicker for us.
Still, in terms of security, and compliance, there is no doubt that the private cloud will satisfy our requirements better. It is entirely within our own environment and we take it all very seriously. Despite our 10 Gb/s pipes to the world, latency off-site may prove to be an issue as well.
There’s plenty of research that shows, once you have it designed correctly, that the private cloud environment is generally cheaper on a VM/hour basis than a public cloud. So, I want to use the public as our *extra* capacity. That will provide us with some challenges, of course.
So, some more terms.
Nodes grouped with the same physical configuration.
Clusters grouped within a single network segment. Similar to a rack.
Pods grouped with the same secondary storage. These zones are built to isolate failure from other zones, including separate power and network access.
##Region (or cloud)
One or more zones accessible via one or more common API endpoints, with the zones connected with high-speed network.
When we get there, I wish to see self-service provisioning, and better control and security in a single view, including better operational costs.