“Latency be damned! We’re in THE CLOUD!”
“Bandwidth, schmandwidth! We’re in THE CLOUD!”
“Load is always balanced! We’re in THE CLOUD!”
“We don’t need no more stinkin’ [whatever]. We’re in THE CLOUD!”

We’re here to today to talk about THE CLOUD, and how it’s different from the cloud.

The cloud is a marvelous tool that lets you abstract, well, almost anything … and as much or as little as you want. Don’t have the skills, space, or time in-house to maintain the hardware? Move to a cloud environment. Tired of managing your MS Office licenses? Move to a cloud solution, and let someone else manage that headache. Want to be able to double your infrastructure size with a click of the mouse? There’s a cloud-based solution app for that.

THE CLOUD, on the other hand, is an auto-magical place that is nowhere and everywhere at once, where the sun always shines, and “infinite” is just not big enough to describe it. THE CLOUD solves all problems, cures all ills, turns spaghetti code into optimized hacks that’ll be taught at MIT for centuries while supporting a billion concurrent users per second… and requires literally no effort whatsoever for anything at all. It’s magical supercomputing for muggles.

The problem – and the risk – of conflating THE CLOUD with the cloud is conceptual. It’s an easy trap to fall into. (We’ve all been there, right?) We abstract a thing, making it into a black box, a wrapper, an interface, a shape in a flowchart or diagram. That single item conveys a simplicity that belies the hundreds or thousands or millions of items that it contains in reality. The physics don’t change, the nuts and bolts of it are still there, but we forget that those nuts and bolts exist. This is not a bad thing in and of itself. After all, technology is all about freeing up brain space by using machines for the grunt work. But one has to remember we did not suddenly change the laws of physics with wave of a mouse in Visio.

For instance, we were working on a project recently that included some latency bench marking and bandwidth measurement for various corporate locations worldwide. Some of the numbers were very bad but the client’s comments were, “That’s OK! The production environment will be in THE CLOUD!” To which we replied, “Do you mean that the application and database will be replicated and synced across all of the vendor’s nodes? And where are these nodes located?”

Crickets. Not the insects. The sound of.

The actual, real, live cloud may have controls to dial compute, memory, storage, network, and other resources up and down but still represents a platform and a stack within which your code was designed to operate. In THE CLOUD, those dials may go to 11. In the cloud, your code and architecture must conform to “good”, if not “best”, practices if for no other reason that the fact that your budget won’t pay for THE CLOUD to be running at 11 24/7/365. (It also turns out from long experience that software that performs very badly usually has a bunch of other defects, too, i.e. functionality, compatibility, security, UX, etc.)

The lesson here? Don’t accept THE CLOUD as the answer to any important question in the real world. If your tech moves at a crawl in your dev or stage environment, the probability of a cloud production environment is tiny. The chance of THE CLOUD fixing it is zero since that CLOUD doesn’t exit. Furthermore, it’s a good idea to respect the performance data and begin asking questions about what the bottlenecks are and why do they exist, what risks should be tracked, and what expectations should be set for the field. Bad performance data should also treated as a sign that more testing and QA work might be warranted across the board. And by doing all of this, we transform THE CLOUD (magic) to the cloud (technology).

We can all agree that tech beats magic, right?


The authors:


Josh Kitchen, Director of Engineering

Jonathan Cornwell

Jonathan Cornwell, Marketing Manager