I’ve been “in cloud” for over 13 years (@dmcrory and I submitted patents using it starting in 2001) and I’m continually amazed at how complicated people want to make it.
For my role at Dell, I’m continually invited to seasons of meetings to define cloud, cloud architecture and cloud strategy. The reason these meetings go on and on is that everyone wants to make cloud complicated when it’s really very simple.
Cloud is infrastructure with an API.
That’s it. Everything else is just a consequence of having infrastructure with an API because API provides the ability to provide remote control.
What else do people try to lump into cloud? Here are some of my topic cloud obfuscators:
- (inter)network. Yes, networks make an API interesting. They are just an essential component but they are not cloud. Most technologies are interesting because of networks: can we stop turning everything networked into cloud? Thanks to nonsensical mega-dollar marketing campaigns, I despair this is a moot point.
- as-a-service. That’s another way of saying “accessible via an API.” We have many flavors of Platform, Data, Application, Love or whatever as a Service. That means they have a API. Infrastructure as a Service (IaaS) is a cloud.
- virtualization. VMs were the first good example of hardware with an API; however, we had virtual containers (on Mainframes!) long before we had “cloud.” They make cloud easier but they are not cloud.
-
pay-as-you-go (service pricing). This is a common cloud requirement but it’s really a business model. If someone builds a private cloud then it is still a cloud.
- multi-tenant. Another common requirement where we expect a cloud to be able to isolate users. I agree that this is a highly desirable attribute of a good API implementation; however, it’s not essential to a cloud. For example, most public clouds do not have true network isolation model.
- elastic demand. IMHO, another word for API driven provisioning.
- live migration. This is a cool feature often implemented on top of virtualization, but it’s not cloud. We were doing live migrate with shared storage and clusters before anyone heard of cloud. I don’t think this is cloud at all but someone out there does so I included it in the list.
- security. Totally important consideration and required for deployments large and small, but not presence/lack does not make something cloud.
We start talking about these points and then forget the whole API thing. These items are important, but they do not make it “a cloud.” When Dave McCrory and I first discussed API Infrastructure as “cloud,” it was driven by the fact that you could hide the actual infrastructure behind the API. The critical concept was that the API allowed a you to manage a server anywhere from anywhere.
When Amazon offered the first EC2 service, it had to be a cloud because the servers were remote. It was not a cloud because it was on the internet; plenty of other companies were offering hosted servers. It was a cloud because their offering allowed required operators to use and API to interact with the infrastructure. I remember that EC2’s lack of UI (and SLA) causing many to predict it would be a failure; instead, it sparked a revolution.
I’m excited now because we’re entering a new generation of cloud where Infrastructure APIs include networking and storage in addition to compute. Mix in some of the interesting data and network services and we’re going to have truly dynamic and powerful clouds. More importantly, we going to have some truly amazing applications.
What do you think? Is API a sufficient definition of cloud in your opinion?
PS: Yes, if you have a physical server/network/store that is completely controllable by an API then you’ve got a cloud on your hands.
Rob Hirschfeld 
Thank you. This is the most useful single piece of writing on what the hell ‘cloud’ is that I have ever seen. “Everything else is just a consequence of having infrastructure with an API because API provides the ability to provide remote control.” Awesome.
LikeLike
Thanks! Good to know my rants make sense 🙂
LikeLike
Rob,
I fully agree. Great job distilling the essence of the concept
LikeLike
[Take 2 – please delete if duplicate]
A few comments.
First, it’s not enough to say “API”. The semantics of this API have to be substantially real-time, even if we admit some asynchrony. If I provide an API to Jira to cut tickets for the infrastructure humans to act upon, that doesn’t feel like a cloud service.
Secondly, it’s logical (virtual, abstracted) infrastructure. It doesn’t necessarily behave like bare metal, or even VMware-style VMs. It probably doesn’t correspond to specific, dedicated hardware components.
(BEGIN SIDEBAR)
One of the misleading aspects of many of the existing IaaS software solutions – CloudStack, OpenStack, Eucalyptus, Nimbula, etc. – is that they suggest that they will work with any of the existing virtualization technologies – VMware, Xen, etc. What’s not made clear by the vendors is that you cannot (rationally) drop a cloud orchestration layer on top of a virtualization solution and continue to use the existing virtualization tools. The result would be chaos. The re-use of existing technologies is a convenience for the service provider, not an extra feature for the user of the cloud.
(END SIDEBAR)
Finally, I strongly disagree with the final point. It admits all kinds of systems: a singleton Linux box with an ssh interface becomes a cloud under this definition! Let’s stick with the “pooled resources” concept from the NIST taxonomy.
The bottom line: an IaaS cloud is a service (with API, SLA, behavioral metrics, resource accounting, etc.) providing access to abstracted infrastructure and infrastructure-like capabilities, which are implemented using dynamically allocated pools of physical infrastructure resources. By defining the service and APIs in terms of powerful resource abstractions, rather than physical infrastructure, the provider is able to innovate “under the covers”, using technologies like compute and network virtualization, live migration, consumption-based capacity planning, policy-based automation, and so forth.
LikeLike
Goeff – Thanks for the thoughtful comment! Since I have nothing positive to say about the NIST taxonomy (and I know it too well since if has advocates at Dell), you won’t be surprised if I don’t agree with you on this one.
Jira is not infrastructure – it’s an application. Infrastructure does computing work like a server, switch or storage array.
Regarding the pooling requirement. A pool implies N > 1 resources as a requirement. I don’t see why N=1 is not a cloud. If I ask for a server from a cloud API then I have no idea how many resources are behind it. In fact, I’m not required to know. So a N=1 cloud would be pretty boring, but completely identical to an N=3141592 unit cloud. To go farther… if I asked for resource #101 of a N=100 cloud then I’d get exactly the same result as asking for unit #2 from a N=1 cloud. Pooling does NOT make a cloud IMHO.
LikeLike
When I was working at [DELETED] there was a service (web console plus matching API) which handled provisioning requests. The API was very similar to that exposed by IaaS systems. But behind the scenes, the web server translated every request into a ticket to the operations team. The only (relevant) difference was that each request took several days to satisfy, rather than a few minutes. The point is that the existence of an API is necessary but not sufficient: the semantics and SLA associated with the service are just as important.
N=1 is uninteresting. One of the most important changes that IaaS has introduced is to allow people to build designs that treat infrastructure as effectively unbounded. Of course it’s not really infinite – just try to grab more than a handful of any popular new EC2 instance type! – but the most interesting innovations in applications patterns and operations are being inspired by the possibility of treating VMs the same way earlier generations treated threads or processes. Traffic-driven elasticity, Netflix-style deployments, innovative HA and DR patterns, the use of micro instances to provide Zookeeper clusters for coordination… all of these are inspired by the idea of effectively unlimited infrastructure, which is so effectively captured by the deliberate metaphor of “cloud”.
LikeLike
Ah, thanks for clarifying. I think in both points you’ve given cases that would be clouds but are, as you say, uninteresting.
A. If you put the OpenStack API on a ticketing system then it would appear to be a cloud, but an uninteresting one due to performance.
B. If you have an N=1 cloud then it would appear to be a cloud, but an uninteresting one due to resource limits or failure zones.
I’m not saying we don’t have other considerations. My point is the we often forget the CORE DEFINITION when we talk about it.
I totally agree that we want clouds that have great performance, N+2 failure zones and a laundry list of other features. Those are features and not definitional.
Great points Geoff.
LikeLike
Pingback: Dell Open Source Ecosystem Digest: OpenStack, Hadoop & More 2-2013 - Dell TechCenter - TechCenter - Dell Community
Pingback: Dell Open Source Ecosystem Digest: OpenStack, Hadoop & Mehr 2-2013 (englischsprachig) - TechCenter - Blog - TechCenter – Dell Community
Your description of cloud as infrastructure with an API resounds with me a lot. I have this discussion a lot with people who think the best path to a cloud is to virtualize everything right now and work out the cloud later.
My argument is to build the orchestration layer first. the *stacks and euc make this easier as they give you orchestration and virtualization in a single step ( made up of about a thousand substeps! ). Extend that orchestration to your physical hardware ( anything from cobbler, pxe_dust, to some crazy tool called Crowbar ) and you have Brilliant cloud. ( althogh networking is probably always going to be the long pole in the tent in any physical server automation ).
I would actually call Geoff’s example of an putting an API layer on top of your operations staff a cloud. sure there are manual steps (invisible to customer), and a time delay, but those are irrelevent towhat I would define a cloud as.
It’s also a brilliant first step towards a cloud as you can slowly replace each of the manual operations steps with code until it’s all automated ( apart from the actual racking/stacking ).
LikeLike
Thanks 🙂 I agree, it would be an interesting use case to use a manual ticket to fill in API gaps. I hesitate to think of what time-out you’d have to use on the call. As a general statement, I do often wish that people had a better API.
LikeLike
Actually, it’s a pretty lousy way to build a cloud, because full automation almost always involves ripping and replacing large chunks of your operational policies and procedures. Doing it incrementally is hell. The most successful private cloud programs I’ve seen all involve freezing “IT 1.0” and standing up a new, clean-sheet “IT 2.0” operation designed as an IaaS from the top down.
LikeLike
Pingback: Dell Open Source Ecosystem Digest: OpenStack, Hadoop & More 2-2013 | ServerGround.net
Pingback: Internets of Interest for 11th January 2013 — EtherealMind
Finally, you have undressed cloud – which was often described from the sales perspective and the definition was always bundled with all its features. Great work, Rob.
Cloud is infrastructure with an API.
I see this definition as a transformational one as how REST helped us to design & implement better networked application API’s.
I strongly believe this distilled definition will help us to visualize and innovate effectively as next generation infrastructure is on its way. It’s all about making API’s for all the components of an infrastructure – storage, network, etc.,
LikeLike
Thanks! I totally agree that the beauty of REST was its simplicity of definition. I appreciate the comparison.
LikeLike
Pingback: OpenStack’s next hurdle: Interoperability. Why should you care? | Rob Hirschfeld's Blog
Pingback: Unicorn captured! Unpacking multi-node OpenStack Juno from ready state. | Rob Hirschfeld
Pingback: 2015, the year cloud died. Meet the seven riders of the cloudocalypse | Rob Hirschfeld