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:
ndcconferences.com
ndcporto.com/
Subscribe to our KZbin channel and learn every day:
/@NDC
Follow us on our Social Media:
/ ndcconferences
/ ndc_conferences
/ ndc_conferences
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

[@allanwind295]

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).

[@ForgottenKnight1]

"but presumably you still want the event to eventually be delivered to the receiver(s)" - then that is not an event, but a message. Events do not require acknowledgement. They are simply emitted - there might be someone who could react now, or after 10 minutes, or never.

[@allanwind295]

​@@ForgottenKnight1What, in my comment, made you ascribe acknowledgement? All I am saying if you have two parties communicate, there is an coupling per definition of the term. It's just not as tightly as (temporal) synchronous.

[@ForgottenKnight1]

@@allanwind295 "presumably you still want the event to eventually be delivered to the receiver" - when a message layer is present, there is no coupling. I might have service A put a message on a queue and ... that's the end of it. There might be a service B looking at that queue or topic to get it, or there might not be. If service A expects its messaage to be processed, it means that it expects a service B to exist, take its message, process it and provide some output somewhere in some form. If there is none and service A fails or timeouts, it means service A is dependant on service B and not autonomous anymore. Maybe I interpreted your comment wrong, so feel free to correct me. In some cases, a response is needed and you might also think that if service A is always dependant on service B, you might want to merge them.

[@allanwind295]

@@ForgottenKnight1I never said anything about a messaging layer. My point is just because you rename your transport to "event bus" it doesn't eliminate coupling. You relax the run-dependency on another module, however, your system as a whole still need the event to acted on and usually within a implicit deadline. Your system will expect to react to "OrderPlaced" within a day or you will have "RefundIssued" events to deal with 🙂

[@Exterminator131]

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!

[@felipevaldes7679]

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.

[@jancarius101]

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

[@vivekkaushik9508]

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

[@ForgottenKnight1]

He might be barking loud and for a good reason. The last dozen solutions I had a look at claiming to do "microservices" were all distributed monolyths :) A lot of people don't understand that just because you split it, it's not a microservice yet.