1 Sentence Summary: Building Microservices allows us the opportunity to tackle software complexity and deliver faster; if (and it’s a big if) we build our services right: choosing the right tech, interfaces, and integration patterns.
Microservices are a way of breaking down applications into their parts so that businesses can deliver the components separately, experiment with distinct technology stacks, and create clear boundaries between business logic.
But building microservices isn’t easy an easy task. With microservices, you need to consider many things, such as how (and where) you split the services, how they talk to each other (integration), and what data they share.
It’s in-vogue at the moment to debate on the virtues of Microservices vs. Monoliths. But ultimately they’re just two different architectural patterns that solve different use cases. Ideally, you should understand both patterns.
Here are my three big takeaways:
- An architect is a town planner
- Microservices are data abstractions
- Independently deploy services
Lesson 1: An Architect Is A Town Planner
One point Newman makes in Building Microservices is how we should split services according to business domains, not just arbitrary boundaries. The idea of splitting services based on the business domain is not a new idea, it’s also been discussed heavily within books covering “Domain-Driven Design”.
That said, Newman does dive more into the architect’s role and how they should focus on those boundaries. He argues architects should focus less on what’s in “in the box” and more on “how the boxes are connected”. Newman argues that service integration and API’s are where architects should spend their focus.
Newman expands on this idea through the usage of the metaphor of thinking of architects as town planners, who consider the “zones” of applications, just as a town planner considers zones of a town, and the architect should think hard about how these zones interface with one another. A useful metaphor.
Lesson 2: Microservices Are Data Abstractions
As is expected, throughout Building Microservices there are lots of discussion about data. Understandably so—managing application data is indeed one of the most difficult aspects of building and designing software.
Newman discusses the various different data-related aspects we should consider when building microservices, such as how to think about data when splitting a microservice, how breaking down data affects data consistency, and how to deal with aggregated data for use-cases like reporting.
But one of the more interesting ideas that Newman explores about data is: A microservice can often be thought of as an abstraction (or an interface) over some private state (read: data). Therefore microservice architects should think very carefully about what data a given service exposes and in what format.
Lesson 3: Independently Deploy Services
The last big lesson from Building Microservices is related to some factors that define a microservice. One aspect Newman emphasizes strongly is if you cannot deploy a microservice independently you’re probably doing something wrong.
Not only is orchestrated deployment a smell—indicating that the service boundaries may not be correct—but by orchestrating deployments a business will not get one of the biggest benefits of the microservices approach, which is team autonomy and the ability to independently deliver.
Favorite Quotes
On how big a microservice should be…
Once a piece no longer feels too big, it’s probably small enough.
On the role of the architect…
I cannot emphasise how important it is for the architect to actually sit with the team.
On service integration patterns…
Getting integration right is the single most important aspect of the technology associated with microservices in my opinion.
Who Should Read “Building Microservices”?
The back-end engineer curious about architecture with 1+ years of experience.
Check Out “Building Microservices”
If you find yourself wanting the book, I’d appreciate it if you used the button below. When you do I get a small commission which goes towards the running of the website. Whether you buy the book or not—thanks for your support!
Buy “Building Microservices”
- 2023 Summary: Data Driven Stories About The Cloud - December 31, 2023
- 2022 Summary: The Open Up The Cloud System - January 1, 2023
- Open Up The Cloud Newsletter #30 (January Recap 2022) - March 1, 2022
