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

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

This talk was recorded at NDC Porto in Porto, Portugal. #ndcporto #ndcconferences #architecture #cloud #softwaredeveloper

Attend the next NDC conference near you:

Subscribe to our YouTube channel and learn every day:

Follow us on our Social Media:

As a consultant, I get to see many systems built by many different developers. Recently, I’ve seen an uptick in the number of systems built with a microservice architecture in mind, but those systems often include a lot of the same mistakes that keep them from working well.

In this session you’ll learn from my experiences and get pointers on what to avoid in your microservices implementations so that you don’t accidentally build something which has all the worst aspects of a monolithic application and the worst aspects of microservices These monsters are what I call “distributed monoliths”, and I can help you avoid building one accidentally.

[zaoralj]

One the best speech about this topic I've heard in last few years.

[namelessyoutubechannel]

Fantastic presentation! Learnt so much.

[chashdeveloper]

Sometimes we forget performance is not only achieved by architecture improvement but code improvement. Microservices are a pain in the arse esp when it comes to supporting product env with separated network boundaries

[allanwind]

Two services would still exhibit coupling they communicate async via an event bus. They are no longer have the same temporal coupling but presumably you still want the event to eventually be delivered to the receiver(s).

[Exterminator]

The suggestion to start from a monolith app first is probably the most ridiculous one, that I've heard for recent years! Every system architecture has its own specifics, which makes any transition to another architecture a really non-trivial task, or it's not possible at all. What is OK for one architecture (say, tight coupling in monolith), stays against the rules in the other (micro-services must be loosely-coupled). We cannot just gradually transform our monolith to the completely different micro-services architecture!
Hence, we have three options here:
1) Start with micro-services from the beginning.
2) Write 2nd version of our software solution from scratch.
3) Stay with monolith, as it's not "evil" like it's now popular to state! "Evil" sources from lack of competence! The same guys, that created "bad" monolith before, would make awful "distributed monolith" instead of normal micro-services!

[jancarius]

How many times is this same talk going to be given? If this was comedy, people would say jokes are being stolen!

[felipevaldes]

AI summarized this talk as follows, please comment if you agree with the summary, or if it's completely botched:


The talk discusses the common mistakes made when building microservices, which often lead to the creation of a distributed monolith. A distributed monolith is an application architecture where services are tightly coupled and communicate with each other in a way that resembles a monolithic application. The main differences between a monolith and a microservice are:

Monolith: A traditional architecture of software development where all components are built and deployed together. It can be modular, but not independently scalable.
Microservices: A software approach and team organization that leads to small, loosely coupled services communicating with each other through well-defined messages. They are owned by small, self-contained teams.

The talk highlights 10 common mistakes made when building microservices:

Assuming microservices are always the best choice for every project.
Not having a clear architecture and design for microservices.
Ignoring cross-cutting concerns, such as security, authorization, and authentication.
Skipping logging and monitoring, making it difficult to debug issues.
Creating tightly coupled services, which resemble a distributed monolith.
Using an event bus or queue in a way that creates coupling between services.
Not having a clear separation between services, leading to a ball of mud monolith.
Ignoring the need for a well-defined API and contract between services.
Allowing the database to become a single point of failure.
Not scaling horizontally, which can lead to performance issues.

To avoid these mistakes, it is essential to have a clear architecture and design, consider the project's requirements and constraints, and ensure that the team has the necessary expertise to build and maintain the microservices. Additionally, it is crucial to monitor and log issues, create loosely coupled services, and scale horizontally when needed.

[vivekkaushik]

Milan Jovanovic must be crying out loud now. 😂😂😂 Jk. That guy is amazing but his entire channel is built around monolith architecture. 😂