1 Microservices: an architecture for fast flow

A lot has been said and written about the microservice architecture over the years. There are conflicting claims about when to use it. Some in the community say it’s the future of software development. There are others who even argue it’s an anti-pattern. The reality, as always, is it depends. But upon what? When should you use the microservice architecture? What problems does it solve and how?

The main motivation for using the microservice is to solve a problem that you are most likely facing: the need to deliver software faster, more reliably and with less risk so that your business can thrive in today’s world. While you might be able to accelerate development by, as a manager once put it, buckling down (or is it up?) and burning the midnight oil, any improvements are likely to be short-lived, and you will most likely burn out. For lasting improvements, you need to change the way you develop software, and, in some cases, the architecture of the software itself.

1.1 The need for fast flow

1.1.1 The software delivery feedback loop

1.1.2 Fast flow: continuous change and feedback

1.1.3 The fast flow success triangle = DevOps + Team Topologies + Architecture

1.2 Architectural requirements for fast flow

1.2.1 Architectural requirements for fast flow

1.2.2 The Monolithic architecture can enable fast flow

1.3 A brief introduction to the microservice architecture

1.3.1 The microservice architecture: a definition

1.3.2 The microservice architecture is a fast flow architecture

1.3.3 Other benefits of the microservice architecture

1.3.4 No such thing as a silver bullet: the drawbacks of microservices

1.4 When to use the microservice architecture

1.4.1 Building an application from scratch: typically a monolith-first approach

1.4.2 Refactoring a monolith to the microservice architecture

1.5 Summary