Cloud Entropy: Cloud Must Sprawl;
It's Written in the Stars

The universe and cloud alike have a natural propensity to become disordered, and such disorder leads to fragility. Energy, in the form of optimization and resource management, must be put back into the system to resolve the chaos. We identify three laws that dictate and define how cloud scalability impacts enterprise deployments.

The 451 Take

Picture a field of Japanese Knotweed that represents the sprawl of an application. Even if you spray weed killer on every part of the infected field, it only takes one tiny root to bring it all back in a few years. No matter how well you think you've eradicated it, it is bound to come back. The only way to fight it is to keep track of it, and regularly cut it back and attack it – it's not a one-off task. If you leave it, the fightback will be harder than ever as those roots wrap and interact around each other. And if you don't keep track of its spread, then all our land is under threat and fragile to the elements. Cloud applications are the same: Accept that sprawl will happen, but address it regularly, monitor its progress and don't let it get out of hand.

The second law of thermodynamics essentially says that a system generally flows from a state of order into a state of disorder. Entropy is a property that describes this disorder. At the microscopic level, this occurs because energy flows, which creates waste, which creates disorder. To resolve this disorder, energy must be spent recreating the order. This also occurs at a macroscopic level – to arrange a house of cards takes time and effort, but to knock it into a disordered mess takes a slight gust of wind. The probability that the house of cards will eventually fall down is certain, over a long enough time frame; the probability that a house of cards will spontaneously organize itself into a structure is near zero, over that same time frame. This law gives reassurance to those parents that reach the end of the day and wonder how their once pristine home became a disaster zone of Lego bricks and semi-digested bananas.

Law of Cloud Scalability: A Cloud-Native Application Left Unmanaged Will Tend Toward Greater Resource Consumption Over Time

Picture a cloud application that can scale up and down. In this initial case, scaling is performed manually by an administrator. In a period of demand, the administrator scales up the application, which takes a small amount of time and effort. The administrator tracks the demand, and scales back the application when that demand is no longer present, which (again) takes a small amount of time.

In the above scenario, the administrator must expend twice as much time to keep control of the application's resources compared with leaving the application to grow. Let's say this occurs time and time again, hundreds or thousands of times. For the application to remain at its original scale, the administrator must remember to scale back every single time. But for the application to have net growth, the administrator only needs to forget once.

The effort needed to scale up and scale back is greater than the effort needed to scale up. Thus, the probability of scaling back every single time is less than the probability of not scaling back every time. Therefore, the cloud-native application experiences a net growth over time.

This problem is even more pronounced with multiple administrators, each having their own agenda and personality. And with multiple clouds, the issue is far more pronounced. The problem also exists with auto-scaling – an automated script can scale up and down. But, like the human administrator, it only needs to fail at scaling back once for there to be a net gain in resources. Even a perfect script or tool is going to fail now and then.

The same applies to object storage, databases and the like. These platforms will naturally attract more data, and it is easier to add data and leave it than to add it and also remove it or optimize it. Thus, storage platforms also tend toward disorder. Energy must be expended to keep it ordered and remove the orphaned or disordered resources.

The problem is caused by cloud's greatest asset – the ability to scale. In a fixed-capacity system, this infrastructure remains broadly the same. But in cloud, the ability to scale means it will scale, if it can.

What does this mean in practical terms? On-demand cloud resources have a natural propensity to grow in volume. Even if you tightly control who can spin up resources, how much budget they have and how long those workloads live for, over a long enough timeframe there will still be some sprawl. These measures just slow down sprawl. To prevent sprawl from the outset, processes must be perfect and never failing, since just a single failure to scale back results in net growth. Since nothing is perfect and errors always occur, sprawl must happen. The only way to prevent it is to regularly clean up the sprawl. More on this in a moment.

Law of Cloud Entropy: Increasing Scale Left Unmanaged Tends Toward Increasing Disorder, Complexity and Fragility

With each new resource, the interactions between those resources scale exponentially, and the sprawl increases complexity. Let's say three resources communicate between each other, so that there are three interactions.

With each additional resource, the interactions between those resources vastly increase (in the figure above, the number of interactions grow faster than number of resources). For each resource we add, interactions grow larger again. So even a small amount of waste drives a huge increase in interactions. These interactions make the application more complex, since effort must be expended to understand these interactions, and it becomes more difficult to resolve issues. The more resources and interactions to keep track of, the more disordered things become, unless energy is expended in tracking and resolving this complexity. This can increase fragility.