The last several days has seen two standardization-related events that I think are worth of note. Standardization, of course, is a critical element to creating fluid markets for compute, development, and application services in the cloud. There are several efforts already under way, including the Distributed Management Task Force (DMTF) Open Cloud Standards Incubator, the Open Grid Forum's Open Cloud Computing Interface working group, and the Storage Network Industry Association Cloud Storage Technical Work Group. A great resource to see the spectrum of cloud standards activity can be found at the OMG's cloud-standards.orgwiki.
The standardization effort that was officially announced this week is already listed on that wiki: the Open Group Cloud Work Group. In a press release, The Open Group, described the group's charter:
(T)he Group is being established to ensure the effective and secure use of cloud computing within enterprise architectures, based on open standards. The Open Group Cloud Work Group prioritizes collaboration on standard models and frameworks, aimed at enterprises looking to benefit from cloud products and services.
The Open Group Cloud Work Group was created to develop a common understanding between buyers and suppliers of how enterprises, regardless of size or scale of operation, can include cloud computing technology in a safe and secure way in their architectures to realize its significant cost, scalability and agility benefits. The newly-formed group includes some of the industry's leading cloud providers and end-user organizations and emphasizes customer input, drawing on The Open Group's global membership.
While that may sound pretty generic as charters go, the exciting element of this announcement was the availability of the group's first deliverable:
The first deliverable of the Cloud Work Group will be to publish a Business Scenario for Enterprise Cloud Computing, based on end-user requirements discussed at The Open Group's July Enterprise Architecture Conference held in Toronto. Business scenarios, an important technique that is fully explored as part of The Open Group's TOGAF(TM) framework, can be used at various stages of enterprise architectures to derive architecture requirements directly from high-level requirements for each business organization. The Enterprise Cloud Business Scenario will help companies identify and understand business needs relative to cloud computing and thereby derive the requirements that the architecture development must address. For more information on this report, please click here (PDF).
This document is a pretty well done list of the key benefits/concerns for cloud, and has a great quotable list of statements about cloud from a variety of enterprise participants.
The other effort that made itself public this week was Chris Hoff's call for participants in developing a standard for security assessment and management. The idea behind this API--codenamed the Audit, Assertion, Assessment, and Assurance API (A6)--is quite simple, as Hoff notes:
So I propose -- as I did to a group of concerned government organizations yesterday -- that we take this concept a step further, beyond just "vulnerability scanning."
Let's solve (both the question of vulnerability scanning of the cloud, and the challenge of auditing cloud services for contractual and compliance purposes) with one solution.
Specifically, let's take the capabilities of something like SCAP and embed a standardized and open API layer into each IaaS, PaaS, and SaaS offering (see the API blocks in the diagram below) to provide not only a standardized way of scanning for network vulnerabilities, but also configuration management, asset management, patch remediation, compliance, etc.
Krishnan Subramanian has an excellent overview of the effort. If you are a service provider looking to gain credibility regarding the security of your service, I would highly recommend getting involved in this effort.
While most readers probably think "portability or mobility" when they think of cloud interoperability, the vendor community sees a shorter-term opportunity in standardizing the operation of clouds and cloud infrastructures. It's not that vendors don't care about image portability; it is an especially critical opportunity for so-called "cloud operating system" vendors.
However, the cloud operations opportunity--building a full-featured operations API and user interface for a cloud--is a daunting task, requiring tools for provisioning, management and monitoring, among others.
(Note that I am calling the term "operations" tools, not "management" tools. It may seem like semantics, but when I published part 1 of this series, one of the systems management tools vendors quickly came back and said "hey, that's us!" Unfortunately, I'm not talking about monitoring and responding to problems with specific cloud payloads here, I'm talking about the interfaces you use to provision and control the clouds themselves. Of course, there is often overlap between the two concepts, just to make things...er...cloudier.)
In some ways, cloud operations interoperability is your basic API standardization story; allow several different independent management tools interact with several different independent cloud platforms and providers. Create a loosely coupled market dependency between the tools you use and the systems you manipulate with those tools. This is always a desirable goal in any open software marketplace.
However, there is a little more at stake here than simply enabling tools to be used across platforms. Consider this scenario: an enterprise has a distributed application system that runs components on two different major cloud provider infrastructures, relies on services running on two or three more, and stores data in their local data center. What would be the most desirable way to address the management of this system?
I would argue that you want as few "panes of glass" (i.e. disparate management applications) as possible, preferably one. To do that, you need standards that the single, all-encompassing management platform can rely on to access and manipulate all of the cloud platforms involved in the system.
In fact, you probably want to combine SOA and cloud management into a single pane of glass, so you probably want the standards to cover just about everything in the computing stack, from servers, storage and networking to specific application components and data stores.
Today, the focus is on providing a unified API for Infrastructure as a Service operations. In addition to standardizing how systems are provisioned, when they are active and what policies apply for situations like component failure or load spikes, it is also critical that this API unifies the way in which images are imported and exported from each provider's platform. A cloud operations API needs to cover as much of the system life cycle as possible, including provisioning and deployment.
There is so much effort being made in this space right now, by so many groups, that it is at times a little overwhelming. Luckily, I found a resource that has helped me organize not only the predominant operations API effort, but also the image/data and application/service interoperability classes. Believe it or not, it is a wiki dedicated to cloud efforts in the federal government market. (I'm telling you, the feds seem to be way ahead of the pack when it comes to organizing cloud activities these days.)
The wiki lists the following key efforts for "Governance and Management":
Management of Virtualized Resources - DMTF (http://www.dmtf.org/initiatives/vman_initiative/)
Open Cloud Standards Incubator - DMTF (http://www.dmtf.org/about/cloud-incubator)
SLAs -at SOI (http://sla-at-soi.eu/)
Compliance - Industry organizations (e.g. HIPAA, PCI) (http://www.hipaa.org/)
I was surprised to see three organizations missing from this list: the Cloud Computing Interoperability Forum (CCIF), the Open Cloud Consortium (OCC), and the Open Grid Forum's Open Cloud Computuing Initiative (OGF OCCI). It turns out the CCIF and OGF are acting more as organizing entities here, and the OCC is working standards around data and application interoperability, which I will talk about in part 4 of this series.
There is a "Cloud Standards Summit" planned for July 15th in Arlington, Va., that may clear further organize "who's doing what" in this space. I think the fact that such a meeting is taking place at all at this point is phenomenal. It is clearly an artifact of cloud computing's distinction as the first major IT disruption to take place in a world that assumes openness and transparency, thanks in large part to open source software.
As much as anything, cloud computing has borrowed from open source in terms of its governing principles, which could well be open source's lasting contribution to the cloud. It took a few decades of Microsoft dominance to really get the open-source movement in full swing, but it only took a few months for things like the Open Cloud Consortium to spring to life. Open source has taught us to expect openness by default. The cloud is no different.
John Willis of the IT Management blog is reporting that Reuven Cohen has created a new web site in support of the development and promotion of a Universal Cloud Interface. The concept, as Reuven reported today, revolves around some of the good work being done to address cloud taxonomy and ontology:
We are in a sense defining what cloud computing is by describing it's "components" and their relationships to one another. One that is capable of expressing cloud computing and its subsequent parts in terms of a consensus data model.
So in this effort we may actually be defining a dynamic computing model that can, under certain conditions, be 'trained' to appropriately 'learn' the meaning of related cloud & infrastructure resources based on an common ontology / taxonomy. In a sense, we are talking about the Semantic Web applied to API's or more broadly, a unified cloud interface.
The web site, created on the Google Code infrastructure, provides a central point for the definition and development of the UCI. Remember all that Simon Wardley has been saying about the need for open sourced standards? This is probably as good an example of a community supported effort as there is to date.
... Read moreThe Cloud Interoperability meeting prior to Cloud Connect in Mountain View, Calif., last week was a very interesting petri dish of some of the best and brightest in the cloud-computing marketplace.
There certainly was a quorum of companies represented (though Amazon.com couldn't make it at the last minute, and Microsoft never replied to the invitation). There also, as you might imagine, was no shortage of opinion on how to proceed.
As you might imagine in such a situation, most of the day was taken by attendees expressing their personal visions of cloud interoperability and standards building, only to boil next steps down to developing a taxonomy and sorting out a small list of the most pressing concepts to be explored. A wiki was proposed, and I will share the URL when I get it.
Here is the whiteboard at the end of the day (artistry courtesy of David Berlind, one of the founders of the event):
... Read more- prev
- 1
- next
