Chapter 1. The Microservice Revolution
These days, you can’t swing a dry-erase marker without hitting someone talking about microservices. Developers are studying Eric Evans’s prescient book Domain-Driven Design (Addison-Wesley). Teams are refactoring monolithic apps, looking for bounded contexts and defining a ubiquitous language. And while there have been countless books, videos, and talks to help you convert to microservices, few have spent any appreciable time asking if a given application should be a microservice.
There are many good reasons to use a microservices architecture, but there are no free lunches. The positives of microservices come with added complexity. Teams should happily take on that complexity, provided the application in question benefits.
This report will give you a set of principles you can use to help focus your efforts and avoid wasting your time. As you read through the following pages, ask if your application benefits from a given principle. If you answer “yes” for one or more of the following principles, the feature is a good candidate to be a microservice. If you answer “no” for every principle, you are likely introducing accidental complexity into your system.1 But why are so many companies adopting microservices in the first place? What even is a microservice?
How Did We Get Here?
Odds are you’ve noticed a major shift in how your organization approaches infrastructure. Servers were once homegrown—a bespoke artisanal approach. And while you may ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access