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-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.
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
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.
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?
10 comments for “A Service Taxonomy for Cloud Choices”