The word "antifragile" may be recent, but some of the concepts are ancient. In "Art of War", the renowned general, strategist and tactician Sun Tzu's states, “…water shapes its course according to the nature of the ground over which it flows...” In an antifragile organization, we want to explore opportunities so resources flow like water into the things that are working, and abandon those that are not.
Rock Wall, Andrew Petersen https://flic.kr/p/FFvzCy
Just as water retains no constant shape, there are no constants in an antifragile organization and IT infrastructure. To flow like water, you must be able to shift people and teams easily, create teams and systems easily, be able to tear down systems and remove people from working on projects that aren’t working. This requires an architecture that allows you to act locally but think globally. Some organizations are pursuing microservices to this end. Complex applications are composed of small, independent processes that focus on doing a single responsibility. With microservices, developers decouple software into smaller single-function units that can be replaced individually.
Microservices development follows an evolutionary model. They are not designed from on high or in isolation. They grow and change, with new services splitting off from ones that already work. Easy-to-use services with useful features will get used more frequently. Those that are hard to use or uninteresting attract few users. Services that gain users survive, while services with few or no users should die. This is evolution in action. It naturally leads to resources flowing like water to the successes.
We normally think of design as something that starts with a blank sheet of paper and we draw out what the world should look like. Designing microservices requires us to think of design in different terms. To effectively use and develop microservices, you are always building the next service within the context of the ones that already exist. It’s like building a fieldstone wall. You don't look for the most beautifully shaped stone by itself. You have to find a shape that fits in well with what you’ve already got in place.
Another common approach in design is to eliminate duplication in effort and in data. This creates fragility and increases code size. It multiplies dependencies. Normalization is not a healthy goal. Randy Shoup gave a talk at Craft Conf 2015 about “From the Monolith to Microservices: Lessons from Google and eBay.” In that talk, he described the evolutionary model by which services were born, grew, lived, and died. Duplication happens. Sometimes, services are superficially similar in behavior but have very different operational constraints. Other times, a service may be cloned to support a different user base. These clones, forks, mutants, and symbiotes all allowed the companies to explore solution space. Many services were created and later killed. That means it served its purpose and delivered value until it was no longer needed. In other words, the inventory was used up. I'd call that a success, but a traditional approach would view these as failures! The failure would be keeping everything alive after its usefulness was past.
If you design a service that can never be replaced, then you’ve failed.
Microservices is a hot topic and has a lot of promise. Like any architecture style, however, it must be used well to gain the advantages and mitigate the disadvantages. Simon Brown says, "If you can't build a monolith, what makes you think microservices are the answer?" He's right. The microservice style helps us create disposable code and delivery with team-scale autonomy. But, we must still design well to avoid some serious pitfalls: operational coupling, uncontrolled downtime, poor performance, semantic coupling, and brittleness. We need to learn how to correctly design so that we don't end up with a badly structured, impossible-to-change enterprise, the “big balls of mud.”
It turns out we can learn something about designing microservices and antifragile systems from a rogue fighter pilot from the 1960s. In 1964, John Boyd introduced the energy-maneuverability theory. Boyd’s E-M theory basically showed that the fastest airplane didn’t always win the dogfight. Rather, the one that could accelerate or decelerate fastest—rapidly change maneuvers—wins. Maneuverability is the active, dynamic aspect of antifragility. When we are more maneuverable, we can create randomness that will benefit us and break others.
In our systems, we must be able to scale up, down, and sideways to adapt to changing situations. Cloud computing allows us to gain and shed mass quickly, so it is a big benefit to maneuverability. Microservices, applied correctly, can enhance our maneuverability.
In the last several weeks, we've introduced a large number of concepts but haven't yet shown how to apply them. In the coming weeks, we will show how to weave these concepts together: disposable code, microservices, antifragility, team-scale autonomy, and maneuverable architecture. We'll see how sharp tools and high leverage allow us to create and exploit advantages.
Read all of Michael Nygard's The New Normal series here.