đź“š We started a book club
Read along with us as we study Building Microservices
Medium Engineering started a book club this year! (Really, it’s the backend group, but we’ll extend this to all of engineering in Q3.)
Our first book is Building Microservices. We have a 4-month schedule that’s easy enough to follow while still getting everything done.
- March (already over, but you can catch up!) — Section I: Foundation
- April-May — Section II: Implementation
- June — Section III: People
Read along with us!
Why this book?
Medium is built with a microservice architecture. But we have a (relatively) small team and a complex system that can get difficult to maintain. Building Microservices: Designing Fine-Grained Sytems goes in-depth on topics that are relevant to us:
- Aligning system design with organizational goals
- Migrating from a monolith to distinct services
- Managing the tradeoffs (flexibility vs complexity) with microservices
Here are some quotes from Section I that got extra discussion from our team:
On ubiquitous language
Ubiquitous language refers to the idea that we should strive to use the same terms in our code as our users use. The idea is that having a common language between the delivery team and the actual people will make it easier to model the real-world domain and also improve communication. (Sam Newman, Building Microservices)
This is an area we’re much weaker in. Directly from one of our engineers:
Ubiquitous language is something that historically has not been used at Medium. See: “Collections → Publications”, “Catalogs → Lists”, “Post → Stories, Articles”, “Follow → Save”, etc. etc. Using distinct terminology has caused a slew of problems for us: onboarding a new engineer to the codebase related to the product is more difficult since they have to learn multiple glossary terms. Finding the related pieces of code, databases, logs, events, and documentation is harder because you’re not sure what terms were used in those places.
While Medium isn’t alone in dealing with this, it’s something that’s become increasingly painful in recent years. We’ve made good progress internally (and externally — thank you Amy!). But still, some way to go.
On common coupling
Common coupling occurs when two or more microservices make use of a common set of data. A simple and common example of this form of coupling would be multiple microservices making use of the same shared database, but could also manifest itself in the use of shared memory or a shared filesystem.
The main issue with common coupling is that changes to the structure of the data can impact multiple microservices at once. (Sam Newman, Building Microservices)
Turns out we have a pretty good eye for identifying undesirable coupling and reducing its impact. New services and database connections don’t see this kind of coupling, and any legacy connections are stable and contained enough that we’ve dealt with the coupling in a sensible way.
On choosing microservices
Microservices are not the goal. You don’t “win” by having microservices. Adopting a microservice architecture should be a conscious decision, one based on rational decision making. You should be thinking of migrating to a microservice architecture only if you can’t find any easier way to move toward your end goal with your current architecture. (Sam Newman, Building Microservices)
Microservices are not a switch you can flip. They’re more like a sliding scale you can choose to apply incrementally. One of our engineers quoted this and suggested we take a step back now to evaluate our microservices strategy as a whole. “Do we think it has been worth it so far?”
How we run a technical book club with a distributed team
Our eng team is spread across four US time zones and CET. During parts of the year our most-distant engineers are nine hours apart. That leaves very little overlapping time to sync. So we host our discussions in GitHub.
Updates in GitHub are shared in a dedicated Slack channel for increased visibility.
Discussions from the book club can be referenced in technical proposals and PRs. Though the discussions themselves don’t constitute formal decisions, they are good prose for reference when decisions are made.
We’re all meeting in Portland, Oregon, USA, this month for our first in-person book club discussion. We’re also discussing our long-term plan for microservice architecture.
What a prescient book club.
