VIII. Embrace the Cloud

Some IT guys still take solace in seeing blinking lights in the broom-cupboard.

For this reason embracing the cloud still runs against the grain of standard contractual agreements. Truth be told, those IT guys have a point. You entrust your data to a faceless corporation. You can’t see where it is. You can’t be certain that they’re not sharing it with the CIA. Sometimes all that fancy abstraction gets leaky, and something goes wrong. And when it does, there is nothing left to hit with your spanner. Control freakery is an attribute unusually welcome in a SysAdmin, and the Cloud takes away control.

When we talk about fully embracing the cloud, quite often, your standard issue IT guy is not wholly conversant with what that means. They’ve been on board with server virtualisation for quite some time, but they might not be comfortable with the idea that these virtual servers are ephemeral clones. Like the character Sam Bell in Moon, their drive could be wiped at any given second, and it shouldn’t matter, because the next clone is always ready to be wheeled out. 

Now the containers in our virtual server farm have names like 050487d5cab85820e. It’s harder to get attached that way.

The first rule of farming is not to name the animals. That’s why we abandoned server naming schemes a long time ago. Now the containers in our virtual server farm have names like 050487d5cab85820e. It’s harder to get attached that way.

That’s what fully-embracing the cloud means. It’s not just running some virtual servers. It means developing horizontally-scaling, stateless applications, which can be installed, booted and deleted as part of an orchestrated choir of servers. It means keeping your static assets outside your core application. It means trusting on-demand services for databases, caches, routing and storage. Somewhere, underneath it all, there are servers, but you’ll never know their names. They are disappearing into an electric sea of ‘infrastructure’. Soon there will be only code, and services like AWS Lambda and Google AppEngine are pushing us further in that direction. Which is a good thing.

Servers are disappearing into an electric sea of infrastructure.

And sometimes it will go wrong. Much as cloud providers talk of redundancy, and removing single-points of failure, ultimately, this is impossible. Only the naive entrust that the failover, multi-zone, database-clustered distributed services are truly fault-free. The very systems that coordinate redundancy become single points of failure. It’s like an immutable law of physics that designing-out architectural flaws will introduce different, more complex ones.

Even so. When you look at uptime across the system, weigh in the convenience benefits, and consider the level of expertise underlying the infrastructure, all to be purchased per processor-cycle, it’s still better than relying on that server in the cupboard. And besides, the IT person who seeks to control everything usually has a huge blind-spot covering the highest-risk single-point-of-failure in the system: Themselves.

Required Reading:

• Moon 2009 science fiction drama directed by Duncan Jones and written by Duncan Jones and Nathan Parker
• Service Statelessness Principle a design principle applied in order to design scalable services
• The Law of Leaky Abstractions

Next Month: Cache First (ask questions later)