Modular Monoliths Are The New Microservices

[@akivaliaho5166]

I can't believe this video has only 1700~ views. It should be mandatory watching material for every single architectural astronaut and developer.

[@ChrisAthanas]

They likely won’t pay attention until they went down the wrong path and experienced the pain Blindly following fads is 100% cargo cult practices and the industry is plagued with this bc 50% of devs have less than 4 yrs experience. Given that universities are minimum 10 years behind and usually taught by inexperienced professional developers leads to the big ball of shit architecture patterns People want easy solutions to very hard and complex problems And they want them now So they grab the latest fad hoping it fixes their conceptual problems Lol Cargo cult practices make everyone suffer The planes aren’t coming

[@medilies]

9 months later, it has 8.5k

[@АртемАрте-г5х]

Because this video is bull shit from those who could learn how to implement microservices and when to implement micro services?

[@oguzhanK1234]

10:00 I lived the statement in my prev company. The other agile team started their project as ms, worked for 6 months and the output was nothing was working. In my team, although I was pretty sure that our app will be broken into ms"s in the future, we were very careful in that 6 month period, wrote the project following modular monolith approach. Then once the project has matured, we split it into multiple almost-independent services. Martin is definitely right. You cannot predict future, what kind of changes will be requested and will cause what kind of problems to you in the future.

[@ryanelfman3520]

I agree with the other comment. Every engineer needs to watch this. Micro services should be rarely used

[@djgreyjoy1495]

For this to work the modules need to own specific sub-domains in the database, the entities in a module's sub-domain need to be private, e.g. separate schemas with database users that can only access one schema.

[@kaibe5241]

Not really. You just need to set clear domain boundaries. Everything else is fine. They can all share the same database, that eases infrastructure considerably, and should only be split basically if there's a very good reason to.

[@alimli]

First of all, many thanks for the very informative great talk. I want to access the reference links in the presentation. Where can I download the presentation?

[@leonidas7692]

Somewhere along the way we forgot to let software work for us and instead started working for software. The system is at the mercy of the business architecture (ala Conway). Why then do we not address the business architecture first and THEN look at the software solutions to solve for it?

[@jamesdon2052]

That's why we should use ddd.

[@PierreThierryKPH]

I really think transparent distribution is a trap. If two modules are inside a process and there's a function call, it's not the same thing as doing a network call with all the failures mode this imply. A distributed monolith can be great, but it should almost never just be a single monolith broken up and connected with "transparent" network.

[@aidantilgner]

This was an excellent talk!

[@ivicamajmunskikreten9714]

monolyth...microservice...modular monolyth... distributed monolyth... at this point I'm just going to claim the word hieroglyph for apps that you're not sure what they're supposed to be. everybody tailors their apps to their needs and services they provide. there's no such thing as good or bad until they've experienced PROD.

[@nfuryboss]

Very well presented!

[@АртемАрте-г5х]

in a large company hundreds of developers commit to the same repository of this module monolith. For sure you'll have some dependent, shared files made by junior\middle developers. you'll get +100 commits each day and rebase will become something like crazy conflicts resolving of

[@jeremiahgavin9687]

Yes, I agree. He does mention in this video that FAANG type companies adopted micro-services for these reasons and more. He clearly says that adopting micro-services early in the development of an application CAN cause large issues in the design of the system as a whole. This video is still valid in the face of your point; which is also good.

[@airman122469]

The scalability argument for micro services has always been a little suspect to me. It’s not really universally true, and most of the time the scaling is not totally linear anyway. There will be a point at which there will be a bottleneck in the system as a whole.

[@laughingvampire7555]

back in 2003 when I was in college I got into a course for clusters and making programs to run in clusters with an mpi library in c, I learned that moment that the cost of sending a message to another computer is extremely high that is so much better to run super optimized single threaded monoliths and partition by data than sending mini packages. micorservices was just used as a pretext to incorporate new technologies or to make work different technologies in the same project, like java for somethings, ruby for others, python for others, etc. Even in Erlang they suggest you to start with a monolith process and then fragment in processes as you progress and learn how your program performs. Then in my first work, it was a bank, and the whole site was divided in different applications, all connected by a single gateway application, the frontpage that had all the links to everything, this apps were written in ASP2, .Net1.1, .NET2 and Java, they all had the same assets and the site looked with a standard style and the only way you could knew you were changing of app is through the url. So it was a modular monolith.

[@AlgoristHQ]

With the invention of the protobuf, better hardware, and more resilient containerization technologies, this isn't true anymore.

[@ctcsys]

Best breed bundles will replace Monoliths.

[@mediahost2243]

Really good talk😊

[@mattchaney2559]

Your presentation style demands that people read the screen. It would be better if you didn’t force this necessity

[@aslkdjfzxcv9779]

i

[@beachbum868]

All the things discussed were available and considered best practice in mid to late 2k's. Microservices never made sense, it was all marketing and PR. MacroServices is just SOA. old hat.

[@AlgoristHQ]

Microservices make sense, its just that most developers never made the leap from monolith to microservice. Monoliths are about entity and crud operations generally. Microservices are about entities and the events that happen to them. Its a very different thought process.

[@beachbum868]

@@AlgoristHQ this is why I say MS's is a religion. There isn't any actual tangible reason why it's better, it's because "you think different" or "monoliths can't process events, kinda"

[@kaibe5241]

They're really not, they're nowhere near as complex.