Don’t Build a Distributed Monolith: How to Avoid Doing Microservices Wrong - Jonathan J. Tower

Learn how to avoid common pitfalls in microservices architecture, including the distributed monolith, and discover the right approach to scaling and maintaining a successful microservices system.

Key takeaways

Microservices are not always the best solution, and it’s essential to understand the reasons for and against them.
Avoiding anti-patterns like the distributed monolith is crucial in microservice architecture.
Start by having a small team working on a monolithic application and then gradually break it down into microservices.
Monoliths can be scalable and are better at some things, such as data consistency, than microservices.
Microservices are suitable for applications that require independence, scalability, and high availability.
Organize your teams around business capabilities, not just technology, to achieve a more effective architecture.
Use events to communicate between microservices and maintain eventual consistency.
Avoid creating a distributed monolith by keeping data and services separate and not sharing databases.
Use services like Kafka or Azure Event Bus for event-driven development. *logging is essential in microservices architecture, and it’s better to use existing libraries rather than creating your own.
Don’t assume that microservices are inherently better than monoliths; each has its advantages and disadvantages.
When migrating to microservices, consider starting with a small team and gradually expanding to others.
Don’t reuse the same technology stack for every microservice; instead, choose the best technology for each service.
Use NuGet to manage dependencies and reduce coupling between services.
Avoid over-complicated event-driven architecture and focus on simplicity and maintenance.

Don’t Build a Distributed Monolith: How to Avoid Doing Microservices Wrong - Jonathan J. Tower

More talks