Meta

Cloud vs. Cloud – the state of definitions in 2015

When I started in the cloud industry over three years ago, I was first surprised to see that many conference presentations started with a cloud definition. I guess the terms were reasonably new and it made sense for everyone to take a minute or two to validate expectations (by contrast, those who didn’t share a brief definition often proceeded to confirm that they had no idea what they were talking about!).

“Back in those days”, a number of thoughts leaders reverted back to the NIST “5-legged stool” definition (still available online today as a PDF). To be able to claim the term “cloud”, you needed to have five key characteristics:

On-demand Self-Service

Broad Network Access

Resource Pooling

Rapid Elasticity

Measured Service

Move forward to 2015, and the issue is not so much that people don’t know what cloud is, but more that everyone thinks (and says) they have a cloud. So perhaps it’s time to update the five legs, for greater clarity.

Before we get into it, let’s put aside the SaaS models – although all vendors of hosted applications and/or storage now use the term “cloud”, at least everyone generally understands that we’re talking about software (gmail, salesforce.com, freshbooks, xero, basecamp are examples of popular tools to manage your business, all offered in pay-as-you-go models). [still, it continues to be frustrating to work with some of the leaders, such as salesforce.com, who now require one- to three-year agreements, removing any pay-for-what-you-need benefits…].

The confusing definitions (and claims) are much wilder on the infrastructure and hosting side, with everyone and their uncle claiming they now have a cloud – with various designations of “public”, “enterprise” and “secure” thrown in for good measure.

So here are the five redefined criteria – put them to the test as you select your next cloud vendor. For each category I list a few sample questions you can ask and/or warning signs.

Five essential characteristics of cloud, 2015:

Self-Service

Micro-allocation and billing

API-driven

Hypervisor-agnostic

Multi-services

1. Self-Service

This element is as important today as it was in the original definition. Recent studies have shown that although cloud is sometimes explored first for cost-reduction reasons, business agility is the reason why organizations continue to move to cloud services. Agile teams from fast-moving and innovating groups, such as software development and marketing, need instant access to infrastructure resources to test, iterate, innovate and maximize business value while reducing the cost of development.

The first “acid test” is the good old server provisioning question: can a developer launch their own virtual instance (and services) in minutes?

Any solution that requires IT to control resource allocation is not worthy of the name. That doesn’t mean it needs to be a free-for-all. IT needs to redefine its role from “managing servers to managing services” – it can set templates, define service catalogs, set quotas, but self-service is a must.

2. Micro-allocation and billing

An other important difference between cloud and hosting is the level of granularity of the billing, along with your ability to stop and start using the service at any point.

In a cloud environment, you typically pay by the hour, with an ability to stop and start services as you need. Some examples are business specific (for example seasonal e-commerce sales or batch processing) but others are more universal – for example many software firms automatically turn off development, test and QA environments at night and on week-ends to save on costs.

Test: if you are billed in monthly increments of service, you are missing on a significant portion of the cloud value (of course, clouds will only “invoice” you monthly, but for the total of hourly-consumed services).

3.API-driven

Application Programmers Interfaces (APIs) are calls you can make to a software application with specific instructions on what tasks to perform. Since cloud provides that layer of software on top of the infrastructure, it’s now possible to communicate with your infrastructure directly through an API call. For developers, this is a very natural way to work and communicate with systems – this now means they can interact with their infrastructure in a very comfortable and efficient way.

APIs can be used in many ways. Simple status updates can be obtained by querying the API. More advanced functions can include auto-scaling (the automatic provisioning of new services when certain metrics are met) and fault-protection (actions to take when certain events are triggered).

So ask the question: can I interact with my cloud services through an API?

4. Hypervisor-agnostic

It is generally understood that cloud is really about abstracting virtual services to another layer, to enable for automation and orchestration. This is the same phenomenon that happened over 10 years ago when virtualization was launched. Before virtualization, most software would run directly on bare metal servers. IBM, Dell and HP were key players in building your IT infrastructure, and making decent margins. Vmware, as one of the early leaders, enabled customers to run software on a virtual layer, abstracting the hardware. Effectively, you were now focusing on running your applications on Vmware, and the name on the box mattered a whole lot less (which enabled Vmware to capture great margins, while the pure hardware vendors saw a lot more commoditization and margin pressure).

The same thing is happening today. “cloud” is a software layer that abstracts the hypervisor to a higher level. What’s important for you is that you can launch Linux or Windows instances. As in the virtualization example, in the cloud era the cloud software becomes the key differentiator, and the hypervisor gets buried to a lower layer.

Test your vendor: if your vendor is naming a particular hypervisor in their offer (e.g. a “Vmware cloud”, a “Hyper-V” cloud) then you are still looking at some form of hosting, and are limiting any additional automation or orchestration from a cloud layer.

5. Multi-services

Last but not least, cloud is about a lot more than instances. For example, leading cloud provider has over 40 different service offerings, of which “virtual machines” is only one – Elastic Cloud Compute, or EC2. Other services include storage options such as object storage, database-as-a-service, and a number of scripting and automation platforms.

Ask the question: in addition to virtual instances, what other cloud services do you offer?

So here your have it – the new five criteria for cloud services, with key questions to have. Happy shopping.