Cloud Computing Reference Architectures, Models and Frameworks

There are a plethora of different reference architectures, models and frameworks for Cloud Computing (CC). As well as several vendors such as IBM or CISCO, it seems every standards or industry body has to have their own reference "thing" too. Hence there are architectures from DMTF, CSA, SNIA and the Open Group (which has been submitted by IBM) as well as several seemingly competing federal initiatives.  NIST, who have established the de facto definitions of CC and the service and deployment models also have a draft CC Reference Architecture.

So which one should an organization adopt? Of course there’s no straightforward answer to that question and so I have published a research note on Everware-CBDI to provide guidance on how to organize some of the best ideas that are emerging in a practical structure that should stand the test of time.

Reference ‘Things’

A Reference Architecture (RA) “should” provide a blueprint or template architecture that can be reused by others wishing to adopt a similar solution. A Reference Model (RM) should explain the concepts and relationships that underlie the RA. At Everware-CBDI we then use the term Reference Framework (RF) as a container for both. Reference architectures, models and frameworks help to make sense of Cloud Computing.

Unfortunately, such formality is absent from the various reference architectures, models and frameworks that have been published for Cloud Computing; these frequently mix elements of architecture and model, and then apply one of the terms seemingly at random.

In developing the CBDI-Service Architecture and Engineering Reference Framework (SAE) in support of SOA (Service Oriented Architecture) Everware-CBDI separated out various parts as shown in figure 1. We developed a detailed RA for SOA and a RM for SOA, with particular emphasis on a rich and detailed Meta Model for SOA and a Maturity Model for SOA. We also developed a detailed process and task decomposition for SOA activities.

But the RF is easily generalized, as shown in figure 1, where the various elements could be applied to any domain, and explicit references for example to “SOA Meta Model” or “SOA Standards” etc., can be removed.

Figure 1 – Generalized Reference Framework

The benefit of this approach is that elements of the framework can then be mapped to each other in different ways to support alternative perspectives such as different usage or adoption scenarios, or the viewpoint of an individual participant or organization.  Whereas most of the Cloud Computing Reference architectures, models and frameworks proposed today apply to a single perspective.

Current Cloud Computing Reference Architecture, Models and Frameworks

As discussed there are many frameworks and models to choose from. It is not our intention to detail and critique them all individually. Credit must go to  NIST who have already done much of that in their 2010 Survey of Cloud Architecture Reference Models.

We may classify Cloud reference models as one of two styles, either

• Role-Based. Where activities or capabilities are mapped to roles such as cloud provider or consumer. For example,
• DMTF Cloud Service Reference Architecture
• IBM Cloud Computing Reference Architecture (which has been submitted to the Open Group)
• NIST Cloud Computing Reference Architecture
• Layer-based. Where activities or capabilities are mapped to layers in an architecture such as application or resource layers or to the service management architecture or security architecture
• Cloud Security Alliance Reference Model is one of many layered models showing the cloud ‘stack
• CISCO Cloud Reference Architecture Framework is an architecture of architecture, placing Cloud on top of layers of Service, Security and Technology architectures
• IEFT Cloud Reference Framework goes into more depth, showing the capabilities for each layer.

Analysis of the these shows that they typically contain,

• Roles – that  would be better placed in the Organization section of an RF
• Activities – which would be part of the Process Model
• Layered Architecture – which would be part in the Reference Architecture

Used this way, the generalized RF in figure 1 becomes a useful tool to analyze proposed Cloud Computing Reference architectures, models and frameworks in terms of understanding better what they actually contain, and a basis for development of an enterprise specific framework.

Continued in Everware-CBDI Research Note - Cloud Computing elements placed in generic CCRF, mapping capabilities to roles, process to roles, and recommendations