A Service Taxonomy for Cloud Choices

September 22, 2011

I have been talking with many CIOs for some time about strategic adoption of cloud solutions. A key step in these conversations is always the review of the portfolio of services they provide to business users, so they can choose which clouds to adopt and why.

This has led me to describe a high-level taxonomy that segments the service portfolio according to the different cloud requirements, capabilities, and approaches in different types of applications and services.

Essentially, this work has segmented most (all?) service portfolios into four areas, which (roughly) follow the adoption curve of cloud computing

Cloud Service Taxonomy

Cloud Service Taxonomy – Cloud-Free, Cloud-Migrant, Cloud-Native, and Rogue Cloud

Cloud-Free Services

For most of the large enterprises I talk to, some services will not be part of any cloud. These “cloud-free” services may migrate from physical to virtual, but do not need elastic scalability and self-service, are too impractical or incomprehensible, are too locked into non-commodity (e.g. z-Series) hardware, or are too sensitive or mission-critical to migrate to (especially public) cloud environments. With apologies to the “pure cloud” fantasists, it is a reality for many organizations, especially larger enterprises, many services will not be part of their cloud adoption plans – at least not soon, perhaps not ever. It is important to identify these “cloud-free” services.

With apologies to “pure cloud” fantasists, some services will not be part of the cloud

Cloud Migrant Services

As CIOs get a handle on cloud, they start proactively evaluating their service portfolio and migrating selected existing workloads – from the OS up – initially from physical to virtual, then to appropriate public or private cloud choices. These “cloud migrant” services are not fundamentally changed, as they simply “lift and shift” the same code, requirements, interconnections, users, data sources, etc. from traditional environments to (typically IaaS) clouds. Many benefits can accrue from running these services in a cloud – agility, flexibility, efficiency, cost reduction – but the services themselves are not specifically built in or for the cloud.

Cloud Native Services

As organizations embrace cloud computing, they start developing and using new “cloud-native”services built in the cloud and for the cloud. Mobile and social services, for example, really blossom when built on cloud-native characteristics like self-service, mobility, scalability, and “big data”, while cloud-native development also allows business ideas to “fail fast” or prove success with minimal upfront investment. Of course, rogue-cloud services (see below) can become cloud-native services when they move to ‘official’ production status; and SaaS applications are also cloud-native services, just delivered out-of-the-box by public providers.

Rogue Cloud Services

Rogue cloud can be very positive … there is no per se reason to shut it down.

In many organizations, business users or developers have adopted cloud already, outside of the normal IT procurement process. The term “rogue” may seem pejorative, but is not intended to be – I simply described a process that is outside of IT’s knowledge or control. As I wrote back in 2009, rogue cloud can be very positive, and there is no per se reason for IT should to shut it down. However, IT does need to establish visibility into rogue cloud to ensure security or compliance, avoid cost overruns, drive broader adoption of good cloud choices, or even to promote better cloud choices.

Why Does This Matter?

This segmentation came about not as an academic exercise, but to help CIOs with a taxonomy for service portfolio analysis and cloud choice. Each of these cloud service types has different needs, from both platform and management perspectives. By identifying cloud service types, a CIO can better adopt their choice of cloud as appropriate for different services at different times.

For example,

  • A cloud-native service can be ‘designed to fail’, whereas a cloud-migrant service needs additional management (e.g. real-time replication) to maintain the same level of continuity.
  • A cloud-migrant application that has been QA’d on a closed and proprietary hypervisor may need additional testing and QA before it can be moved to a different (or unspecified) hypervisor.
  • A rogue cloud service must be discovered before it can be managed as part of a whole portfolio, whereas a cloud-native or cloud-migrant service will be catalogued as it is deployed.
  • A cloud-free service needs none of the above, and specifically can fall outside the cloud portfolio and be exempt from new policies specifically designed to enable cloud services.
By identifying cloud service types, a CIO can better adopt their choice of cloud.

This segmentation is not meant to replace a thorough service portfolio analysis in making good cloud choices. In my session at VMworld 2011 in Las Vegas, for example, I presented analysis models from Visible Ops – Private Cloud, a CA Technologies quadrant framework, Forrester Research’s Evaluating Application Fit With Cloud model, and Freeform Dynamics’ model from Applied Cloud Computing: A practical guide to identifying the potential in your environment.

However, I do think it is a useful taxonomy to start making sense of your own service portfolio as you start to take stock of where you are in your cloud strategy, and where you want to go. So far, the CIOs I have worked with on this have agreed.

What do you think?

Tags: , , , , , , , , , ,

10 Responses to A Service Taxonomy for Cloud Choices

  1. May 16, 2012 at 21:02

    Well done, Andi!
    My hunch is as an organization matures in building native-cloud, they’ll start integrating some native-cloud features into legacy services that been migrated — essentially forming a 5th type, hybrid. In fact, it should be a design objective that each native-cloud feature set contain *some* reusable elements to help the legacy services migrate with gusto. 🙂

    @DanFarfan

    • May 16, 2012 at 23:52

      Thanks Dan, appreciate the comment. I agree, it makes a lot of sense that we should end up with a hybrid – just as we are with cloud services per se.

      Interesting idea on the ‘reusable elements’. Makes me think of OO coding, with the cloud providing some objects and the data center providing other. Do you think that open cloud APIs fit the bill well enough for your intent?

      Andi.

  2. Carter Shanklin
    May 16, 2012 at 20:00

    Nice taxonomy, though cloud-migrant and cloud-native are likely to be conflated as organizations increasingly adopt tools that let them automate provisioning and configuration of traditional app stacks on cloud (particularly IaaS). There’s a big difference between an app developed with assistance of a self-service Oracle provisioning thingie and an app is built to an actual cloud database. IOW self-service doesn’t magically transform you to cloud-native.

    • May 17, 2012 at 00:18

      Thanks for commenting Carter, nice to hear from you. I think that even with ‘lift and shift’ getting easier and faster through orchestration, these services are still cloud-migrant. The apps especially aren’t designed for failure, for scalability, for self-service, etc. Even dropping an existing app on a PaaS and I still think that is cloud-migrant.

      So they still need extra tools (e.g. replication, load-balancing) that a cloud-native service designed from the ground up for cloud would have built-in.

      But an app developed for a cloud infrastructure – even legacy infra automatically automatically deployed – yeah, I think that is cloud native. But really starting to blur the lines.

      That said, I think the idea of these terms being conflated over time is true. As Dan posted, we are probably looking, over time, at a hybrid model – just like cloud itself.

  3. Sebastian
    September 30, 2011 at 07:53

    Nice!
    Question? How do you know what Taxonomy Term apply in each case?
    Akamai for example is a Cloud Native Service? And Syslipe.com?

    Greetings!

    • September 30, 2011 at 15:58

      Thanks for the comment Sebastian.

      These descriptors are more how the application is (was) built, and what that means to a cloud-based deployment of that application (regardless of the service provider), than the delivery method or service provider you use to deliver it.

      So Akamai & Syslipe are Cloud Service Providers – you can use them for cloud-native applications or cloud-migrant applications. What I am describing is more about the design, than the delivery.