NIST Cloud Computing Reference Architecture

I see NIST have now published their Cloud Computing Reference Architecture as a recommendation. Little has changed conceptually since earlier drafts, but the document is now more detailed and complete.

In earlier commentary on Cloud Computing Reference Architectures, Models and Frameworks I described how there is little concensus on what form a reference "thing" should take or what its content should be, and that most are a mish mash of concepts that have their own structure, but not a consistent structure that enables them to be easily combined or compared for example.   The NIST Cloud Computing Reference Architecture is no different in that respect.

However, it is still a worthy document, and as with earlier NIST output that laid out definitions for core cloud computing concepts such as SaaS/IaaS/PaaS, the reference architecture is bound to be widely referenced as a "standard".

The Service Oriented Cloud

Cloud Computing is intrinsically service-based. But this is not just in the highly generalized sense of the term ‘service’, but also in the more specific Service Oriented Architecture (SOA) use of the term, where capabilities are provided via published service interfaces. When Amazon CTO Werner Vogels describes the Cloud as "a collection of services", in AWS terms the capabilities provided are SOA-style software services, complete with published Web Service interfaces.

As well as the PaaS and IaaS capabilities provided by AWS or Microsoft's Azure for example, there are also SaaS capabilities provided by the likes of salesforce.com that can be consumed as software services.

Hence the concept of the Service Oriented Cloud (SOC)  illustrated below.

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.

Trialing Microsoft Office 365 Beta

Currently trialing the Microsoft Office 365 Beta. It seems tailored made for small businesses like us. Like many small businesses, we already rely on several disparate hosted services such as email, a SharePoint for collaboration, Skype, Webex, plus some use of Google Docs, and so on, all of which are supplied by different providers, resulting in incompatibilities, lack of integration, multiple signons, etc.
Bringing together all these capabilities under one roof seems attractive. It will also help to ensure everyone is using Office 2010 (no more need to save as 2003!).
Will update as we use it more.

Everware-CBDI plays key role in developing ACT-IAC white paper on Enterprise Architecture and Cloud Computing

Under the auspices of ACT-IAC’s Enterprise Architecture SIG, my colleague Dave Mayo, the President of Everware-CBDI, has led a team in the development of a white paper explaining the role of EA in Cloud Computing.  The paper explores architectural issues, management issues and tools for decision making regarding cloud deployments.  The fundamental finding is that the prerequisite to success with cloud computing is the establishment of a Service Oriented Architecture that identifies the services deployed to the cloud and how they may be accessed.

Click to access the White Paper on the ACT-IAC website. (Word)
or view as HTML on the Semantic Community

Windows Azure - Making Migration to the Cloud Seamless?

This week I attended a Microsoft UK Tech Days (a sort of local version of TechEd) on building and deploying applications onto the Windows Azure cloud platform.  In typical TechEd style, once a few positioning slides had been quickly dispensed with it was down to business with a deep dive into the code and admin tools.  Though my day job isn't as a professional developer, as a consultant and architect I like to know enough about how these things really work.

I came away impressed with just how seamless they are making the migration of applications to the cloud.

Cloud Computing. Are Utility and Cloud Computing really analogous to traditional utilities?

The analogy is often made between utility computing and other ‘traditional’ utilities such as electricity, gas, water, and telephone. The same analogy is now being made with cloud computing. At a high level this makes sense. In the same way there is no need for each individual or company to operate their own power plant, do they really need to operate their own computers? Why invest in the capital equipment to provide a computing capability if it can be piped into the premises and purchased ‘on demand’? The opportunities for economies of scale, the centralization of expertise, increased reliability and scalability all make perfect sense.

However, as Nicholas Carr also recognizes in his book “The Big Switch”, analogies often break down once you move to another level of detail as highlighted in the table below. Here we need to understand the difference between the utility (e.g. electricity) and the application of that utility (e.g. cooking).

Making Sense of Cloud Computing

The terms virtualization, utility computing and Cloud computing are often used interchangeably which can be very confusing. A new report I have just authored aims to provide clarification - to identify the similarities and differences in those characteristics, and provide a framework in which organizations can decide which capabilities they require in specific situations – as it is unlikely that one model alone will suit all their requirements.
A visitor from outer space would be forgiven for thinking that virtualization, utility computing and Cloud computing are different capabilities. But most of us understand that many product and service offerings use the terms rather casually and the trend is to assume they are all describing the same thing, where virtualization is synonymous with utility computing which is synonymous with Cloud. Some might say these are just steps in the evolutionary process – where utility has simply evolved into Cloud.
So, are they the same or different? Can the terms be used interchangeably, or are there clear distinctions between them?

The answer is not straightforward. There are clearly some common, overlapping characteristics that allow the terms to be used interchangeably. But at the same time there are other characteristics that enable them to be distinguished from each other.

The report aims to provide clarification. To identify the similarities and differences in those characteristics, and provide a framework in which organizations can decide which capabilities they require in specific situations – as it is unlikely that one model alone will suit all their requirements.

Service Portfolio Planning and Architecture for Cloud Services

The concept that Services are provided ‘somewhere in the cloud’ has always been central to our vision of SOA and we often used the cloud metaphor to illustrate this. Some 15 years ago in our early CBD research at Texas Instruments Software we presented the notion of application solutions assembled from a ‘cloud of services’ though this was positioned more as a way to achieve technology independence as the notions of a public infrastructure provided in the cloud were not well developed then.

The arrival of Web Services at the turn of the millennium provided a standardized mechanism by which location independence could be added and at that time we began presenting ideas like this, entitled "Does it matter where Services are Located?" - though in 2001 we will admit the audience was often more than slightly skeptical about the idea!

Does it matter where Services are Located?

Whilst there is now a high level of convergance throughout the industry on classification of Cloud Services as Software as a Service (SaaS) or Infrastructure as a Service (IaaS), as concepts such as Public, Private or Community Clouds, these generalized terms can be a bit misleading and vague when it comes to producing a more exact model of the Service Architecture. What exactly is the type of capability being offered by a Service? Who exactly is playing what role in the Service Supply Chain?

So, in the free report I have published in our CBDI Journal this month, I set out to show how our CBDI-SAE approach can be used and extended to architect for Cloud Services. The current guidance has been extended with new and refined classification systems, diagrams, policy types and techniques designed to promote visibility and good governance over Service Portfolio Planning activities and Cloud Services provisioning.  (see also the slideshare following the 'read more...')