The Standardized Cloud
Over the last few weeks I've been engaged in several conversations about the need for a common, interoperable and open set of cloud computing standards. During these conversations a recurring theme has started to emerge. A need for cloud interoperability or the ability for diverse cloud systems and organizations to work together in a common way. In my discussion yesterday with Rich Wolski of the Eucalyptus project he described the need for a "CloudVirt" API similar to that of the Libvirt project for virtualization. For those of you that don't know about libvirt, it's an open source toolkit which enables a common API interaction with the virtualization capabilities of recent versions of Linux (and other OSes).
I would like to take this opportunity to share my ideas as well as get some feedback on some of the key points I see for the creation of common cloud computing reference API or standard.
* Cloud Resource Description
The ability to describe resources is (in my opinion) the most important aspect of any standardization effort. One potential avenue might be to use the Resource Description Framework proposed by the W3C. The Resource Description Framework (RDF) is a family of specifications, originally designed as a metadata data model, which has come to be used as a general method of modeling information through a variety of syntax formats. The RDF metadata model is based upon the idea of making statements about Web resources (or Cloud Resources) in the form of subject-predicate-object expressions, called triples in RDF lingo. This standardized approach could be modified as a primary mechanism for describing cloud resources both locally and remotely.
* Cloud Federation (Cloud 2 Cloud)
The holy grail of cloud computing may very well be the ability to seamlessly bridge both private clouds (datacenters) and remote cloud resources such as EC2 in a secure and efficient manor. To accomplish this a federation standard must be enabled. One of the biggest hurdles to over come in federation is the lack of clear definition to what federation is.
So let me take a stab at defining it.
Cloud federation manages consistency and access controls when two or more independent geographically distinct clouds share either authentication, files, computing resources, command and control or access to storage resources. Cloud federations can be classified into three categories: peer-to-peer, replication, and hierarchical. Peer 2 peer seems to be the most logical first step in creating a federation spec. Protocols like XMPP, P4P and Virtual Distributed Ethernet may make for good starting points.
* Distributed Network Management
The need for a distributed and optimized virtual network is an important aspect in any multi-cloud deployment. One potential direction could be to explore the use of VPN or VDE technologies. My preference would be to use VDE, (Virtual Distributed Ethernet). A quick refresher, a VPN is a way to connect one or more remote computers to a protected network, generally tunnelling the traffic through another network. VDE implements a virtual ethernet in all its aspects, virtual switches, virtual cables. A VDE can also be used to create a VPN.
VDE interconnects real computers running (through a tap interface), virtual machines as well as the other networking interfaces through a common open framework. VDE supports heterogeneous virtual machines running on different hosting computers and could be the ideal starting point. Network shaping and optimization may also play an important role in the ability to bridge two or cloud resources.
Some network optimization aspects may include;
When looking at the creation of compute cloud memory tends to be a major factor in the performance of a given virtual environment, whether a virtual machine or some other application component. Cloud memory management will need to involve ways to allocate portions of virtual memory to programs at their request, and freeing it for reuse when no longer needed. This is particularly important in "platform as a service" cloud deployments.
Several key memory management aspects may include;
* Distributed Storage
I've been working on creating a cloud abstraction layer called "cloud raid" as part of our ElasticDrive platform and have been looking at different approaches for our implementation. My initial idea is to connect multiple remote cloud storage services (S3, Nirvanix, CloudFS) for a variety of purposes. During my research the XAM specification began to look like the most suitable candidate. XAM addresses storage interoperability, information assurance (security), storage transparency, long-term records retention and automation for Information Lifecycle Management (ILM)-based practices.
XAM looks to solve key cloud storage problem spots including;
Potential Future Additions to the API
* I/o
The virtualization of I/O resources is a critical part of enabling a set of emerging cloud deployment models. In large scale cloud deployments a recurring issue has the ability to effectively management I/o resources whether on a machine level or network. One of the problems a lot of users are encountering is that of the "nasty neighbor" or a user who has taken all available system I/o resources.
A common I/o API for sharing, security, performance, and scalability will need to be addressed to help resolve these issues. I've been speaking with several hardware vendors on how we might be able to address this problem. This will most like have to be done at a later point after a first draft has been released.
* Monitoring and System Metrics
One of the best aspects of using cloud technology is the ability to scale applications in tandem to the underlying infrastructure and the demands placed on it. Rather then just scaling on system load, users should have the ability to selectively scale on other metrics such as response time, network throughput or other metrics made available. Having a uniform way to interact with system metrics will enable cloud providers and consumers a common way to scale applications.
Security & Auditability.
In my conversations with several wall street CIO's the questions of both security and cloud transparency with regards to external audits has come up frequently.
---
My list of requirements is by no means a complete list. Cloud computing encompasses a wide variety of technologies, architectures and deployment models. What I am attempting to do is address the initial pain points whether you are deploying a cloud or just using it. A lot of what I've outlined may be better suited to a reference implementation then a standard, but none the less I thought I'd put these out ideas out for discussion.
-- Updates --
1. Looks like I've forgotten an obvious yet important aspect to my cloud standards. Authentication. Maybe something like OAuth or OpenID could form the basis for this as well. I'll need to do some more thinking on this one.
I would like to take this opportunity to share my ideas as well as get some feedback on some of the key points I see for the creation of common cloud computing reference API or standard.
* Cloud Resource Description
The ability to describe resources is (in my opinion) the most important aspect of any standardization effort. One potential avenue might be to use the Resource Description Framework proposed by the W3C. The Resource Description Framework (RDF) is a family of specifications, originally designed as a metadata data model, which has come to be used as a general method of modeling information through a variety of syntax formats. The RDF metadata model is based upon the idea of making statements about Web resources (or Cloud Resources) in the form of subject-predicate-object expressions, called triples in RDF lingo. This standardized approach could be modified as a primary mechanism for describing cloud resources both locally and remotely.
* Cloud Federation (Cloud 2 Cloud)
The holy grail of cloud computing may very well be the ability to seamlessly bridge both private clouds (datacenters) and remote cloud resources such as EC2 in a secure and efficient manor. To accomplish this a federation standard must be enabled. One of the biggest hurdles to over come in federation is the lack of clear definition to what federation is.
So let me take a stab at defining it.
Cloud federation manages consistency and access controls when two or more independent geographically distinct clouds share either authentication, files, computing resources, command and control or access to storage resources. Cloud federations can be classified into three categories: peer-to-peer, replication, and hierarchical. Peer 2 peer seems to be the most logical first step in creating a federation spec. Protocols like XMPP, P4P and Virtual Distributed Ethernet may make for good starting points.
* Distributed Network Management
The need for a distributed and optimized virtual network is an important aspect in any multi-cloud deployment. One potential direction could be to explore the use of VPN or VDE technologies. My preference would be to use VDE, (Virtual Distributed Ethernet). A quick refresher, a VPN is a way to connect one or more remote computers to a protected network, generally tunnelling the traffic through another network. VDE implements a virtual ethernet in all its aspects, virtual switches, virtual cables. A VDE can also be used to create a VPN.
VDE interconnects real computers running (through a tap interface), virtual machines as well as the other networking interfaces through a common open framework. VDE supports heterogeneous virtual machines running on different hosting computers and could be the ideal starting point. Network shaping and optimization may also play an important role in the ability to bridge two or cloud resources.
Some network optimization aspects may include;
- Compression - Relies on data patterns that can be represented more efficiently.
- Caching/Proxy - Relies on human behavior , accessing the same data over and over.
- Protocol Spoofing - Bundles multiple requests from chatty applications into one.
- Application Shaping - Controls data usage based on spotting specific patterns in the data and allowing or disallowing specific traffic.
- Equalizing - Makes assumptions on what needs immediate priority based on the data usage.
- Connection Limits - Prevents access gridlock in routers and access points due to denial of service or peer to peer.
- Simple Rate Limits - Prevents one user from getting more than a fixed amount of data.
When looking at the creation of compute cloud memory tends to be a major factor in the performance of a given virtual environment, whether a virtual machine or some other application component. Cloud memory management will need to involve ways to allocate portions of virtual memory to programs at their request, and freeing it for reuse when no longer needed. This is particularly important in "platform as a service" cloud deployments.
Several key memory management aspects may include;
- Provide memory space to enable several processes to be executed at the same time
- Provide a satisfactory level of performance for the system users
- Protect each program's resources
- Share (if desired) memory space between processes
- Make the addressing of memory space as transparent as possible for the programmer.
* Distributed Storage
I've been working on creating a cloud abstraction layer called "cloud raid" as part of our ElasticDrive platform and have been looking at different approaches for our implementation. My initial idea is to connect multiple remote cloud storage services (S3, Nirvanix, CloudFS) for a variety of purposes. During my research the XAM specification began to look like the most suitable candidate. XAM addresses storage interoperability, information assurance (security), storage transparency, long-term records retention and automation for Information Lifecycle Management (ILM)-based practices.
XAM looks to solve key cloud storage problem spots including;
- Interoperability: Applications can work with any XAM conformant storage system; information can be migrated and shared
- Compliance: Integrated record retention and disposition metadata
- ILM Practices: Framework for classification, policy, and implementation
- Migration: Ability to automate migration process to maintain long-term readability
- Discovery: Application-independent structured discovery avoids application obsolescence
Potential Future Additions to the API
* I/o
The virtualization of I/O resources is a critical part of enabling a set of emerging cloud deployment models. In large scale cloud deployments a recurring issue has the ability to effectively management I/o resources whether on a machine level or network. One of the problems a lot of users are encountering is that of the "nasty neighbor" or a user who has taken all available system I/o resources.
A common I/o API for sharing, security, performance, and scalability will need to be addressed to help resolve these issues. I've been speaking with several hardware vendors on how we might be able to address this problem. This will most like have to be done at a later point after a first draft has been released.
* Monitoring and System Metrics
One of the best aspects of using cloud technology is the ability to scale applications in tandem to the underlying infrastructure and the demands placed on it. Rather then just scaling on system load, users should have the ability to selectively scale on other metrics such as response time, network throughput or other metrics made available. Having a uniform way to interact with system metrics will enable cloud providers and consumers a common way to scale applications.
Security & Auditability.
In my conversations with several wall street CIO's the questions of both security and cloud transparency with regards to external audits has come up frequently.
---
My list of requirements is by no means a complete list. Cloud computing encompasses a wide variety of technologies, architectures and deployment models. What I am attempting to do is address the initial pain points whether you are deploying a cloud or just using it. A lot of what I've outlined may be better suited to a reference implementation then a standard, but none the less I thought I'd put these out ideas out for discussion.
-- Updates --
1. Looks like I've forgotten an obvious yet important aspect to my cloud standards. Authentication. Maybe something like OAuth or OpenID could form the basis for this as well. I'll need to do some more thinking on this one.
Labels: Cloud Computing, standards
posted by enomaly
at
12:32 PM
5 Comments :
Interesting. This is the most disruptive vision for cloud computing standards I have seen. It seems to me that the first step is likely to be to incrementally build on existing IT management standard to slowly bring in cloud concepts. Your proposal on the other hand is very natively cloud-like, which could make it a lot more powerful but also harder to mix with existing consoles, IT process management and app management tools...
FYI, I wrote a post on cloud standards some time back that is not earth-shattering by itself but received some very interesting and well-informed comments.
Yep, good list. I have a few more additional items in my blog http://doubleclix.wordpress.com/2008/08/21/the-standard-cloud/
This is an excellent baseline for a cloud *provider* standards effort. However, I argue that there remains a need to analyze cloud *consumer* architectures, and thus identify protocols required to allow applications to run smoothly in a cloud world, even one as highly defined as presented here.
Very informative and captures the main themes. We need to add a few things to this list.
a) Workload orchestration across clouds You can call it scheduling, goal based load balancing, cost based routing, etc..
I suspect that this would drive the adoption of clouds in more places than we can think of now. As it provide the ultimate "enduser" flexibilty. Hence I call it the cloud orchestrator aka "rain maker"
b) I am not a big believer in mixing data and software packages as a single thing. We should be exploring "software distribution" components in the cloud. Treating software as just another binary bits would lead to the the same "block headness" we come across day in and out.
c) Security as you point out is the key element to make the cloud to cross the "corporate boundary". Having an easy way to “secure data” and enable only known access points are key for a lasting model
d) Transparency in pricing/cost/penalty is important as it would dictate work load orchestrations.
e) Performance based SLAs are lacking at this point in “big picture”. The performance is still measured in “deployment units” like KB/s, mips, etc. We need this to be more “transactions per sec” or more meaningful metrics that are “application/use” based. I believe somebody already suggested this more eloquently.
This is a great thought exercise, but I'm wondering if some of these use cases can be tied to actual commonly requested requirements. In other words, is this premature standardization?
I'm a big believer in starting small and building to meet emergent use cases. At this point, there are only a few APIs that generalize even the most basic cloud services.
I'd love to have your opinion on this:
Should we start small and work up to these standards, putting simple APIs in to the hands of cloud users now?
Or should we standardize now in an effort to encourage enterprise cloud adoption and define a fully thought out architecture/protocols, possible delaying standardization efforts for months if not years?
,Wil
Post a Comment
Subscribe to Post Comments [Atom]
Links to this post :
Create a Link
<< Home