Monday, 13 June 2011

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

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

No comments:

Post a Comment