“Cloud” has become the latest love term that promises to provide IT services at much lower cost and with much higher agility.  However, there has been much debate in regards to the type of services a cloud provides and how it provides them.  Traditionally, networking folks have drawn clouds on network diagrams for conceptually representing transport services. Now-a-days anyone who touches (directly or indirectly) data center, virtualization, computing, networking, storage, security, provisioning, convergence, scaling, federation, software, hosting, infrastructure, platform, etc. etc. is on the cloud bandwagon. This “everything but the kitchen sink” approach undoubtedly has caused confusion as to what clouds really mean; a case in point is last week’s “What is a cloud?” article by Tim Green of Network World.

For a cloud services framework to be simple yet meaningful, two key categories come to the forefront:

• Cloud service type – infrastructure versus application: An infrastructure cloud service (aka infrastructure-as-a-service or IaaS) is the one where some portion of the IT infrastructure, such as compute, storage, programming, security, identity, etc., is offered as a service. This infrastructure service is an enabler for running end user applications. An application cloud service (aka software-as-a-service or SaaS), on the other end, is a self-sufficient soup-to-nut application offering to the end user, i.e. there is no additional IT effort and/or dependencies that an end user needs to address
• Cloud service usage – public versus private: A public cloud service can be subscribed by any end user (public at large) and is typically accessed through the Internet, e.g. using HTTP/HTTPS web protocols, and mostly via the web browser user interface. A private (or internal) cloud, on the other hand, is owned/controlled by a particular end user and hence its access restricted – e.g. through a campus network and/or through VPN tunnels.

The above Type x Usage framework forms a nice 2×2 analysis grid for evaluating cloud services.  Amazon’s Elastic Compute Cloud (EC2) service and Simple Storage Service (S3), for example, are public infrastructure cloud services, whereas Salesforce.com and Cisco Webex are public application cloud services.  Private clouds are not as prevalent today, though they are now being talked about more frequently; see the recent InformationWeek’s article on “Why ‘Private Cloud’ Computing Is Real — And Worth Considering“.  Bechtel, for instance, has been an early adopter of private clouds, even before the term “private cloud” was founded; see “The Google-ization of Bechtel” and “Cloud Computing to the Max at Bechtel“.

Based on discussions with several large enterprise customers and cloud providers, it seems that large enterprises would likely follow Bechtel’s lead:

• build their own private IaaS and SaaS clouds,
• scale private clouds’ reach/capacity by extending to hosted IaaS & SaaS,
• subscribe to public IaaS opportunistically for non-core infrastructure needs,
• convert internal applications to private SaaS,
• outsource certain enterprise applications to public SaaS.

Traditional SMEs, on the other hand, are more likely to gravitate towards public cloud infrastructure for most of their IT needs.

Certainly, it’s natural to expect blending of the above framework components. For instance, start-up SaaS providers often leverage one or more IaaS services (e.g. compute, storage, security). Similarly, a public cloud provider may instantiate their service for private use. In most scenarios, the above framework should be reasonably sufficient for describing cloud services.

Needless to say, the hypothesis will be tested more thoroughly when applying widely in subsequent cloud-related posts.

PG.