In this past year, I have been dealing with monoliths, modular monoliths (moduliths), and microservices. Distributed systems have been my focus over the past couple years. So when I saw that my friend J Tower was giving this talk, I had to check it out.
Establishing Definitions
This is something I’m seeing more of – and something I do in my own talks – is establishing definitions. When we say monolith or microservice, what do we mean?
I have to give credit to J – he reminds us right at the very beginning that monoliths do not have to be bad things. They are a single application, possibly with multiple tiers. Monoliths can be written in a way that they work with scaling and sharding. They can be designed with modules, making them easier to maintain.
When he defined microservices, he stressed that microservices solve very specific problems and microservices are not a “one size fits all” solution. He shows an architectural diagram where the services are independent – including their data stores. He also makes mention of how the event bus fits in this setup.
Distributed… Monolith?!
When I saw the title of this talk, I winced fiercely. 😖 As his talk’s title suggested – don’t do microservices wrong! I was afraid to ask what he meant by a distributed monolith, so I held out until he got there.
A distributed monolith is what you get when you take developers who are inexperienced with distributed development and bring in things like “microservices without an event bus”, “microservices with a shared database” 🤔, “microservices with shared models” 😖, and “super chatty microservices”.
Rules for Event Changes
J talked about the top pain points he sees when developers try to create microservices and end up in the distributed monolith disaster. He mentions Domain-Driven Design and events, and the pain point he brings up is when developers have tightly coupled events.
These are the rules J has for Event Changes:
- Once an event is introduced, no new required fields.
- Unrecognized fields should be ignored. They shouldn’t cause errors.
- Consumers should use default values for optional fields when no value is provided.
- If 1-3 cannot be met, create a new event.
Conclusion
This session did a great job at reminding me of the perilous path of microservices and the pitfalls developers run into as they implement them. When the paths lead to a distributed monolith, know that here there be dragons – and they aren’t fun ones to fight. J’s session offered many suggestions on how to avoid these pitfalls. If you’re new to microservices development, I highly recommend catching this talk. In fact, another conference recorded the session, so check out NDC’s recording of “Don’t Build a Distributed Monolith”.
[…] Don’t Build a Distributed Monolith – J. Tower […]