NEW MEAP

Learn the Theory behind Microservice-Based Systems by Using Them in Practice

An excerpt from the Tao of Microservices, Second Edition by Richard Rodger

If you want to really climb inside the microservice architecture and learn how it works, you have to use it in practice. This updated edition will teach you the theory underlying microservice-based systems by having you use them in practice.

Read on for more.

Take 25% off The Tao of Microservices, Second Edition by entering fccrodger2 into the discount code box at manning.com.

Getting started: building a microblogging startup

The best way to learn the theory of something is to see that theory put into practice. This book focuses on the theory of the microservices approach to system construction and will teach you via a practical example.

We shall design and model a microblogging system. You will see declarative code and diagrams that define the system in a rigorous way. In this book, we avoid the particulars of any given microservice platform or tooling. We will use JavaScript for code examples, because that is the language most developers have some knowledge of. You will be able to apply the ideas in this book to your own system whatever language and platform you use.

We will design the initial implementation of a microblogging startup, cut down to the bare functional essentials. We will design down to just above the level of implementation code (the full source is available online). You will start to learn the way of thinking about microservices explored in this book.

Messages First

How do you design software? How do you design anything? A design is a map that is to be made into reality. A good design, as a map, highlights the important features of that yet-to-be reality, and guides the builder.

To design software is to decide what it does. We can start from the informal requirements, and pull out actions that the software should perform. You may prefer to start with the data that the software operates on, and you may find that this improves your choice of the system’s actions. That is a perfectly fine approach.

The actions of the software system can be represented as messages passed between the components of the system. Let us deliberately leave the components to later. Traditional software design (and especially object-oriented design) often starts with an outline of the components. This book rejects that design tactic as premature. It is better to start with the messages, and work out what components you need later. The messages can be directly derived from the informal requirements because they encode behavior, rather than concepts. This book will teach you how to keep messages and services decoupled. Refactoring and scaling your systems, and avoiding the dreaded “distributed monolith”, will be much easier as a result.

Using Models

We can use the messages we have extracted from the informal requirements to start discovering the services that we need to build. We can group the messages in ways that make sense to us, and use each group to define a service that will contain the implementation code that can handle that group of messages.

This grouping of messages is not fixed, and can change over time as requirements change, or as we develop new insights that suggest refactorings that will give us a better structure for the system. This book does not prescribe a specific procedure for grouping messages into services. That is where your good judgment and experience come into play. This book does strongly suggest a set of design principles that make mixing and matching messages and services much easier.

The implementation of your services will require you to write code. Writing code means you start needing to make decisions about all sorts of foundational things. Where does your configuration live? Which data stores will you use? Where will you deploy your application? How will people in marketing update the text of user messages? How can you keep all the little things consistent, like the entries in drop-down lists?

There is also the data model. What data entities will you use, and what fields will they have? How will you do validation? How can you keep that validation consistent between local apps, web frontends, and many backend microservices. What about the messages themselves? Will you validate them in some way? Will you define message schemas?

Building a shared language

There is a school of software design known as “Domain-Driven Design” (DDD). It has some nice ideas we can adopt to help answer all those questions. This book does not prescribe the use of any specific methodology. You need to carefully choose working practices that will be effective for you and your team in the house that you live in.

One of the nice ideas from DDD is the concept of a “ubiquitous language”. The advice is that you should deliberately and carefully define the meanings of the specific terms that everybody on the project, technical and non-technical, will use. This shared language prevents a great many problems and keeps the requirements accurate and understandable. The insight is that you can only really do this inside a “bounded context”. Once the world gets too big you should instead start translating between such languages. A project using the microservice architecture is going to operate within a bounded context with one ubiquitous language. This works up to several hundred services and data entities. Beyond that, you will need to split things up into separate contexts with their own internal languages.

In this book we take things a step further. One of the most useful developments in recent years has been the adoption of infrastructure-as-code (IaC) tools. These tools let you define the machines, servers, databases, and all sorts of other supporting elements of your system, using code. The infrastructure of the system is defined in a formal way, and you can build verifications and automations on top of this. The important thing is that code is used. Code is powerful, and we already have many tools to work with code.

There is a recurring fashion in software development for model-driven architectures. The big idea is that you need to design the system at a level above code, and then produce the code from that design. If you are a working programmer you are now free to laugh out loud. Us working programmers know that a sufficiently detailed description of the system is exactly the code that we end up writing, not some near-useless model written by architects who have forgotten how to code!

The idea of being model-driven, and somehow avoiding the complexity of real code, is very compelling. Every decade tries something new. First we had COBOL, BASIC, and SQL. Then we had 4GL languages. Then we had UML. Now we have “no-code” tools. Some have been more successful than others.

When you build microservices, the need to use a shared language, and to have some sort of formal model of the system, in code, becomes more acute. One of the many valid criticisms of the microservice approach is that it generates far too much busy-work. It’s hard to keep hundreds of services consistent. A shared language, expressed in a formal model, greatly reduces this cost. A model-driven architecture, therefore, where the model is still code, turns out to be quite useful, in the same way that infrastructure-as-code is.

We’ll use case studies throughout this book to illustrate practical applications of the microservice approach. The case studies will keep you connected to the practical side of the discussion and allow you to make a critical assessment of the ideas presented — would you build things the same way?

What’s new in this edition?

Where the first edition of this book was more focused on advocacy and supporting those who had self-selected to build microservice systems, this edition focuses on helping those who have been directed to build using microservices, and have little choice in the matter.

In particular, this includes “cloudnative” architectures such as Kubernetes, Serverless, and JAMStack systems, and variants, which all suffer from many similar constraints to the original microservices concept. A common failure mode for such projects is to create large numbers of small web services and then string them together with ad hoc message flows, without considering the implications for system management or local development.

This book describes an approved path for navigating the microservice architecture from requirements to production. It is not a survey book, or focused on code (although there are many code examples). Rather, the aim is to give the reader the mental models and concepts to be successful with microservices.

Who is this book for?

This book is for developers and architects, or anyone who wants to learn about microservices and how to build microservice-based systems.

Learn more about the book here.