Service-Oriented Cloud Computing Infrastructure (SOCCI) Framework – Introduction

 

Infrastructure is a foundational element for enterprise architecture. Infrastructure has been traditionally provisioned in a physical manner. With the evolution of virtualization technologies and application of service-orientation to infrastructure, it can now be offered as a service.

Service-orientation principles originated in the business and application architecture arena. After repeated, successful application of these principles to application architecture, IT has evolved to extending these principles to the infrastructure.

Thus, came about the concept of Infrastructure as a Service (IaaS).

An enabling framework of a well-defined, integrated set of service-oriented components is essential for infrastructure to be provided as a service.

Service-Oriented Cloud Computing Infrastructure (SOCCI) is the realization of this framework for the cloud. This document details the SOCCI elements, the synergies realized through the cohesive application of SOA and cloud-based principles, and the SOCCI Management Building Blocks. It expands upon the relationships between service-orientation and its application to various infrastructure components. Finally, the concepts outlined are explained in the context of a business scenario – Motor Cars in the Cloud.

Target Audience

The target audience for this specification includes a number of different communities:

  • Executive sponsors for The Open Group Service-Oriented Architecture Work Group as well as The Open Group Cloud Computing Work Group
  • Architects including enterprise architects, SOA architects, and infrastructure architects
  • IT strategists and lead designers
  • Standards organizations as a foundation for other standards and to apply to industry domains

Value Statement

A recent analysis of cloud computing in the Economist stated that there were a plethora of data centers worldwide and estimated that 7,000 data centers existed in America alone. Most of these data centers were one-off designs that had grown over the years. Many surveys show that these data centers are highly inefficient [1]. According to a study by McKinsey (a consultancy) and the Uptime Institute (a think tank), on average only 6% of server capacity is used. Nearly 30% is no longer in use at all and many organizations are unaware of which application is running on which server. This has created tremendous waste and impact on the environment [2]. Additionally, the economic turmoil and globalization have mandated that organizations cut costs and promote their human and financial resources on processes that can rapidly and easily be automated and managed. There are downsizing and rightsizing options to cut cost and be agile, which lead to the cloud-sizing solution.

The process of replacing existing in-house services and resources with cloud-based resources and services holds many benefits, such as lower costs, scalability, flexibility, freedom from software maintenance, and pricing structures that are a continuous expense rather than a larger up-front capital expense. Additionally, a cloud-based solution can promote accelerated business growth through server utilization optimized in real time, improved availability of data, and reduced power consumption. Given the potential benefits that cloud computing might bring to the business, it has become the latest technology buzz. The rapid adoption of distributed server virtualization is accelerating the deployment of high-utilization virtual machines. The relationship of a virtualized infrastructure to cloud computing has recently attracted a multitude of cloud vendors to the market, creating confusion for the consumers about the options available to them and the choices they need to make to derive the benefits of cloud computing for their business.

In order to consume and use cloud computing resources to their best advantage, it is incumbent upon business owners and executives, IT managers, start-up founders, and senior developers to understand the options that cloud computing provides. Additionally, there are also many perceived and some real risks associated with cloud computing which need to be carefully evaluated prior to adoption. To provide insight and clarity on cloud infrastructure, this specification:

  1. Defines an open, industry-standard, service-oriented, and vendor-neutral reference framework for cloud computing infrastructure that a variety of cloud users can leverage and benefit from
  2. Specifies the architecture building blocks that enable the framework
  3. Supports various user viewpoints from consumer, provider, and integrator perspectives
  4. Provides real-life scenarios that support SOCCI

Terminology

Can

Describes a permissible optional feature or behavior available to the user or application. The feature or behavior is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.

Implementation-dependent

(Same meaning as “implementation-defined”.) Describes a value or behavior that is not defined by this document but is selected by an implementer. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence of the value or behavior. An application that relies on such a value or behavior cannot be assured to be portable across conforming implementations. The implementer shall document such a value or behavior so that it can be used correctly by an application.

Legacy

Describes a feature or behavior that is being retained for compatibility with older applications, but which has limitations which make it inappropriate for developing portable applications. New applications should use alternative means of obtaining equivalent functionality.

May

Describes a feature or behavior that is optional for an implementation that conforms to this document. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations. To avoid ambiguity, the opposite of “may” is expressed as “need not”, instead of “may not”.

Must

Describes a feature or behavior that is mandatory for an application or user. An implementation that conforms to this document shall support this feature or behavior.

Shall

Describes a feature or behavior that is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.

Should

For an implementation that conforms to this document, describes a feature or behavior that is recommended but not mandatory. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations. For an application, describes a feature or behavior that is recommended programming practice for optimum portability.

Undefined

Describes the nature of a value or behavior not defined by this document that results from use of an invalid program construct or invalid data input. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior cannot be assured to be portable across conforming implementations.

Unspecified

Describes the nature of a value or behavior not specified by this document that results from use of a valid program construct or valid data input. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior cannot be assured to be portable across conforming implementations.

Will

Same meaning as “shall”; “shall” is the preferred term.