In my last post, I discussed the subject of federated clouds. With the vast majority of federated cloud scenarios, the two parties involved have quite different views of proceedings, because cloud federation is an essentially asymmetric relationship between supplier and consumer. Consumers want to be able to see their data centre activity and their cloud-based activity as a single unified whole; providers see a delegation of control over some of their technology to the consumer, so that it can be managed from afar. This delegation can happen at multiple levels:
- the simplest (Saas) just allows remote use of the provider’s application software, nothing more
- the next simplest is DaaS, which is like SaaS except that the application being used remotely is an operating system (which can of course run other apps within it)
- then we have PaaS, which allows the running of consumer-provided applications in the cloud together with the discovery of, binding to and use of various provider services (database, etc)
- then comes IaaS, which allows the consumer control of what happens in the compute and storage fabrics, which hypervisor to use (unless you’re using VMware’s excuse for a cloud), but on a prescribed network configuration (usually flat)
- and finally comes NaaS (as an add-on to IaaS, it’s not that much use on its own) which allows more complex network topologies to be built by the consumer in the cloud (and between clouds)
(Incidentally, I’m not a fan of the term “WaaS” (Windows as a Service). To my ears it sounds like a British slang word for “urination”.)
So we have a gradation of the extent to which powers of control are delegated by the provider to the consumer. Of course, reality isn’t quite that simple, because it’s almost certainly not a 1:1 relationship between provider and consumer, because a consumer may simultaneously use cloud services from multiple providers (with federation making them all look like a single entity), and a provider would swiftly be out of business without multiple simultaneous consumers (the task of keeping them completely separate being known as “multi-tenancy”). Whenever we focus on a single provider-consumer connection (perhaps for the purpose of understanding how the connection is structured), we should remember that this is a simplification which should not be regarded as the normal state of affairs.
But back to the simplified “one provider, one consumer” model, because I’m about to complicate it in other ways.
First, there’s the question of what kind of infrastructure the consumer is using; is it a collection of virtualised machines, or a true cloud infrastructure (noting, for VMware users, that these are not the same thing)? The answer can make a substantial difference to the way the consumer would manage their enhanced data centre. Of course it’s possible to add cloud-based VMs to a virtualised data centre, but it’s going to be difficult to hide the join between those two different kinds of technology infrastructure. True cloud federation would permit the join to be hidden if required, and this is much more likely to happen if the consumer is also running a cloud infrastructure in their own data centre.
Ideally, consumers should seriously consider running the same kind of cloud infrastructure as their favourite cloud service providers. This would be supported by the (perhaps slightly naïve) premise that software vendors will build their IaaS software in such a way that it will most readily and easily federate with another instance of itself. Of course consumers may well like a choice of provider, and may not be happy about having their choice restricted only to providers using one particular IaaS implementation. I think it would be safe to say that Citrix is aiming at the “more choice” end of the spectrum, an attitude which is not universal.
But will any IaaS implementation suffice? If the consumer is required to establish any kind of strict separation between any of its business divisions – perhaps for compliance reasons, or perhaps simply to operate internal billing for IT – then it will effectively need to run its own multi-tenant infrastructure, albeit one which is used only internally. For these consumers, NaaS could be very useful, particularly if their organisation has a relatively fluid structure, as the network level is a great place to have partitioning through an appropriate topology. (It is worth remembering that not every cloud infrastructure is sophisticated enough to provide secure multi-tenancy.)
So the ideal consumer’s cloud needs to be able to federate with multiple different providers’ clouds, and perhaps also provide secure multi-tenancy to its business divisions, so their cloud usage is both mutually independent from and invisible to other divisions’. We’ll park that summary and return to it shortly.
Now, one of the most touted benefits of cloud computing is supposed to be elasticity – the promise that your data centre can expand into the cloud in an unlimited fashion. That’s all very well, but a moment’s thought should tell you that even the biggest providers’ data centres are finite, and that for the smaller provider, running out of hosting power could be a big issue, perhaps even a showstopper. So (and this is borne out by known requirements) providers also need to be able to extend the elastic services they offer to client by the somewhat recursive extension of their own infrastructure elastically into another service providers’ facility. This leads to a situation in which a provider’s enterprise client may be offered services which are actually situated with a provider that is at least one hop away, and possibly more. The problem for the consumer is that these hops are hidden from them, and so they have no idea which provider is giving them the service they are using; many of you will already have spotted that this constitutes a potential performance nightmare.
Nevertheless, this extension of providers’ space is a necessary evil in order to make things work smoothly, although there are three important corollaries:
– First, harking back to our observation parked earlier, we see that the ideal consumer cloud (to be run in an enterprise’s data centre) has exactly the same requirements as the ideal provider cloud, in terms of the need to both provide and use cloud infrastructure services. The consumer may be able to get away without offering multi-tenancy, but both provider and consumer need to be able to extend seamlessly into multiple other cloud offerings. And any sensible cloud infrastructure creator will have but one set of source code for them both, even though the marketing and packaging may differ.
– Second, the ability for one provider to rent out to a consumer part of another provider’s cloud is an essential prerequisite for establishing for providers a secondary market in spare cloud capacity, eventually to become an automated exchange, which seems the appropriate direction for something which is fast becoming a commodity.
– Third, the potential performance issues encountered when using a VM hosted several providers deep may not be acceptable, and so there must be a method of discovering before a service is used its likely performance characteristics, the depth of nesting, or both. This is where SLAs for cloud computing come in, because this are the only method there is of promising and accepting an appropriate level of service ahead of actual usage. Allow me to cite Arjuna as a example of a company doing great work in this area.
So, to sum up: consumer and provider needs are more alike than one might at first think. Nesting of service provision may occur, and the only defence is the SLA, which if written right can also be used to broker the use of space cloud space and hence open up a new secondary market. And the underlying message to cloud software vendors is: make sure your IaaS can provide handle SLAs automatically, if you don’t want to be left out of this market …