Don’t Build a Distributed Monolith - Jonathan "J." Tower - NDC London 2023

monolith could also scale horizontally by dividing it into "macro" services: api nodes, shared state manager, and background worker

Except theory nothing is there and I hardly understand a single thing

Don’t forget to mention that you the owner of Trail Head and you like some business.

This got me thinking. Let's say you have a website and an app that communicates with your server. Isn't that at least 3 different "micro" services? The backend, the front-end, and the app? Should communicate through an event bus?

hmm. Public interfaces are final except for very limited circumstances. Yes. Really.

It is very expensive to start with distributed app with cost as you develop the prototype

Those migration patterns like evolution or strangler fig look cool on slides. In real life, in most applications the database is so tightly entagled that you can neither pull much out separately nor can you use a "facade" because the integration happens in the back thorough the database (and assuming instant consistency and locking/concurrency resolution via DB, of course). Now I do not want to advocate green field, I would perfer an evolutionary approach but it is very hard and I have seen it get stuck half way many times as focus shifts and buget runs out, resulting in an application more complex than before.

I did one team many services before, it worked fine and did not at all push us to monolith. We choose that architecture for a reason after all. What I see as main issue, so many people do microservices just because they are cool but do not reflect on it properly (we all learn, after all, but you need to allow for that) and people cut microservcies not by functions, but by data. Sometimes they are treated just like extended database tables.

My tech lead is rejecting to regret have built a distributed monolith, what should I do?

I live in a community very similar to the picture you picked to criticize the distributed monolith. 😂 no hard feelings even though i like to live in here, its not as beautiful and pleasant as the houses of microservices.

The thing about adding fields in event contracts, making sure the code expects unknown fields and forwards them is a good contender for some gnarly CI tests. Push out an event with a random new field, make sure it gets forwarded all the way to the end of all paths and that nothing crashes.

What a narcissistic guy! He's pretty much sure, he's the only one who knows stuff and tries to be funny to hide that. Fails on both fronts.

Why do we call it a brownfield project. Could we not have chosen a different colour. rofl.

In short: we should use common sense.

I've been developing software by that parable for over 20 years and I've been ahead of industry wisdom by 5-10 years.
Xtreme programming -> 90% garbage
J2ee beans - garbage
Microsevices -> special use, otherwise mostly garbage.
Scrum and agile -> 80% garbage
Mockup- based tests - very expensive garbage (you'll see)
And so on.

USE YOUR HEAD and you'll be fine

Here's example if people using their head: Loki' s deployment model. Check it out.

This is the best introduction to microservices I've found so far: It explains what microservices are, are not, and when to and not to use them.

Smart contract Virtual Machines are a modular monolith.

if you have trouble with MSA youll probably still have trouble with monolith.

ie, it has less to do with the pattern and more to do with the org.

Hi
Is Ocelot gateway with Rabbit MQ a ggod solution ?

This is great! I wish I was able to convey these concepts to teams where I have been part of. I was never able to convince team members to take a decoupled approach.

I got fired from a job for arguing with the DBA who wanted to have a single database for all the microservices xD

Monoliths are not our nemesis. Microservices could be enemies of the enemies.
And the real enemies are the stake holders and YOU yourselves.

Yeah dont build a distributed Monolith. Just build a Monolith.

I often miss the argument that microservices are much easier to replace.

gRPC?

First rule about the microservice club: don't. Our hardware ain't designed for microservices, is designed for multithreaded monoliths.

We need to sell more cloud services... let's turn "monolith" into a dirty word!!

Great talk! Thanks

I’ve worked on both Greenfield and Brownfield products… The Brownfield products were always more difficult. I completely believe that Brownfield product would be easier if Software Engineering were a more robust field where Clean Code and BDD were understood and the default method of development but I can’t keep up with 1000 line methods in 150 different classes.

I don't understand how someone might change table name, yet they can't change message or channel on which they send update. Event bus doesn't solve problems with lack of policy and guards in a team. I would never write a piece of code that changes db structure at runtime. There is no immediate consistency within a monolith in that example either.

Event bus is one of tools that we have, but it's just a tool not holly grail.

What he calls distributed monolith also can work well. The problem is that someone needs to figure out how it works and set rules. The other choice is to take policies and rules from Kafka. First option can be much faster because can be optimized using domain knowledge. Kafka is resource hungry option that gives the safety.

How'd one go about solving the 7th example (order service getting customer data from the customers service)? In my head even if the data is duplicated into the orders service, inserting a lot of customers would lead to the orders service also needing to duplicate them (by listening to some CustomerCreated event), meaning it'd still be impacted by this kind of load on the customers service?

Easiest way to avoid doing microservices wrong: don't do it until it absolutely needs to be done. Debugging distributed calls in real time during prod outages is no joke.

It's a very strange dichotomy HA vs IC in the context of microservises/monolith. It's completely orthogonal. You can make HA monolith and IC microservice perfectly fine without any hurdles.

If the only issue of monolith (by author words) is deployment issues I take monolith approach 24/7. It's pretty solved class of problems by modern infra.

Not having a previous application running for comparison doesn't mean you can only judge the new project by your feelings. There's also deductive reasoning that is used in science all over the place, including math. Sure, actually confirming old and new tech in an experiment is even better, but don't dumb it down to mere feelings either.

Great talk J. Thank you.

Oh damn i'm strugling with these. Can you come to speak our internal conference about these issues @jonathantower ? :)

Thanks very much J.! I started a big microservices project about 4 years ago, and spent a lot of time reading articles and watching presentations; I wish your presentation had existed then as you've summarized the most important parts of all that I learned the long way in just 50 minutes. As always, there is so much more, and I'd love to see a followup presentation with more details, but I'll definitely be passing this link on to anyone who says to me "I'm thinking about using microservices".

Without execption every monotlih I've worked on the last two decades has been a ball of mud monolith. It requires skill and disipline in application architecture to keep a monolith in good shape over many years. In my experience most developers don't have that. This is where micro services really shine. When the application get small then application architecture matters less (but system architecture matters more).

Sometimes I think microservices is all about politics / management. Everyone wants their own team, their own turf. You can operate independently and choose your tools, data structure, etc. But managing all the cross-talk on the data via the event bus seems like a nightmare. I'm sure I don't know enough about it but it sure seems complicated. Great talk.