Many people confuse “using a hardware and software stack that potentially enables a cloud” with “cloud infrastructure as a service”. Analyst firms haven’t necessarily done a good job with drawing the distinction, either — there are plenty of (hopefully non-Gartner) analysts who use “IaaS” interchangeably to describe the technology stack and the service itself.

The technology stack — typically an integrated system (such as a Vblock) plus a cloud management platform (such as vCloud Director), although it could be anything, like whitebox servers + Nexenta storage + Arista switches + OpenStack — is what Gartner is now dubbing “cloud-enabled system infrastructure” (CESI). This is admittedly naming-by-committee, but it parallels our use of “cloud-enabled application platform” which is the technology-stack corollary for PaaS.

Why is it important to make a distinction between CESI and IaaS? Because while CESI can be used to deliver IaaS, there are many services that can be delivered on top of a CESI that are not IaaS. Gartner’s cloud definitions are pretty strict, and one of the cores of our IaaS definition is that IaaS is self-service — you can optionally layer managed services on top, but the customer has to have full control to obtain and remove resources in a fully self-service, fully-automated way. Not only are many of the services that can be delivered on CESI not IaaS, they’re not actually cloud services — cloud requires not only self-service, but also scalability, elasticity, and metering by use, for instance.

Why does this distinction matter? Because there are a significant number of service providers in the market today who offer a service on top of a CESI and call it “cloud IaaS”, when it’s neither cloud nor IaaS, and it misleads customers into thinking that they are getting the technical and/or business benefits of going to the cloud and going to IaaS.

I’ve written two research notes that I’m hoping will cut through some of the market confusion. (Links are Gartner clients only, sorry.)

The first, Technology Overview for Cloud-Enabled System Infrastructure, is an overview of how we define CESI and how it is not merely a virtualization environment — it encompasses compute, storage, and network capabilities; it is automated, scalable, elastic, near-real-time on-demand; and it exposes self-service interfaces. It discusses the range of cloud-enabled infrastructure services from those that are merely cloud-facilitated (using the CESI as an efficient infrastructure platform, without exposing it to the customer via self-service), to those that are fully cloud-native (CESI fully exposed to customer via self-service that is routinely used), and gives examples of the services along this spectrum; for instance, IBM’s SCE+ is cloud-enabled data center outsourcing, not IaaS, in our parlance. Finally, it disusses the distinction between global-class CESI architectures (think Amazon Web Services) and enterprise-class architectures (think Vblock + vCD), and how to build a CESI.

The second, Don’t Be Fooled By Offerings Falsely Masquerading as Cloud Infrastructure as a Service, is a note that is intended to help IT buyers figure out what they’re really buying when they are assessing something that the vendor is claiming is IaaS. It focuses on a handful of principles: Beware of common “cloudwashing” claims; ensure that what you’re buying delivers promised technical and business benefits; identify your requirements and look at competing providers before purchasing a solution that requires a contractual commitment; favor providers who have better cloud infrastructure roadmaps.

The four most common “cloudwashing” claims for infrastructure services:

• “It uses virtualization, so it’s a cloud.”
• “It’s being delivered on a Vblock, so it’s a cloud.”
• “We use vCloud Director, so it’s a cloud.”
• “You can buy it through a portal, so it’s a cloud.”

I apologize for introducing more jargon into an already jargon-heavy corner of the market, but I think these distinctions are critical: You can have a technology stack that potentially enables you to deliver cloud IaaS… and use it to deliver something that is neither cloud nor IaaS. Cloud infrastructure as a technology platform is separate and distinct from cloud infrastructure as a service; the technical construct and the service construct are two different things.