Blog post

U.S. Government’s Flavors of Cloud Computing Need More Clarity

By Andrea Di Maio | May 20, 2009 | 4 Comments

cloud

On May 13th the General Services Administration (GSA) with the IT Infrastructure Line of Business (ITI LoB), issued a Request for Information for capability statements and responses from vendors who provide Infrastructure as a Service (IaaS) offerings.

This RFI contains definitions of cloud computing, its characteristics and delivery models, taken from recent work done at the National Institute of Standards and Technology (NIST). Based on these definitions, the RFI asks vendors questions on:

  • Business Model, Pricing Model and Service Level Agreement
  • Operational Support
  • Data Management
  • Security
  • Interoperability and Portability

Questions are relatively sensible, although broadly scoped in places. However there are potential problems with the working definition of cloud computing that NIST has proposed and GSA has adopted and that may generate some confusion among users and vendors.

Let’s start with the actual definition:

Cloud computing is a pay-per-use model for enabling available, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is comprised of five key characteristics, three delivery models, and four deployment models.

This emphasizes pay-per-use pricing model and availability, but not fundamental aspects like scalability and elasticity aspects, nor the service orientation and the use of Internet technologies.

The five characteristics are: (1) On-demand self-service, (2) Ubiquitous network access, (3) Location independent resource pooling, (4) Rapid elasticity (yes, it is in) and (5) Pay per use.

The delivery models are (1) Cloud Infrastructure as a Service (IaaS), (2) Cloud Platform as a Service (PaaS) and (3) Cloud Software as a Service (SaaS). This is a coarser grain classification than the one we use at Gartner, where we look at six categories of services delivered from the cloud (see Cloud Computing Services: A Model for Categorizing and Characterizing Capabilities Delivered From the Cloud – subscription required).

While at this early stage the differences above are not critical , things become really difficult when looking at the four deployment models.

The first one is private cloud, which is defined as follows:

Private cloud. The cloud infrastructure is owned or leased by a single organization and is operated solely for that organization.

According to this definition it is likely that even a single, decently virtualized data center owned by an agency would qualify for being a “private cloud”, But would it be scalable and elastic enough to really provide the kind of services one would expect from a cloud infrastructure? It would be probably better to name this “single-tenant infrastructure as a service”.
Further this definition assumes that the infrastructure is operated by the user organization itself: but what if it is outsourced? And to what extent does it overlap with IT infrastructure utility services that a vendor could provide to a variety of users, providing each of them with the perception of a private cloud?

The second one is community cloud, which is defined as follows:

Community cloud. The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations).

This is what we at Gartner call a private cloud. In our definition,  a private cloud implementation has a bounded membership which is exclusive (i.e. only approved members can participate and approval is contingent on some characteristics). This fit the “community” definition above, where membership is limited to government organizations, presumably from the same or closely related jurisdictions.
Also in this case there is confusion about alternative sourcing strategies. Organizations in the community may use the infrastructure and have it sourced to one of them, or a cluster, or an external provider. To what extent would these differences impact the capabilities explored with this RFI?

The third one is public cloud, which is defined as follows:

Public cloud. The cloud infrastructure is owned by an organization selling cloud services to the general public or to a large industry group.

Here mentioning a “large industry group” suggests that membership would be bounded, so there is potential ambiguity between this cloud being really public or community.
Once more, the sourcing angle is not crystal clear. Could a public cloud be run by a government organization? If so, what would be the capabilities that such an organization would be looking for in a vendor?

The last one is hybrid cloud, which is defined as follows:

Hybrid cloud. The cloud infrastructure is a composition of two or more clouds (internal, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability

This last deployment model reinforces the impression that there is confusion between users and suppliers of cloud services.
An agency that decides to use different deployment models may source its infrastructure requirements through a combination of private, community and public cloud: one would call this “selective sourcing” and the outcome would be that the agency uses a hybrid cloud.
On the other hand, a provider may decide to offer infrastructure services hosting workloads on different clouds and offer its services with complete location-independence: in this case the provider would be using a hybrid cloud but for clients this would look like a public cloud.
Or the provider may have a service catalogue allowing clients to choose on which specific cloud they want their data and workloads, in which case they would be looking at a hybrid cloud.

It seems to me that these definitions do not help achieve the level of clarity that would be required for prospective users as well as actual and prospective providers to understand each other.

A crisper definition of cloud attributes, focused on scalability and elasticity, and a simpler definition of private cloud based on limited membership, would have been more effective.

Besides alternative definitions, it is imperative that the sourcing challenges behind cloud computing in government are clearly understood. While the global-class public clouds that commoditize most infrastructure resources are the reference model here, every other single deployment model will present challenges that governments have faced for years with outsourcing, selective sourcing and – especially – shared services,

Cloud won’t make them any easier.

Comments are closed

4 Comments

  • I forgot to mention something else that the RFI says about deployment models:
    “Each deployment model instance has one of two types: internal or external. Internal clouds reside within an organizations network security perimeter and external clouds reside outside the same perimeter”
    This is also a bit confusing, isn’t it?
    A public cloud within a single government organization’s perimiter? This looks lile government competing with Google and the likes…
    And how can a hybrid cloud be totally internal?

  • Jay Heiser says:

    Perhaps the problem is that ‘cloud’ is too nebulous a concept to ever pin down. It is a metaphorical usage. How can anyone be surprised that no two attempts to neatly taxonomize a figure of speech result in the same list of sub-metaphors?

    Its time to stop overloading the term ‘cloud’, and to concentrate on specific functional and service level requirements, and ways of doing that.

    If you want to buy a cloud, you should expect that you’ll get something that is difficult to hold onto.

  • Jay Heiser says:

    Perhaps the problem is that ‘cloud’ is too nebulous a concept to ever pin down. It is a metaphorical usage. How can anyone be surprised that no two attempts to neatly taxonomize a figure of speech result in the same list of sub-metaphors? This is poetry, not technology.

    Its time to stop overloading the term ‘cloud’, and to concentrate on specific functional and service level requirements, and ways of doing that.

    If you want to buy a cloud, you should expect that you’ll get something that is difficult to hold onto.

  • Christian says:

    There’s an interesting company in Banagalore India – founded by an ex-Sun employee which delivers cloud apps to over 200 municipal governments all across India. And it’s free!

    http://www.egovernments.org/products.htm

    Why can’t we build something like that here?