Cloud helps us solve the rocket fuel problem

Putting code into production is a bit like going to space.

If you want to reach Earth orbit from the surface of the planet, you will need some help. To start with, you can’t survive on your own in space: you need a spacecraft.

But your spacecraft needs help too. It can’t escape Earth’s gravity on its own: it needs a boost. The only way humans have found to solve this problem so far is by using rockets.

But your rockets need help too. Lifting you and your spacecraft needs fuel, determined by your combined weight. But that fuel adds to the total weight, so you will need more fuel to carry that fuel. And more fuel to carry that fuel.

And, given that fuel is dangerous and explosive, and your ability to reach orbit (and survive) depends on it being burnt in the right way, at the right time and in the right direction, you need structures to hold, control and direct that fuel. And those structures add to the weight and need more fuel to carry. (And more fuel to carry that fuel.)

The mathematics of this problem are known as the rocket equation, defined by Konstantin Tsiolkovsky in 1903 and eloquently described here in this article by Don Petit of NASA.

The results of applying the rocket equation to a trip from the Earth’s surface to orbit is that your spacecraft and rocket combo will be at least 85% fuel with a maximum of 15% payload, assuming perfect efficiency and engineering. Assuming that your engineering is not perfect and that you want some redundancy and a little margin for error, you will achieve a much worse ratio. The space shuttle was about 1% payload, most of which comprised the reusable shuttle craft itself.

And even if you have all that fuel available, you can’t build a spacecraft and a rocket on your own: it is a feat beyond any single human. You need a space programme.

By comparison, getting code into production is, of course, not as much of an achievement as putting someone into orbit. However, there are some similarities.

Think of a piece of successfully running code in production, accessible over the Internet and providing a service to customers, as analogous to a person in orbit. Just like a person in orbit, that code in production needs help, otherwise it cannot survive. At the very least, it needs an environment to provide all of its basic resources.

And that environment needs help too. Even though environments these days are usually virtual rather than physical constructs, they still need physical resources: they need computing and storage and networking infrastructure. And all of that those resources need help too: they needs a location which is secure, which is at the right temperature, and which has access to all of the utilities it needs to operate.

And, just as rocket fuel needs to be controlled and directed, the environment in which your code runs, and all the resources on which it depends need to be controlled and directed too.

Of course, many of these resources are systems themselves, which need their own environment and their own management tools, which needs environments and management, and so on.

Let’s call code which provides services to customers and colleagues the systems payload, and all of the resources required to make this payload work effectively systems fuel.

Fortunately, the systems fuel equation does not quite work in the same way as the rocket equation. While we need a relatively large set of resources to get any code running at enterprise strength, and we need to scale those resources as our application estate grows. But if we architect our estate well and build shared services, we will come to a point where the quantity of systems fuel required does not grow exponentially or even linearly with the payload.

However, for many small and medium enterprises, and even some quite large enterprises, it might never be possible to reach this stage, especially given increasing demands for capacity, quality of service, security and resilience. Such companies may have to accept a more fragile or less secure infrastructure, or find a way to swallow disproportionate costs.

Until the last few years, of course. As the title of this blog suggests, I think that one of the attractions of public Cloud is that it helps solve the systems fuel problem. It does not make the need for well managed resources go away, and it does not negate the need for resources that manage other resources, but it does let you use resource which already exist and which are shared with other users. It lets you hitch a ride on somebody else’s rocket, and it provides the space programme that builds the rocket.

For small and medium companies, it provides the opportunity to achieve enterprise grade security and services which they could not otherwise achieve. For large companies, it presents some interesting choices about how we deploy our resources and attention: if all that rocket fuel we have at our disposal is no longer expended expended in lifting itself, how far and how fast can we go?

We should extend the analogy further, though, before we get too carried away on this rocket ride. Just turning up at the launch pad with a positive attitude, a desire to go to space and an open cheque book isn’t enough: if we just hop on top of the rocket, we’ll soon find out that we haven’t done enough to prepare ourselves. Between the launch, the passage through the atmosphere and the cold vacuum of space, we face a lot of dangers. Even when we take advantage of the existing infrastructure and services within Cloud, we must still define our Cloud architecture, build our applications well, secure our environments and protect our data: we must design our space capsule if we aim to survive.