Cloud Native means serverless: What Prussia can teach us about serverless

‍

Napoleon reviewing the Imperial Guard at the Battle of Jena–Auerstedt, by Horace Vernet, 1836.

Armakuni has always been a Cloud Native company. We rode that first wave of being able to take advantage of easy to use self-service PaaS systems, and turned them into commercial benefits, for our customers, and their customers as far back as 2012.

But 2012 was nearly a decade ago now, so what does it mean to be Cloud Native in 2020. To understand how Cloud Native applies now, we need to go back and look at what makes something Cloud Native.

There’s no official definition of Cloud Native, so let’s lean on this one from the Cloud Native Computing Foundation, vendor agnostic shepherd of the Kubernetes project.

“Cloud native computing uses an open source software stack to deploy applications as microservices, packaging each part into its own container, and dynamically orchestrating those containers to optimise resource utilisation.” — Cloud Native Computing Foundation

Let’s pull this apart a little bit.

“Deploy applications as microservices” is the first part. Microservices are the breaking down of applications into small independent chunks which communicate via the network. Microservices are possible on any networked machine though, so what it’s saying is more than that, it’s that this behaviour must be natural and encouraged.

“Packaging each part into its own container” which means using container-based isolation. Isolation gives us the confidence to cram more onto each machine and reduce the number of wasted CPU cycles without worrying about leaking information between processes.

Once we have the confidence that we can utilise more of each machine’s resource, we don’t want to manage that manually. Once we have that it follows we want to reduce the amount of work that takes by automating, or as CNCF puts it: “dynamically orchestrating those containers to optimise resource utilisation”.

However, this definition doesn’t go far enough. We’ve fallen into the Engineer’s trap of thinking of the technology and not the people. So what are the principles that CNCF implies in this definition?

When we are using these tools, we’re able to move a lot faster. I can’t stress this enough: the human is now the bottleneck. To take full advantage of these tools, we can look to another fast-moving environment.

Learning from history: Prussian military strategy and forward control

The year is 1806 and Napoleon is marching on Jena and Auerstedt. Napoleon’s army is massively outmatched in soldiers, 110,000 Prussian troops to his 50,000.

Prussia has a problem though, their command structure is a mess. Multiple senior staff hold the same position in the army, leading to uncertainty as to who orders to follow, and making it slow to react.

The battle came to a head when Prussia ordered their main force to hold the Kösen Pass, Louis Davout, one of Napoleon lieutenant colonel’s leading a single Corps of 27,000 men defeated the main Prussian army of 60,500 troops.

What made the difference here, wasn’t a difference in technology, but rather strategy. It doesn’t matter if you have the latest, shiniest new technology, if you’re still using the same training drills from Frederick the Great.

JoJan — artwork by Vernet and Swebach / CC BY

Prussia had to go back to the drawing board with their army’s organisation. Over the next years, they formed a new doctrine, lead by Moltke the Elder: Auftragstaktik, or “Mission-type tactics”.

Auftragstaktiks most crucial aspect is Forward Control, the idea that the “man on the ground” can make better judgements on the situation than someone removed by multiple levels of rank. Commanders were given goals to achieve but left to decide the method on their own.

“Diverse are the situations under which an officer has to act on the basis of his own view of the situation. It would be wrong if he had to wait for orders at times when no orders can be given. But most productive are his actions when he acts within the framework of his senior commander’s intent” - Helmuth von Moltke

This sort of “Forward Control” is implicit in being able to take advantage of this increased speed of delivery.

To give people that control, we need to first delegate the responsibility to how to develop software systems in the most effective way. Meaning we need to teach people how to do it safely, and make it easy to perform actions safely through training and automation.

The next part of this is if we’re able to do all these things faster, we need our organisation to be able to learn from them, rather than making the same missteps over and over again.

An organisation that can’t retain institutional knowledge as fast as they can experiment will only evolve at that same speed that they can learn.

Technological Evolution: From Cloud Foundry to Kubernetes

When we first came into the industry, we were massive advocates of Cloud Foundry, and we still see it as a very influential tool. It wasn’t the first PaaS platform, but it was the first large one that took advantage of containers, meaning to achieve isolation you no longer needed to have a VM per process, massively reducing the total cost of ownership.

It automatically orchestrated running and scheduling the containers and took advantage of building and maintaining the environment they lived within. Utilising Bosh, a tool for deploying software onto Virtual Machines, it was possible to automate nearly all aspects of platform ownership.

It was a game-changer. Using Cloud Foundry helped us develop microservice platforms; the isolation and utilisation making it cost-effective and fast. Most memorably for Red Nose Day where we took payment platform that was massive for a single night of the year, to a group of easily understandable Microservices, that could handle anything the public could throw at it.

But the tech industry does not stand still; it can’t. As Lehman put it “an E-type system must be continually adapted or it becomes progressively less satisfactory”. Change is necessary to survive in the tech world.

Cloud Foundry has a high total cost of ownership. We’re looking at at least 20 Virtual Machines. Meaning the amount of productivity you need to get out of it needs to be notable before it starts to break even, making it unsuitable for most smaller companies.

Cloud Foundry internal and external communications of the Cloud Controller — Cloud Foundry Documentation

The rise of Kubernetes

Into this space walked Kubernetes. Now Kubernetes has container-based isolation with Docker and easy automation points, but it only has four components: kube-apiserver, kube-scheduler, kube-controller-manager, and etcd. This simplicity makes it cheap enough to be financially attractive to organisations that operate with small IT budgets.

The compute overhead is low enough so that developers could play with it on their machines, and mirrored how Virtual Machines worked so closely it was an easy transition. This simplicity made it the smash hit it is today.

Kubernetes Components — Kubernetes Documentation

Unfortunately, it was too easy; like with the initial creation of Virtual Machines, people applied their existing processes from physical machines to the utility-based world of clouds computing.

When you have weeks to have a physical server delivered, you have plenty of time thumb-twiddling and rarely scheduled meetings, with drawn-out processes. In the Cloud Native world with no delivery times, these still live on as echoes of when hardware was physical.

There are two sorts of change. One is easy and essentially involves taking a new tool for an old way of working; this is often how most people initially try to apply new technology. They shoe-horn it into their current mental models. The second requires us to unlearn previous habits, practices, and ways of doing things. It takes significantly more effort — and can be challenging in environments where we don’t feel psychologically safe.

This cloning of practices from physical hardware does nothing to encourage Auftragstaktik. The organisation does not need to learn to experiment faster, because it can’t move any quicker.

The Promise of Serverless: Embracing Forward Control

Step in Serverless.

Serverless is Utility-based computing provided at a FaaS (Function as a Service) level; this means thinking in small chunks of code. Under the hood, we’ve seen before, but they’re abstracted away from us. Containers, automation, now entirely supplied by the hosting provider, significantly reducing the amount of time needed to be spent by developers on non-value producing activities.

The technology isn’t what makes serverless unique, though: Serverless forces you to use Auftragstaktik’s Forward Control. To use these services, you need to be able to have direct access to the platform. This direct access causes a shift in thinking away from Physical Machines.

This transition isn’t always easy. Remember the Prussians? Well, I left out a part of the aftermath of the victory at Königgrätz, the commanders pursued their troops for insubordination, describing their actions as “barely concealed contempt”. What’s more, during the battle some commanders had no knowledge of Moltke the Elder’s strategy, and some treated it with open contempt. The road to high performance is often bumpy.

Many organisations will face the same internal struggles. What we have in Serverless is something that makes making the changes less painful than not. That is a mighty wedge.

You don’t get the benefits of Cloud Native without bringing these cultural changes. You don’t win a war of movement using tactics from a more static era. You can use the wedge of Serverless to make those changes easier.

Is Serverless the end of the Cloud Native story? No. “an E-type system must be continually adapted or it becomes progressively less satisfactory”. But is it the closest we’ve ever been to the dream? I think so.