Nobody Can Give You What I Can Promise

I want to dispel a cloud myth I hear from time to time. It usually goes something like this: “…the advantage of the cloud is that your application automatically gets deployed to more machines when your user count rises.” Then comes the assurance that cloud solution XYZ will automatically handle this, provide extra computing power and balance the load dynamically. Whatever language or platform technology you use, it’s rather naive to assume the cloud will make that happen for your particular application.

Picture a woman at a public pool dispensing soft serve into cones. A long line forms at her stand, people are unhappy, and some bright spark suggests buying a second ice cream machine. Here’s the five-crown question. Will another machine shorten the line? Unless we’re in an episode of The X-Files and the woman is part octopus with five arms, it won’t help. So why do we think putting another “ice cream machine” in the cloud will help if the person serving isn’t set up to use it? Adding one more machine might solve one problem only to give us a whole new set of problems we could safely ignore, or didn’t know about, before. Just picture the slapstick as her arms, or tentacles, fight over the stack of cones or the till where she keeps the change.

I’ve seen, or rather read about, a few applications that scale in a way many developers see as a showcase for the cloud. Look under the hood and you find that they have to meet several fairly demanding conditions to make the most of it while keeping costs and operations manageable.

An application has to be designed and implemented with cloud deployment in mind. It has to deliver good value for money and remain easy to manage. Miss any one of those conditions and you lose one of the advantages of the cloud. I stress “one.”

The compromises in architecture and implementation

An architecture that makes use of the cloud involves trade-offs, sometimes painful ones you have to be willing to make. The first is the degree of statelessness versus the complexity of the programming model. You never have a completely stateless application. The volume of data you’d have to move and the robust abstraction you’d need to build on top would make it inefficient. Another trade-off is between having data available locally and having it up to date. For performance, you’d ideally always have the data available locally, preferably in memory. If several independent processes can work with that data, you have to choose between availability and consistency. That’s the CAP theorem.

Your existing technologies may not work well in the cloud. That’s why cloud providers offer their own technology tuned for the environment. The trade-off you make when you use it is called vendor lock-in. You become dependent on a particular provider.

Economic scalability

The many problems we solve through architectural and implementation trade-offs can affect how efficiently we use the resources we’ve paid for in the cloud. In other words, you can end up with an application that scales at an astronomical price. The point is to scale at a cost you can afford. If each new user brings in one crown per month and you work out that just renting the hardware to serve that user costs one crown and ten hellers, your application scales technically but not economically. The architecture and implementation should share resources as widely as possible while keeping interference within acceptable bounds.

Operability

Manageability is all too often overlooked. Beyond obvious things like monitoring, you need a way to configure the whole setup. Things get really complicated when the application is split into several separately deployed components instead of one monolith. Look at the open-source technology released by Netflix or Twitter and you can immediately see that each core technology has several others around it that make it possible to run and manage. These are usually for monitoring, dynamic management or service discovery. Some cloud providers offer similar tools themselves.

There’s no cure-all

Yes, the cloud offers interesting possibilities, provided your application is built to use them. I don’t want this to sound like an argument against the cloud. My point is that we should learn to write applications that can scale well. The cloud lets us deploy such applications at a good price. The cloud won’t save your applications if you haven’t prepared them for it…