Modular Monoliths Are The New Microservices
Вставка
- Опубліковано 3 чер 2024
- Microservices aren't all they're cracked up to be, let's try a different tack!
The complete session and speaker details below.
🔴 Subscribe for more Code PaLOUsa and other software development videos:
/ @talelearncode
This was a presentation given at Code PaLOUsa 2020. Code PaLOUsa is a software development conference designed to cover all aspects of software development regardless of the technology stack. The conference schedule features presentations from well-known professionals in the software development community.
✅Check-out the Code PaLOUsa website for more details: www.codepalousa.com
🖥️ Be sure to check out other Louisville Azure Meetup videos: • Code PaLOUsa 2020
_________________________________________________________________
✅Check-out the TaleLearnCode Twitch stream Monday, Wednesday, and Friday at 8:00 pm EDT: TaleLearnCode.tv
⭐ Useful Links ⭐
► Code PaLOUsa: www.codepalousa.com
► Code PaLOUsa 2020 Archive: cpl20.codepalousa.com
► Code PaLOUsa on Twitter: / codepalousa
► Tale Learn Code: TaleLearnCode.tv
_________________________________________________________________
💸 Support The TaleLearnCode Community 💸
Donations are not required but are greatly appreciated. Any money raised through donations, subscriptions, etc. is used to help cover the costs of running the TaleLearnCode channels, speaking at events (when we can travel again), and organizing meetups, user groups, and other community events.
💸Subscribe On Twitch: / ticket
💸Donation Support: streamelements.com/TaleLearnC...
_________________________________________________________________
⭐ Modular Monoliths Are The New Microservices ⭐
We've finally reached the trough of disillusionment on Microservices, and people have realized that they are not Magic, nor are they easy. Most of the supposed "benefits" of Microservices can achieved without that added complexity though. Let's discuss some strategies for how you can design your applications to be amazing without the overhead and complexity of resorting to Microservices.
⭐ Deven Phillips ⭐
Deven is a Senior Consulting Engineer with Red Hat's Cloud Native Application Development Practice, a program focused on helping organizations build cloud native software to market more quickly. The practice brings together open source tools, methods, and open culture to help companies become more innovative. Deven is proficient in many popular programming languages, as well as experienced in a number of different architectural platforms. Deven specializes in Microservices, Cloud, DevOps, Design Thinking, Domain Driven Design, and Kubernetes to create solutions which delight customers. - Наука та технологія
I can't believe this video has only 1700~ views. It should be mandatory watching material for every single architectural astronaut and developer.
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
9 months later, it has 8.5k
Because this video is bull shit from those who could learn how to implement microservices and when to implement micro services?
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.
I agree with the other comment. Every engineer needs to watch this. Micro services should be rarely used
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.
This was an excellent talk!
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?
Very well presented!
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?
That's why we should use ddd.
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.
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
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.
Really good talk😊
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.
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.
With the invention of the protobuf, better hardware, and more resilient containerization technologies, this isn't true anymore.
Best breed bundles will replace Monoliths.
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.
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.
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.
@@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"
i