Some weeks ago I made the mistake of asking a wide swath of project teams if their customer is using the cloud. I was a bit surprised to learn that nearly all of them are using the cloud until I noticed what passes for “cloud” these days. This is a such a common misconception and misunderstanding that before I dive deeper into other cloud related topics I should take some time to establish a good working definition – and deal with the ensuing vigorous and virulent debate.
There really is no one definition of “the cloud” that everyone agrees on. For those who have been in IT for awhile, the origin of the term (as best I can tell) stems from architecture and networking diagrams where anytime one wished to reference “the internet” you simply drew a cloud. More appropriate iconography would have probably been a black box, but given that every other item on the diagram was a black box someone decided a cloud would be better (Steve Jobs – was that you?). In essence, it captures the idea that stuff (packets) disappears into this thing called the internet, then as if by magic, reappears at either a client device of some kind or your data center, generally after passing (ironically) through one or more firewalls (odd brick looking devices in various states of incineration that you place in your data center on either side of a “demilitarized zone”) . I have to assume “cloud computing” or “cloud” started as a shortcut reference to “computing that takes place in the cloud or internet”. The cute little cloud icon and associated term has since morphed into the ideal way to gloss over concepts and technologies that you don’t understand well enough to document accurately or explain.
Enter the marketing team (face palm). In a fashion reminiscent of AT&T’s creative interpretation of “4G” from a few years back, everyone and their mother jumped aboard the cloud bandwagon. This is in the cloud, that’s in the cloud, it runs in the cloud, we have our own private cloud, managed cloud, red cloud, blue cloud, 1 cloud, 2 cloud. This is particularly prevalent in government agencies where the cloud first mandate, intended to encourage agencies to save money by moving to the cloud, has been interpreted as license to spend exorbitant amounts of time, energy, and money to each build their own cloud (double face palm).
Not to be outdone by the marketing department, IT shops everywhere got into the game branding everything they do as cloud, cloud, cloud, lest they be bludgeoned by management for not getting with the program and being in the cloud.
Eddie Exec: “Danny IT Director, are we in the cloud yet?”
Danny: “Ummm, no sir. What would you like in the cloud?”
Eddie Exec: “Everything. Everything needs to be in the cloud. Everyone is there…cloud, cloud, cloud Danny. Cloud is gonna be YUUUUUGE.”
Danny: “Ok. I’m gonna need some additional resources to make that happen sir.”
Eddie Exec: “What?? The cloud makes things easier, cheaper, better, faster. Now that we’re in the cloud, I’m actually cutting your team in half. Cloud cloud cloud Danny…gonna be yuuuuuge. Need you to own it.”
Danny: “Yessir. Right away sir.”
Sorry Danny, but the VMWare stack in the “data center” (closet) with the supplemental A/C (big loud fan) in the secure room (behind Tony’s desk) is not a cloud. But what if you took that same stack, increased it by a magnitude of 100, and put it in an actual data center? Still not a cloud, brah. Sorry.
So, what is “the cloud” then? When we say cloud (or perhaps more appropriately “cloud computing” b/c cloud can still refer to the broader internet) we’re referring to a consolidated offering that encompasses Infrastructure, Platform, and Software as a Service (IaaS, PaaS, and Saas). All of these, offered together, by a single entity or vendor and provisioned with minimal human involvement. These are usually, though not exclusively, the domain of public cloud providers (Amazon, Microsoft, Google, Digital Ocean, Rackspace, etc.). Admittedly, I have yet to have encountered a legit private cloud that meets this definition, but maybe there is one somewhere…though the idea of a “private” cloud is a bit of a paradox. The whole origination of cloud was quite explicitly a simplified descriptor for internet, not (private) intranet. But I digress.
Why does the distinction matter? Because for all of its virtues, virtualization alone does not fundamentally change the architecture or management approach to developing or deploying a solution. Most of the time, it doesn’t even fundamentally change the underlying architecture or tools (note I said “fundamentally”, twice – I’m not saying there is zero difference, just that the difference is not earth-shattering). That’s not a knock on virtualization. That is kind of the point of virtualization – make it look, feel, and behave like hardware without, well, hardware and stuff. Every enterprise I’ve ever encountered that has gone virtual still has mostly the same tools in the toolbox, the same resource constraints, the same management approach, and generally the same set of headaches and issues they had on pure hardware. The only difference is that virtualization makes it easier to have idle capacity sitting around being – idle. Oh, and it saves valuable floor space in the clos…I mean “data center”.
The irony here is that virtualization is more evolutionary where the cloud is actually revolutionary. But if it weren’t for virtualization, there would be no “cloud”. It reminds me a bit of the mp3. It wasn’t the advent of the mp3 (by a record company employee, no less) that changed the music industry. At the time it was an evolutionary change that helped store music data in a more compressed format to make it easier to store. It took Sean Parker and Steve Jobs to unlock the power and create something truly revolutionary based upon a small, obscure file storage format. The same is true of virtualization. We’re seeing Amazon, Microsoft, Google, etc. enabling revolutionary change building on an evolutionary improvement to computing infrastructure (which should cause VMWare to be crying in their Kool Aid thinking “if only…”).
In contrast to virtualization, the cloud does fundamentally change the way you approach solution development and management in a number of critical ways. Take capacity constraints for example – no matter how big your virtual stack is, it is never any bigger than the number of physical machines your organization can afford to buy and operate, regardless of how many VM’s you cram onto the servers themselves. The cloud has no such limitation. Suddenly, a small organization has access to the same computing infrastructure as companies many times their size – literally thousand of servers at their disposal. To run efficiently, solutions have to be designed to take advantage of this scale (horizontal vs. vertical) which often changes the underlying architecture. The same can be said of the management approach. The removal of capacity constraints also means the removal of cost constraints meaning costs have to be managed more carefully (a topic I will discuss in far more detail in subsequent posts).
Another area in which the two are fundamentally different is the concept of ephemerality of compute power. In a traditional virtual architecture, most organizations create inefficiencies by dedicating compute resources to a particular project, team, task, or environment. This makes logical sense and is pretty easy to implement. In all but the most mature of installations, there is no concept of auto-scaling or hyper-efficient utilization. This means that when resources are shut down, they are just that – turned off and unavailable for use until that project, team, task turns them back on. The compute capacity is not returned to the pool of readily available resources. Why? Because doing so is incredibly complex and requires significant layers of abstraction between data storage, network, and compute, and for most organizations the investment required to do this simply doesn’t have a sufficiently high ROI. This is to say nothing of the fact that the application itself would likely have to be substantially modified and rewritten to support totally clean starts/stops and exploitation of elastically-scaled infrastructure (these are non-trivial design paradigms that many people assume are baked-in and almost never are). And it is here that the cloud requires a fundamental rethinking of the way the solutions are designed if an organization wants to be able to take advantage of the underlying hyper-efficiency and elasticity of the cloud.
These are just two examples of many areas where the cloud demands a fundamental rethinking of the way solutions are developed, how projects are managed, and why virtualization is not “the cloud”. In coming posts I’m going to talk more in-depth about how the cloud is different and what to do about it. But using some page space to first define the term seemed a worthwhile endeavor, especially if I can send as read-ahead material for my next cloud vs. virtualization meeting!