Q&A on the Book "Microservices, a Practical Guide, Principles, Concepts, and Recipes"

The book “Microservices, a Practical Guide, Principles, Concepts and Recipes” by Eberhard Wolff explores technology stacks for microservices-based architectures that can be used at the overall system level. Targeted to architects, developers and operations, it provides a set of technology recipes along with executable samples that can be used to address different needs.

InfoQ: Why did you decide to write this book on the Microservices field at this stage? Did you find a missing piece of the puzzle?

Eberhard Wolff: When I started to write this book, I had already written a book about microservices with a focus on architecture. It had only one chapter about technologies. Then I condensed the basic architecture ideas into the free Microservices Primer. However, with the growing popularity of microservices, more and more technologies appeared that support microservices. So it was time to write a book about the technology landscape to complement the first book. That is how I started working on the book. You can now find the basic in the free booklet "Microservices Recipes" .

InfoQ: Who’s the target audience of the book and how can they benefit from reading it?

Wolff: As the focus is on technologies, architects, operations, and developers benefit from the book the most. Architects learn to understand the technology landscape and its implications. Developers can deep dive into the technologies with the provided sample projects. And some of the projects cover technologies for monitoring, logging, or tracing which is valuable for operations. Of course there is also a general introduction into microservices that all readers can benefit from.

InfoQ: You’ve mentioned that the focus of the book is on technologies for entire microservices systems and not on technologies for individual microservices. Can you detail here?

Wolff: One of the strength of microservices is that each microservice can be implemented with a completely different technology i.e. with a different framework and a different programming language. So the decision to use a specific microservices framework can easily be revised and the next microservice can be written with a different technology. Actually, if the system is long-lived,  different technologies will be used to implement the microservices to stay up-to-date and profit from innovation. But the question whether microservices use REST or a messaging system like Kafka for communication impact all microservices and is therefore much harder to change. So the technical decision for integration, communication, and operation are much more important than the decisions for the technologies in the individual microservices.

The book covers UI integration with links and JavaScript on the client as well as ESI (Edge Side Includes) on the server. For asynchronous communication it explains Kafka as an example of message-oriented middleware and a REST-based approach. Synchronous communication mostly uses REST these days and technologies like the Netflix stack or HashiCorps's Consul support this. Finally Docker, Kubernetes, and PaaS like Cloud Foundry add deployment as well as support for e.g. service discovery. The book also discusses Prometheus which is quite popular for monitoring, the Elastic stack for log analysis, and Zipkin to trace calls between microservices. Those are the most popular tools for these challenges at the moment and these areas must be covered for a larger microservices system. So there the book explains quite a few technologies that solve typical problem in microservices systems.

infoQ: How did you come up with the following as a definition of Microservices? “Microservices are independently deployment modules”

Wolff: I like this definition because it says that microservices are just a different type of modules. That clearly says that there are alternatives: All the other types of modules like libraries, JAR files, Maven projects, and so on. Also, it means that good microservices should be good modules i.e. low coupling - high cohesion or the single responsibility principles apply. Independent deployment is a key feature. Only then changes to a microservice can be put into production independently from changes to other microservices. That simplifies continuous delivery - which in my opinion is a major reason to use microservices. Continuous delivery make changing software just a lot easier and is often very hard with deployment monoliths. The Independent Systems Architecture (ISA) explains this line of thinking in more detail.

InfoQ: What are the main challenges of the microservices systems that you’re trying to dig into?

Wolff: When I talk to customer I often see an architecture based on REST services and synchronous communication. There are cases where such an architecture works. Netflix is an example. However, in my experience integration on the UI layer often provides  looser coupling and more resilience. If a microservice just renders a link to another microservices on an HTML page, the only coupling is the format of the URL. The linked to microservice can provide any kind of information under this URL. And if the other microservice is down, the link can still be displayed. So resilience is improved. Asynchronous communication is similar: If the microservice fails, message will be transferred later and there might be data inconsistencies - but the other microservices are still available. Of course there are also cases where synchronous communication makes sense to ensure consistent data. So in the book I show the different ways how microservices can communicate with each other - and technologies to implement those communication paradigms. For example, it is entirely possible to communicate asynchronously using REST.

InfoQ: In regards to architecture, Domain Driven Design is mentioned as one of the techniques that might help reach a clear division between macro and micro architecture of microservices based systems. Can you detail how?

Wolff: Domain-driven Design allows to separate the domain logic into bounded contexts. Each of these bounded contexts has its own domain model. So in an e-commerce system there might be a bounded context to do the shipping and another one for the invoicing. A change to either invoicing or shipping would be implemented in the respective microservice. The context map defines the bounded contexts and their relations as part of the macro architecture. How these bounded contexts and their domain models are implemented, is part of the micro architecture and can be decided by the teams that implement the bounded context.

InfoQ: You’ve highlighted the Self-contained Systems as a type of microservice. What’s their relevance compared to other types?

Wolff: Self-contained Systems (SCS) are different because they include a UI. Each SCS is a web application. So to continue the example of the invoices and shippings: If those two domains are implemented as SCS, then each of them would render HTML pages with the information about the invoices and shippings. Obviously you can only implement SCS if you are working on a web-based system. SCSs recommend UI integration and asynchronous communication over synchronous communication. And finally each SCS should implement one domain and belong to one team. So the structure of the domain logic and the organization is also considered which SCS. SCS is therefore a specific type of microservices that we found very useful in many projects. You can find more details in the article about SCS on InfoQ.

InfoQ: You’ve dedicated an entire chapter for the migration topic, from a monolith to a microservices architecture though. Can you sum up it here please?

Wolff: I think migration is very important because most microservices systems are not greenfield projects. So somehow the current system must be migrated into a microservices system. I recommend a basic principle: Separate a bounded context. Use asynchronous communication and data replication for integration - and UI integration but avoid synchronous communication. This improves decoupling and resilience. Then migrate the next bounded contexts step-by-step.

I wasn't really sure whether I should give a general recipe for the migration. Actually the book explains quite a few ways how a migration can be done. So let me add: Depending on the circumstances you might need to follow a different approach - maybe there is more to be gained if the UI is migrated first. And it is also important to think about operation. It is easy to operate one single microservice and there is no need to invest in a lot of infrastructure then. Actually I don't think such an upfront investment is always necessary i.e. there is no need to deploy Kubernetes for the very first microservice already. However, with a growing number of microservices eventually a more efficient platform must be deployed. Otherwise operations will be overloaded with work.

InfoQ: The book makes use of recipes to show the utilization of several technologies in the  implementation of microservices based architectures. Do you want to provide any special tip on how to pick the right one?

Wolff: To me this is the fundamental challenge of software architecture: Find the technological solution or recipe that solves the problem at hand best. And there is no perfect solution - it is always a trade-off. That is why the book discusses so many recipes and shows alternative as well as variations for each recipe. However, I think synchronous communication with REST is overused. That is why the book starts with UI integration then talks about asynchronous communication. Synchronous communication is the last alternative that is presented. I want the reader to be aware of these alternatives and the trade offs.

InfoQ: What about the operation part, can you tell us what are the trends we are seeing nowadays?

Wolff: Kubernetes is very popular. The book explains how Kubernetes does not just solve the challenges concerning operation but also provides service discovery or load balancing for REST communication. But also in this regard the book shows an alternative: A PaaS like Cloud Foundry hides Docker completely. And finally there is Serverless which is very popular solution at least in the Public Cloud.

InfoQ: To finalize, how connected have you seen Microservices and the Agile Mindset?

Wolff: Some years back I became interested in continuous delivery because it is a great fit for the agile approach: If you deploy software frequently you can get feedback from production and use that as input for the next iteration. However, continuous delivery is hard if you don't change the architecture. And that is where microservices help. So I think microservices are the ideal architecture approach to support continuous delivery and therefore agile development.

Also microservices allow for decentralized decisions for technologies as well as the implementation of domain logic. That perfectly supports  self-organization and cross-functional teams that are fundamental to the agile model.

About the Book Author

Eberhard Wolff has 15+ years of experience as an architect and consultant - often on the intersection of business and technology. He is a Fellow at innoQ in Germany. As a speaker, he has given talks at international conferences and as an author, he has written more than 100 articles and books e.g. about Microservices. His latest book is about Microservices His technological focus is on modern architectures – often involving Cloud, Continuous Delivery, DevOps, Microservices or NoSQL.