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

[@zaoralj]

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

[@JonasThente-ji5xx]

I agree.

[@namelessyoutubechannel]

Fantastic presentation! Learnt so much.

[@JonasThente-ji5xx]

Me too.

[@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 🙂

[@JonasThente-ji5xx]

@@allanwind295 Of course, they belong to the same system after all. If there was no dependency *at all* between the two micro services, then they would be two different systems.

[@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

[@JonasThente-ji5xx]

What do you mean?

[@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!

[@JonasThente-ji5xx]

You start with 1 service, and split it into multiple ones when you realize a need for it.

[@r87961]

Most principles that make for good microservices also make for good applications in general. So rather than building microservices you start out building modules in an application. These are separated and modeled after the same domain concerns as a microservice. Once there’s a clear need you can spin off modules into their own microservice. Of course there’s a cost involved with that, but you saved on the initial cost and maintenance of needlessly building everything in microservices with all the complexity that goes with that.

[@awakenwithoutcoffee]

modular monolith! bigger application level with micro-services only when needed and as loose coupling possible.

[@jancarius101]

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

[@JonasThente-ji5xx]

You don't have to listen.

[@r87961]

Most talks are given at multiple conferences during “the conference season”. So usually about a year. Though in my opinion this talk should be given until devs stop using microservices as their silver bullet solution for everything.

[@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.

[@JonasThente-ji5xx]

Which AI did you use?

[@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.