Search this Blog:
IDC eXchange Home

Defining “Cloud Services” – an IDC update

Posted by Frank Gens on September 30th, 2009

cloud2010Last year, we published IDC’s “cloud services” definition, as the foundation for our forecast of IT Cloud Services spending – and to inject IDC’s point of view, as a rational market taxonomist, into a very crowded and confused debate about just what “the cloud” is all about.

After a full year of discussion and debate among key IDC analysts, We’ve continued to refine our thinking about what defines cloud services, and what makes them new and important.and conversations with hundreds of leading IT users and suppliers, we’ve continued to refine our thinking about what defines cloud services, and what makes them new and important.  The revised definition is very consistent with last year’s definition, with improvements in two areas: 1) minor tweaking of cloud service “key attributes” to improve clarity, and 2) expansion of the definitional scope to accommodate both public and private cloud deployment models.

What Are “Cloud Services”?

As we noted last year, “cloud services” are fundamentally about an emerging delivery/consumption model – one that can be applied to IT industry offerings (e.g., as in software-as-a-service (SaaS), and storage or server capacity as a service), but also much more broadly, to offerings from many other industries, including entertainment, energy, financial services, health, manufacturing, retail and transportation, as well as from government and education sectors.

At a high level, cloud services can be described simply and informally as:

Consumer and business products, services and solutions delivered and consumed in real-time over the Internet

This is a useful simplification for discussing cloud services with non-technical business people, but it is obviously too broad a description to capture what’s important: how the emerging cloud model dramatically differs from prior online offering models in ways that promise to fundamentally expand and transform markets. After all, online services have been around for a very long time – from the timesharing systems of the 1970s through the first generation of transactional Internet commerce sites. Thus, IDC’s formal definition of cloud services includes the following eight key attributes, that – in combination – differentiate cloud services from these other online delivery/consumption models:

cloud_attributes_updated_2009-thumb

CLICK IMAGE to ENLARGE

As we noted last year, the cloud services model, by leveraging all eight of these attributes together, “make business and consumer cloud services easier and cheaper – and often better – to consume than through traditional delivery modes. These attributes lower costs (for customers and suppliers), speed and simplify access, speed and fine-tune provisioning (in line with true demand/usage), greatly increase the number and variety of available services (thanks to lower development and deployment costs, and standards), and improve the potential to integrate.”

As we’ll discuss below, in the more detailed description of each attribute, some of these attributes may manifest to different degrees, or in different ways, in different cloud service categories (e.g., “self-service” for cloud applications vs. cloud storage), but for all categories of cloud service offering, there is an important common thread:  these attributes manifest in ways that offer major customer advantages compared with traditional delivery/consumption models.

Detailing the Eight Cloud Services Attributes

Here’s more detail on what each of these attributes means:

  • Shared, standard service – this is the most fundamental attribute of a cloud service, an attribute that is shared with the wide variety of previous-generation online services, and  the one that differentiates cloud services from many traditional, Cloud services are shared, standard services, built for a market, not for any specific customer.customer-unique outsourced or hosted offerings. Cloud services are shared, standard services, built for a market, not for any specific customer.  These services present themselves to users as “multitenant” offerings, although our definition – focused on the customer-facing aspects of cloud services – leaves room for service providers to use a variety of underlying deployment and architectural options.  The shared service model offers customers and suppliers both enormous operating efficiencies and upgrade/enhancement velocity. In a private cloud deployment, the IT department can be viewed as the cloud service “vendor”, offering a standard service within a single enterprise, or across an extended enterprise. [Last year, we referred to this attribute as "shared resources/common versions".]
  • Solution-packaged – one of the most obvious user benefits of the cloud service model is that it is “turnkey”: the customer can access the offering without the need to own, manage or understand any underlying resources required to support the offering. The Cloud Service Provider (Cloud SP) bears that burden, offloading it from the customer, making it much simpler and faster to adopt for customers. [Last year, we referred to this attribute as "minimal/no IT skills to implement".]
  • Self-service – cloud services allow customers self-service capabilities for service provisioning and administration. In the IT cloud services world, the range of self-service capability varies widely up and down the stack: in the infrastructure area (e.g., cloud storage, cloud servers), “click-to-buy” provisioning is widely available today, whereas much of the SaaS community lags here. While most SaaS vendors provide a lot of self-service administration, there is little “click-to-buy” provisioning simplicity and speed; some on-boarding and more complex customization functions typically require human intervention from the provider’s staff. IDC believes we’ll see SaaS vendors evolve in this area, providing more automation around self-service provisioning. Customer self-service is a key tool for providing greater operating efficiency, deployment speed and customer satisfaction.  [Last year, we referred to this attribute as "self-service requesting, near-realtime provisioning". This year we've expanded to address administration.]
  • Elastic scaling – another of the key benefits users often cite in the cloud services model is the ability to quickly scale resources to need – delivering speed and cost-efficiency benefits. This is an area, like self-service, where the way in which the attribute is manifested varies by type of offering. We can easily see the elasticity of compute and storage cloud services, but what about SaaS? SaaS offerings – while typically less “instantly scalable” than the infrastructure services – still look much more elastic to customers than the traditional on-premise model.We would argue that SaaS offerings – while typically less “instantly scalable” than the infrastructure services – still look much more elastic to customers than the traditional on-premise model, since increasing/decreasing resources (seats/subscriptions, and associated supporting resources – CPUs, storage, bandwidth) can happen much faster than traditional on-premise offerings. Once an application is provisioned on-premise, those resources/costs are on the balance sheet; scaling down is not easy at all, given the portion of capital remaining on the balance sheet, and increasing (beyond a marginal change) usually takes significant time to provision. [Last year, we referred to this attribute as "dynamic and fine-grained scaling".]
  • Use-based pricing – customers not only want services scaled to need, they also want them priced to use, whether that’s in proportion to usage, or to the number of users. As we noted last year, as a convenience to some customers, providers may mask this pricing granularity with long-term, fixed price agreements, but – to meet the cloud service definition – the supplier must design their offering so they have the capability to do fine-grained metering and pricing for customers who wish that. In a private cloud setting, some IT shops may take advantage of the fine-grained metering to support more detailed, usage-based chargebacks. [Last year, we referred to this attribute as "pricing model = fine-grained, usage-based (at least available as an option)".]

The last three cloud service attributes are related to the same thing: leveraging the power of de jure and de facto Internet standards – to reduce costs, increase reach and maximize interoperability and combinatorial value creation.

  • Accessible via the Internet – this means that cloud services are designed to leverage the most ubiquitous public network on the planet. For public clouds, this is a no-brainer:  it means services must be accessible to (authorized) users who have access to the Internet. The core benefit to both the service provider and customers is broad, simple and low-cost access.  Obviously this doesn’t mean that a public cloud service is unsecured and unreliable; Cloud offerings take advantage of the huge marketplace of security and QoS offerings that are building up around the public Internet.rather that the service provider (and customers) leverage security and QoS/availability mechanisms that are Internet-based (e.g. SSL, IP VPN, CDNs, etc.), and take advantage of the huge marketplace of security and quality-of-service (QoS) offerings that are building up around the public Internet. For most private clouds (see Public vs Private Cloud discussion below), this attribute will still be a key one, especially where employees are mobile; but we could envision very secure private clouds where access is restricted only through private IP networks.  We will also certainly see interesting use cases where public cloud SPs offer customers with high-bandwidth and/or security needs the ability to access the public cloud via private lines – one example of what will be many “mash-ups” of public and private cloud services.  [Last year, we referred to this attribute as "accessed via the Internet". We've expanded with the notion that a user may access a private cloud service over their organization's private IP network.]
  • Standard user interface (UI) technologies – to clarify, we’re talking here about the client and underlying technologies, not the visual layout of elements on the screen (or a device). Like the network access attribute above, this attribute is about leveraging Internet-related de jure and de facto standards and technologies that are widely-deployed – and typically service/application-independent – to give cloud SPs and their customers maximum reach and access to leading-edge innovation, at a very low cost. SPs should leave the client choice for users as “open” as possible, for both their own, and customers’, benefits.In the case of UI technologies, we are talking about Web browsers, as well as supporting technologies such as Ajax (asynchronous JavaScript, Dynamic HTML, XML), Flash, HTML, JavaScript, SVG, etc. Other service/application-independent clients – such as AIR – that sit outside the browser, but leverage the same de jure and de facto standard technologies, could also fit the bill as they become widely deployed on users’ devices. We are including de facto standards, so this attribute obviously has some degree of subjectivity to it. The core thought behind this attribute is this: SPs should leave the client choice for users as “open” as possible, for both their own, and customers’, benefits. [Last year, we referred to this attribute as "UI = browser and successors". We've expanded to include other service/application-independent, Internet technologies-based clients that may sit outside a browser.]
  • Published service interface/API – The ability to combine services with each other, and to integrate them with traditional, on-premise systems, is the foundation for being able to rapidly create – and, importantly, allow others to create – new solutions and value, and therefore a core element of modern cloud services. Published cloud service APIs transform online services from “islands” to high-leverage building blocks within large innovation communities and marketplaces. It’s already obvious that cloud SPs who do not offer open/published, programmatic interfaces – and thus fail to develop large ecosystems of solution developers around their services – will simply not be competitive. These APIs, and the ecosystems around them, will be the foundation for expanding suppliers’ market power.In our view, this is the brightest red line that separates first-generation online Internet offerings and cloud services. It’s no surprise that the first-generation Internet businesses that have become cloud leaders – Amazon, Google and eBay – were among the first of the first generation online/ecommerce providers to open up their services with APIs, and recruit huge developer communities. In the IT industry, many SaaS vendors have published services APIs (SOAP, REST, et al.) that allow customers and other vendors to access functionality within their offering; some expose a minimal number of controls, while others publish many. But it’s hard to imagine any successful SaaS (or any –aaS/Cloud) vendors not providing a way for their offerings to be leveraged for greater value by customers, and by their own ecosystems. These APIs and the ecosystems around them will be the foundation for expanding suppliers’ market power. The successful Cloud SPs will have APIs in some form as the market matures, while “walled gardens” will have a hard time being competitive in the cloud services space – think “AOL vs. the Internet”. [Last year, we referred to this attribute as "system interface = web services APIs".]

It’s worth repeating: the reason the cloud services model is worth defining (and researching) is that the combination of these attributes delivers a unique and powerful set of benefits (in bold above) for the industries and organizations that deploy and use these services.

Deployment Models: Public vs. Private Clouds

A major market development in the last 12 months has been the emergence of the idea that the very same eight attributes above – which have given public cloud providers like Amazon, Google, Salesforce.com and others great advantages in cost, speed , simplicity and value-creation velocity – can be applied to corporate data centers within a private (single-, or extended-, enterprise) setting. “Private clouds”, by definition, don’t have nearly the same reach and scale as public clouds, but they do offer significant improvements over traditional private deployment models.

And so our definitional framework for Cloud Services is now expanded to include these two deployment models:

cloud_definition_publicprivate_2009-thumbCLICK IMAGE to ENLARGE

As noted in the Cloud Services definition chart above, Public and Private models represent two ends of a deployment continuum, which we expect will frame a growing variety of models that mix aspects of both.

It’s important to note that the notion of private clouds didn’t just arise suddenly from public clouds, Private clouds are an evolutionary next step in CIOs’ decade-long efforts to transform their organizations into service-oriented IT delivery providers.but is really an evolutionary next step in CIOs’ decade-long efforts to transform their organizations into service-oriented IT delivery providers – what IDC has referred to for almost ten years as the journey toward “dynamic IT”.  Private clouds (and public clouds, for that matter) are built on the key elements of that transformational roadmap – consolidation, standardization, virtualization and automation – and add important new ingredients: turnkey packaging, self-service provisioning and administration, more granular and elastic scaling, granular usage metering and leverage of Internet standards and technologies.  For the past ten years, many CIOs have found the journey to dynamic IT, based on conventional offering approaches, very slow, difficult and costly.  We believe these new ingredients that private clouds add will help CIOs move much faster down the dynamic IT path.

Putting It All Together

Wrapping up, here’s a chart that puts these three elements – simple meaning, key attributes and the public/private deployment models – together into a single figure.

cloud_definition_updated_2009-thumb

CLICK IMAGE to ENLARGE

Bookmark this blog post:

  • del.icio.us
  • Digg
  • Facebook
  • Google Bookmarks
  • Live
  • Slashdot
  • SphereIt
  • Technorati
  • TwitThis
  • YahooMyWeb

10 Responses to “Defining “Cloud Services” – an IDC update”

[...] of cloud computing definitions (I like this one and this one), IDC has today published a very good “Cloud Services” taxonomy. Cloud Services are defined as, “Consumer and business products, services and solutions [...]

[...] (be sure to watch this recent Larry Ellison rant on the topic), IDC has just published a very good “Cloud Services” taxonomy. Cloud Services are defined as, “Consumer and business products, services and solutions [...]

[...] to businesses and there is significant interest in learning about these offerings. This week IDC updated their definition of cloud services and they did a great job of explaining the attributes you can expect from a company with these [...]

[...] details his definition a bit more here….and I can’t help but love the data IDC is so well know for with Cloud Service Revenue [...]

[...] more and more important to understand what exactly are “Cloud Services”? Broadly defined by an IDC analyst, Cloud Services are “consumer and business products, services and solutions delivered and [...]

[...] ^ Defining “Cloud Services” – an IDC update [...]

[...] figures represent revenues for offerings delivered via the cloud services model in five major enterprise IT [...]

My opinion is that cloud (or public cloud) means the whole internet, clould service means all internet web service, and cloud computing means a kind of cloud service which supply IT resource capacity

[...] Hot Startup With It (www.businessinsider.com) Amazon Enters PaaS with Beanstalk (www.infoq.com) Defining “Cloud Services” – an IDC update (idc.com) Cancel [...]

[...] To learn more about how IDC defines cloud services click here. [...]

Post a Comment


About IDC | Contact IDC | Privacy Policy | Site Index | Reprints | Worldwide Offices | Objectivity
Copyright 2005 IDC. Reproduction is forbidden unless authorized. All rights reserved. Trademarks | Terms of Use