In my last post, I discuss the subject of federated clouds. With the vast majority of federated cloud scenarios, the two sides have very different views of the proceedings, because a cloud federation is essentially asymmetrical relationship between the supplier and the consumer. Consumers want to be able to see their data center business and its cloud business as a unified whole; suppliers see a delegation of control over part of their technology to the consumer, so that it can be managed remotely. This delegation can occur at several levels:
- The simplest (Saas) only allows remote operation of the supplier's application software, nothing more
- next DaaS is simpler, which is like SaaS except that the application used remotely is an operating system (which can of course run other applications in it)
- so we PaaS, allowing the operation of consumer applications delivered in the cloud with the discovery of the connection and the use of various service provider (database, etc.)
- then comes IaaS, which allows control of the consumption of what is happening in the computing and storage fabric, which hypervisor to use (unless you are using VMware excuse for a cloud), but on a prescribed network configuration (usually flat)
- and finally comes NaaS (as an add-on to IaaS, there is not much on its own), which allows more complex network topologies to be constructed by the consumer in the cloud (and between clouds)
(by the way, I'm not a fan of "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 the supervisory powers are delegated by the supplier to the consumer. Of course, the reality is not quite that simple, because it is almost certainly not a 1: 1 relationship between the supplier and the consumer, because the consumer can simultaneously use cloud services from multiple providers (with the federation who makes all look like a single entity) and a provider would quickly be out of business without multiple concurrent users (the task of keeping them being completely separate known as "multi-tenancy"). Whenever we focus on a single supplier-consumer connection (perhaps in order to understand how the connection is structured), we must remember that this is a simplification which should not be considered as the normal state of things.
. But back to the simplified procedure 'a supplier, a consumer "model, because I'm about to complicate it by other means
First, there is the question of what kind of infrastructure is the consumer using, is a collection of virtualized machines, or a true cloud infrastructure (noting, for VMware users, that they are not the same) the answer can make a substantial difference to the way? the consumer would be improved to manage their data center. of course, it is possible to add virtual machines to cloud-based virtualized data center, but it will be difficult to hide the junction between these two types of infrastructure technology. True cloud federation allows the connection to be hidden if necessary, and this is much more likely to occur if the consumer is also running a cloud infrastructure in their own data center.
Ideally, consumers should seriously consider implementing the same type of cloud infrastructure as their preferred cloud service providers. This would be supported by the (perhaps somewhat naive) premise that software companies will build their IaaS software in such a way that it will be very quickly and easily federate with another instance of itself. Of course, consumers may well as a choice of the supplier, and can not be happy to have their choice restricted only to vendors using a particular implementation IaaS. I think it would be safe to say that Citrix aims to "more choice" end of the spectrum, an attitude that is not universal.
But will any implementing IaaS enough? If the consumer is required to establish a sort of strict separation between one of its business divisions - perhaps for compliance reasons, or perhaps simply to operate chargeback IT - then it will actually need to launch its own multi-tenant infrastructure, although that is only used internally. For these consumers, NaaS could be very useful, especially if their organization has a relatively fluid structure, such as the level of network is ideal for partitioning through an appropriate topology. (It should be recalled that all cloud infrastructure is sophisticated enough to provide secure multi-tenancy.)
So the ideal cloud consumer must be able to federate with the clouds of several different suppliers and may also provide secure multi-tenancy its business divisions, so that their cloud usage is both independent of each other and invisible for the other divisions. We park the summary and return shortly
Now, one of the most touted advantages of cloud computing is supposed to be elastic -. The promise that your data center can develop in the cloud without limit. All very well, but the thought of a moment should tell you that data centers even the largest suppliers are finite, and that for the smallest supplier of lack of accommodation power could be a big problem, perhaps a pitfall. So suppliers (and this is confirmed by the known requirements) should also be able to extend the elastic services they offer to the customer by the somewhat recursive extension of their own elastic infrastructure in the installation of another service providers. This leads to a situation in which the company's customer of a service provider that can actually be located with a provider that is at least one hop away, and perhaps longer available. The problem for the consumer is that these jumps are hidden from them, and so they have no idea which provider gives them the service they use; many of you will already have spotted that this is a performance potential nightmare
Nevertheless, this extension of the suppliers of space is a necessary evil to make things work smoothly, although there three important corollaries:
- first, harking back to our observation parked earlier, we see that the cloud of the ideal consumer (to be run in an enterprise data center) has exactly the same requirements that the ideal cloud provider, in terms of the need to both provide and use cloud infrastructure services. The consumer may be able to get out without offering multi-tenancy, but both supplier and consumer must be able to seamlessly extend several other cloud offerings. And any infrastructure cloud creator supposed to have, but a set of source code for both, even if the marketing and packaging may differ
-. Second, the ability of a supplier to rent some consumers from another provider of cloud is an essential prerequisite to the establishment for suppliers of a secondary market for spare cloud capacity eventually to become automated exchange, which seems the appropriate direction to something that is becoming a commodity
-. Third, the potential performance issues encountered when using a VM hosted several deep providers may not be acceptable, and therefore there must be a method to discover before used his service likely performance characteristics, the nesting depth, or both. This is where SLAs for cloud computing just because it is the only method, it is promising and the acceptance of an appropriate level of service before actual use. Let me quote Arjuna as an example of a company doing excellent work in this area
So to summarize :. The needs of consumers and suppliers are more alike than one might think at first. Nesting service delivery can occur, and the only defense is ALS, which if written law can also be used to negotiate the use of space cloud space and thus open a new secondary market. And the underlying message to cloud software vendors is: make sure your IaaS can provide handful of ALS automatically if you do not want to be left out of the market ...
0 Komentar