The Microservices Way: Speed, Safety & Scale

For the longest time there has been a belief in software engineering that you have to compromise between speed and safety: either you go fast or you build with high quality. You cannot have both. It makes sense intuitively. As humans, at the most basic physiological, instinctive level we are subjected to feel that high speed is always “dangerous”. It has everything to do with centuries of self-preservation, but of course isn’t always true. Generally speaking, airplanes are more safe than any other type of transportation, despite being the fastest, and modern high-speed trains are far safer than the steam-propelled ones from the 19th century. But putting our primal instincts aside, there are also more tangible reasons for why we believe that safe software cannot be built quickly, at least not complex one. Big part of the reasoning is that complex systems are built by many teams.

Building complex software is hard work. In films and TV, a brilliant engineer can heroically engineer a world-changing product over the course of a sleepless weekend. In real life it takes lots of people and a whole lot of time to produce a quality result. Multiple teams working on a complex project are typically implementing different parts of said system, following independent roadmaps, at independent pace. Periodically, these parts need to be integrated to resolve dependencies, at which point mostly autonomous teams need to coordinate their work (See Figure 1-1).

Figure 1-1. Sample timeline of a complex project, with coordination touch-points

Imagine team lead Jane in charge of the Accounting work-stream. Her team just finished a sprint and has a dependency on a component that is being developed by team in charge of the Shipment module, lead by Tyrone. Since road-maps are independent, it could be that Tyrone’s team is actually not done with their implementation of the needed component, in the Shipment work-stream. At this point Jane has one of two choices: she can either wait for the component to be delivered (prioritizing safety, but sacrificing speed, by putting her team on halt) and do a proper integration test, or she can rely on agreed interface contract between her team and Tyrone’s team, assuming that his team will deliver the component exactly as planned. In the latter case Jane would proceed without interruption, increasing her team’s speed, but potentially compromising the overall safety of the system since integration testing didn’t occur at the earliest possible stage and a “happy path” assumption was made.

Any team lead, in a complex, multi-team environment, regularly faces this choice between ignoring coordination costs and keeping momentum vs. acknowledging need for coordination and slowing down. Typically we choose one or the other using our intuition on risk vs. benefits, but overall, in a sufficiently complex system, when these choices occur frequently enough you would observe very pronounced tension between speed and safety. It is real, it is not related to our primal instincts and there is a way to fix it. Since coordination costs are what is causing the tension, what if we had a system specifically designed in a way to minimize the very occurrence of coordination needs? What if instead of choosing one way or the other, teams were not even facing the choice most of the time? You can have such design, emphasizing the minimization of coordination, if you have autonomous teams working on small batches of isolated work. And that is exactly what Microservice Architecture is all about, in its essence.

Indeed, if we compare this fundamental benefit with a more expanded list of benefits of Microservice architecture from Sam Newman’s book, we can see that every benefit Sam listed can be represented as a minimization of some kind of coordination requirement:

Technology Heterogeneity

removes need to coordinate programming languages, frameworks, libraries and technology platforms across multiple teams.

Partitioned Scalability and Independent Deployments

basically removes the need to coordinate deployments and operation of various parts of the system across teams.

Organizational Alignment

is all about the creation of autonomous teams, so direct response to avoiding cost of coordination

Composability and Replaceability

removes the need to coordinate life-cycle management of parts of the larger system, across various teams.

Understanding that the fundamental force of building successful microservice architectures is aiming for the minimization of coordination is extremely useful. It gives us a universal litmus test. Building complex, distributed systems, such as microservice architecture, isn’t easy and when in doubt we should always ask ourselves “is this decision I am facing going to reduce coordination costs for my teams or not?” The right answer will be much more obvious when we view decisions from the perspective of coordination costs.

So, why do people build Microservices? Because they help businesses succeed. Modern organizations are under incredible pressure to adapt, change and improve more often and more quickly. Investing in a technology architecture that is purposefully designed for change speed and change safety at the scale of a large organization makes a lot of sense. The Microservices style enables companies operating in complex domains to have the agility of a simpler, smaller company while continuing to harness the power and reach of their actual size. It’s incredibly appealing and the growth in adoption proves that - but, the benefits don’t come for free. It takes a lot of up-front work, focus and decision making to build a Microserivces architecture that can unlock that value.

Microservices Guiding Principles

A system’s principles communicate the most important beliefs of the team that has designed it. They represent the foundational characteristics and properties that the system should exhibit. A good set of principles describes the ideals that are pivotal to producing the system outcomes that the team desires.

Principles are useful because they shape our decisions. They provide the design and build team with a way to measure all of the architectural, design and build decisions that are made in the system. As the system moves from architecture to design and build, the principles help keep the team focused on the overarching goals of the architecture. Principles aren’t laws, but when a design decision breaks a principle it should trigger a healthy debate.

So far in this chapter we’ve described the characteristics, properties and optimization goals that define a Microservices system. But, beneath all of that are a set of general principles that drive the decision making of most Microservices practitioners. Teams that adopt these three principles stand a better chance of succeeding with the Microservices style:

Modularity

At the root of any service oriented architecture lies the principle of modularity and Microservices is no exception. As an industry, we’ve been programming and building applications in modules for a long time. The principle of modularity has been identified, applied and used by some of the most influential thinkers in computer science, including David Parnas, Edsger Dijkstra and Larry Constantine. That’s because breaking a big complex problem space into smaller, bounded pieces is the key ingredient to building a manageable solution. Embracing this principle means that we’ll build Microservices that encapsulate a part of our domain behind a service interface.

Disposability

Disposability is a design quality used to describe products that are cheap to produce, cheap to consume and designed to be thrown away after they are used. This turns out to be a key principle for the microservices in a Microservices architecture. Applying this principle to the microservices that we design and build will help us to form services that are easier to manage and maintain.

That’s because a highly disposable service is one that is easy to reproduce. At run-time, that means our disposable services can easily be instantiated, destroyed and cloned - lessening the burden on our operations teams. At design-time, disposable services can be easily thrown away and re-written - lessening the cost of making changes to existing services. If we design our system with this principle in mind, we’ll make it easier to change our decisions in the future. That’s a huge benefit for us and can reduce some of the analysis paralysis we talked about earlier. If we build a system with parts that are designed to be replaced, we stand a better chance of introducing improvements. But, we’ll need to make purposeful design decisions to bring this quality out.

Continuous Improvement

How we manage changes and improvements to our architecture is the most important consideration of all. Microservices systems that really work well almost always embody the principle of continuous improvement and incremental change. That means that the solution is designed to support a continuous cycle of experimentation, measurement, learning and improvement. There are a lot of different applications of this idea ranging from Edward Deming’s pioneering Total Quality Management to Lean methodologies and Agile principles. But, the underlying goals are similar - we want to build a system that is designed to be changed and improved throughout its lifetime. This is an essential principle for us to adopt. Continuous improvement gives us the freedom to build a system for today’s problems that can adapt and grow as our circumstances and understanding changes. The trade-off being that we need to build an architecture that is optimized for both changeability and observability so that our improvement cycles are fruitful.

These principles are important and understanding them will help us make better decisions for our Microservices architecture. They aren’t the only principles that matter for a software architecture, but these three general guiding principles are the ones that will give us the best chance of success. They don’t give us any specific guidance in terms of how to build our Microservice application (we’ll define a set of more concrete principles for our build in the next chapter). Instead, they give us an overarching direction and goal for the type of system we need to build. We’ll need to consistently consider modularity, disposability and continuous improvement as we design and implement our system. With these principles in hand, we can move on to the architectural decisions that they will influence.

Introducing the “Up and Running” Microservices Model

So far, we’ve talked about Microservices in a pretty generic way. We’ve highlighted a set of general characteristics, traits and principles that gives practitioners a lot of flexibility in how they might implement their system. We’ve also highlighted that the scope and complexity of a Microservices architecture can lead to some difficult decision making for aspiring adopters. It’s difficult to imagine how general guidance and advice will help you when you are faced with the complexities of building your first Microservices implementation. If you had enough time, you could continuously improve your system, changing the architecture as you go and end up with a solution that works. But, chances are you don’t have that luxury.

Instead, we’re going to accelerate that process. We’ll stay true to the guiding principles that we’ve outlined above, but we’ll address the analysis paralysis and the early stage challenges of Microservices adoption by introducing a model that will get you “up and running” faster. Our goal will be to establish a foundational Microservices architecture as a first step on your journey. We won’t be able to cover every aspect of a Microservices system, but we’ll focus on the parts the are the most difficult and most important for your future success. As we go through our build, we’ll implement these key elements of the architecture:

[[The Microservices Up & Running Model]] .The Microservices Up & Running Model image::images/arch-map.png["Description to come"]

Architectural Principles

We’ve covered some general Microservices principles in this opening chapter, but we’ll need to establish principles that are much more specific for our Up & Running build. In Chapter 2, we’ll document five principles that will shape our architecture and the decisions we’ll be making.

Operating Model

With our design principles defined, the first thing we’ll tackle is how the work will get done. In Chapter 3, we’ll dive into the details of our teams and how they will co-ordinate with each other to build and maintain the system.

Cloud Foundation

Our Up & Running architecture will be implemented in the cloud. In Chapters [TK & TK], we’ll design and implement a cloud-based infrastructure for our Microservices system. That will include a runtime network architecture along with some tools and patterns for continuously improving it.

Microservices Platform

Before we can start engineering our individual Microservices, we’ll need to establish some supporting infrastructure to help them communicate and operate. In Chapter [TK], we’ll implement a services architecture based on Kubernetes and Istio that can operate on our cloud foundation. Later, in Chapter [TK], we’ll show you how to implement a local version of this platform to support our engineering work.

Design Process

Once we have a platform and infrastructure in place, we’ll define a design process that will improve the way we create new microservices. In Chapter [TK], we’ll introduce a Microservices design process we’ve called “SEEDS” for designing jobs-based services and interfaces. In Chapter [TK], we’ll incorporate Alberto Brandolini’s “Event Storming” method to help us establish better boundaries and find the right size for our Microservices.

Data Model

In Chapter [TK], we’ll address the challenges of dealing with data - one of the most difficult aspects of building a Microservices architecture. We’ll outline a few approaches ranging from embedded data implementations to a more complex Event Sourcing approach.

Engineering

Finally, we’ll introduce and implement a set of practices for developing, testing and releasing Microservices in chapters TK and TK.

The Up & Running Microservices model covers a lot of ground and is prescriptive and opinionated by design. That makes it a great solution to the problem of “analysis paralysis” that is a problem for so many practitioners. But, it’s not meant to be the last Microservices architecture you’ll ever implement - in fact, it’s just the opposite. The Up & Running model is a great first step for you to take in your journey towards a Microservices system. It will allow you to quickly go through the steps of implementing a realistic sample Microservices system. The hope is that this will accelerate your learning process and give you the understanding and perspective you’ll need to build a Microservices architecture that is the right fit for your own unique constraints and context.