David Heinemeier Hansson: Microservices vs. Monolith
Vložit
- čas přidán 6. 09. 2023
- How should you structure your application? Should you split into microservices or keep your monolith? Watch the full video to find out the suggestions from the creator of Ruby on Rails, and let us know what you think in the comments below.
Check out the home for untold developer stories around open source, careers and all the other cool stuff developers are doing at cult.honeypot.io.
Honeypot is a developer-focused job platform, on a mission to get developers great jobs. Wanna see what we're all about? Visit honeypot.io to find a job you love.
To learn more about Honeypot: bit.ly/4565b77
Follow David Heinemeier Hansson:
Website: dhh.dk/
Podcast: 37signals.com/podcast/
Twitter: / dhh
Follow us:
Twitter: / honeypotio
Facebook: / honeypotio
LinkedIn: / honeypotio
Instagram: / honeypot.cult - Věda a technologie
"Simple as possible for as long as possible."
That's the philosophy to follow not only in writing code, but in business and in life, too.
No way, if you don’t become serious one day and stop having fun then you’ll never make it. And you need to make it before you die.
I don't always agree with DHH, but I always agree with his thought process. He always comes across as pragmatic, just like when he talked about TDD or "test induced damage". A lot of fresher people want to follow what google/big tech do without asking WHY they do it.
Software architect is all trade offs and it's important to think about what we're trading rather than just going with it because that's what others are doing or have been done before. If someone says it needs to be microservices and can't tell you about the fallacies of distributed computing, then it's important to revisit them.
Martin Fawler the creator of the concept of microservices always though about it like this. It is teams based not software. And if each team can have own budget better.
Software architect is all trade offs and it's important to think about what we're trading rather than just going with it - this is the most important sentence and it's what DHH is badly articulating in the video above.
Well put!
Team Monolith here! Microservices have their time and place, but no "miscroservices for the sake of microservices".
What a time to post this video! 😂
Why’s that?
@@headlights-go-up They dropped TypeScript from Turbo and "stired some pots" lol.
@@headlights-go-upAWS is down 👏 😂
@@rcnhsuailsnyfiue2 LOL oh, I see. That's hilarious lol
I thought it was because he dropped TypeScript
Perfect Timing
What's the latest microservice drama ?! 😅
@@FrancoisKerisit he deleted TS from a project and went back to JS
Agree with DHH that monoliths work for 90% of folks out there. The problem is with the word 'microservices'. When you look at your service oriented architecture and that becomes too big for a team to handle the complexity, that's when you should be looking at your domains and find the right separation. It's a "domain-service' that you're separating so you can have a better developer experience and don't have to be held back by multiple teams working on the same codebase.
Dhh is right , but lots of developers are scared of database procedures and want to use the database as a place to dump data , it is a place to secure and enforce integrity of data
IMO business logic does belong in a database stored proc. Not testable or version controlled.
@@nthonymillerGreat point, I agree. Kind of ironic that the one video on your channel is related to stored procedures 😂
@@MrMickmonster haha classic 😆.
Where's the full video?
in DHH we trust, DHH is a smart guy and he knows how enterprise business works, people take fashions and don't think what really work in his company
If only the Twitter guys could understand DHH. He is just a spouse of simplicity and I can tell you that I like that and I am that way too.
People like you don’t get it. Code needs to be completed and hard to understand. Otherwise it’s not serious code. Real software can’t be written in a toy language
what a perfect timing LOL
DHH is the man
Honestly a lot of the things that came out in the past few years I feel like I a dodged a bullet, some are literally just reviving issues we already solved.
I agree with David's point of view.
Thanks for this, my next app will be a monolith approach using Laravel.
The issue of a small team having a broad view over the whole functionality is not an infrastructure deployment strategy problem, it's a workspace management and Developer Experience tooling issue. David infers that the people working on particular services have a narrow view on just that particular service and that everything is organised and deployed separately.
But what's wrong with using a monorepo and enough local tooling to be able to just run as many dependent microservices on your local machine as you need? This essentially allows teams to have the opportunity to dip into that "other service's cron functions" and see how they interact if the dev needs to.
I just worry that making this an "infrastructure deployment strategy" problem will shift the framework of thinking about the reason why you might pick microservices over a monolith. This in my opinion should not be decided by looking at the organisational structure, but rather at the scalability needs of the application and its production behaviour with a main focus on the end user.
You hit the spot right there. Look at the scalability requirements NOT the organisational structure. Being a small team doesn’t necessarily mean no scalability requirements. In fact if you pick the right tooling, achieving economies of scale might even be easier.
Splitting the codebase into microservices for scalability reasons is no longer a valid argument. There have been huge improvements in the last two decades when it comes to processor and disk performance, while programming languages have become more efficient. Even fullstack frameworks writting in dynamic languages, like Django, Laravel or Rails, can handle thousands of requests per second on a moderately-sized server.
Virtually the only valid reason to split your codebase into microservices and pay the performance penalty caused by inter-service communication (you can't always offload tasks from the normal HTTP request-responce cycle) is because you can map those pieces of code to a distinct business domain . That's what basically all the books on the topic recommend (for example, "Software Architecture: The Hard Parts", by Neal Ford et al, "Monolith to Microservices" by Sam Newman, "Microservice Patterns" by Chris RIchardson, "Building Event-Driven Microservices" by Adam Bellemare or "Strategic Monoliths and Microservices" by Vaugh Vernon et al) and not applying this principle generally creates a distributed monolith., which has all the coupling of a monolith and all the drawbacks of a microservice.
Hahaha “scalability requirements” 🤣 Hilarious. So many meetings to be had and decisions to be made because we’ll have to scale one day. Look around you man.
100% agree
This is just another way to look at Microservices IMO, micro-services is also about separation of functions, this will then determine what stacks best suit each service, the team and tools etc. But I do agree that for a small MVP or bootstrapping teams, microservices shouldn't be the focus unless you have an experienced architect that can properly setup the system bearing in mind your limited resources
Imagine having to get a list of users attached to some entity, for example a shop. You make a call to the shops service find out all user ids attached to that shop. Now you take these ids and send it some auth/user service to get user details, right. Now imagine having to paginate these users ordered alphabetically by first name and limited to 10 users per page. But wait you only have a list of user ids in the first place. Now you have to send all those hundreds maybe thousands of ids to the user service and and ask it to hopefully do all that pagination logic.
This just a simple scenario of how microservices can get complicated. This can exponentially get more and more complicated as you have more logic and are tracing logic through network calls. There are ways to solve this of course, but is it worth it really! If you really have a small team and you're running a startup and want to compete....fast. Think about that for a second.
this is a design flaw rather than an micro-service flaw, when you know the calls you are making, you build your microservices to fit the purpose, you don't just build typical crud endpoints.
Microservices are about separation of functions, so a service that does certain functions should carter for those in the best way possible.
@@neneasegh If there is a design flow in a monolith, that would be acceptable as there will be many eyes looking at the same problem and pointing it out. If that was the case in microservices, only specific service owners will feel the pain. And will require non-owners make changes outside of their scope. That feeling of owner/non-owner in my opinion is a death trap and a way for people to point fingers and delay deliverables.
If you have a competent architect designing everything from the get go which I doubt, I don't believe he/she will get all right or can foresee requirements changes 1 year down the line. Even the matrix's architect fucked up in the 7th iteration. I'm sure you understand that software is malleable and changes all the time. Having to juggle multiple pieces is defiantly harder and costlier. Not saying we shouldn't do microservices, just saying try to avoid them as much as you can.
@@moeabdol_ In a medium sized company with multiple teams / departments you will have owners and non-owners, there's no way around it and that's the point of all the fuss. A monolith will not solve that issue and badly sliced microservices will neither. If 3 teams are telling you 3 different things how your software should behave, you will still feel pain. Or if the IT team of a different department is adding funny features to your stuff, because they are working on the same part of the monolith as you do. It is all about separating things which need to be separated, and that can be done with both, microservices or a well architectured monolith. And you can also screw it up badly with both.
If this scenario is a challenge for you, maybe you should consider a GraphQL aggregator in front of a bunch of microservices.
@@DejayClayton yeah or just have a “customer pagination aggregator service” that does one thing and does it well. We can later enrich that data with a customer emoji service when the need arises.
Interesting, but how will Monolith DevOps tech stack look like? We still need containers (and k8s for orchestrating/scaling them), right?
To horizontally scale you don't _need_ containers, k8s or anything of these 'new' sorts of stuff. It might be just easier to do it with new tools in the cloud era.
I don’t agree with DHH on TDD but I certainly agree with his argument here. Whether a module lives in the same process or runs on a different computer should just be a detail hidden by an interface. Just because you build a monolith doesn’t mean that you have to create a big pile of spagetti shit. No! You can and you should isolate different concerns in your components and maintain clean code regardless. If you do that, you will, if needed, easily be able to extract certain parts as microservices without breaking your architecture.
He is so well-spoken and pragmatic. I don't understand why some influencers hate him (I'm mainly TS developer and don't know Ruby btw)
The fact that you don't know Ruby is why you don't hate him.
@@DejayClayton I know ruby and dont hate him. Why would you hate him based on ruby?
@@DejayClayton People dont like him because he is very opinionated
@@etc1702I think everyone is very opionionated, but most dont admit that
I don't like this type of comparison, it's to strict and safe. I prefer my code break at runtime not compile time :)
tbh, you have to have a high IQ to use vanilla JS, not to brag or anything
@@ouss yeah sure, and then you get a UNDEFINED randomly on a webpage and good luck debugging and finding that
I don’t like this type of comparison, it’s too fast and productive. I’d prefer my features to roll out every few months and my bugs to take weeks to solve not hours :-|
You know Micro-Services are distributed micro-monoliths that are focused on single responsibility.
But if we work like Netflix, we'll get as big as Netflix...right?!?
Like throwing React in every project. Maybe if we use Facebook's tools, we'll be as successful as Facebook even when our team looks nothing like their team.
Who picks React as a tool with their reasoning being 'we'll be as big as Facebook'? What a braindead comment.
monolith in Elixir with Phoenix.
Yeah, micro-services only works between multiple teams. It just slows down a single team. But my team doesn’t have 20, 50, 100 devs… it has 2 :/
If it's for that then there is nothing micro- about it.
@@mirekrusin shhhh 🤫 don’t tell them their customer service isn’t micro anymore and basically only their auth service is.
I like microservices because the team can focus on one service and forget about the layers of complexity later down the road. Example our ERP does a bad job managing products we customized it until the PM‘s could not use it anymore. Now we develop a PLM Microservice to manage our productcatalog only and forget about all the other ERP and CRM implications.
Well that's just TMFA
An ERP is an example of a real monolith. When your time tracking and e-commerce and help desk are all the same system.
But then you get people who've never even heard of such a thing and they think their shopping cart needs to be split up into 200 smaller pieces because it was originally written in 2015 so it's bad, legacy, monolith.
Microservice crowd likes to pretend that coupling doesn't exist in their architectures, however it turns out simple fact of using something does couple things together.
Coupling is also output of sharing and applying DRY principle.
In most projects changing/adding/removing something in one place and seeing immediate effect it creates (ie. type errors in other service, failing tests for other service etc.) is a good thing, it means whole new functionality can sit in single PR (addition/modification, changes across all services that are using it, tests etc.) and can be squashed to give readable trunk history with 1-1 mapping to project tracking system.
You can build a monolith in which the PLM module does not fuck around with the data of other ERP modules and vice-versa. Separate model, db schema, dedicated communication interfaces between the modules. It is possible to build such things in a highly decoupled way, but without making network calls and separate deployments necessary. But admitting, it requires highly skilled people to not screw it up. Probably sometimes easier to just go full microservice.
Micorservice is premature optimization.
ONE team at Amazon rolled back. And they were excessively using lambdas (and incorrectly so). The entirety of Amazon is still (micro)service based.
As a rule of thumb, start monolithic and split when you feel it would be easier to manage the codebase. Perhaps if you have 20+ teams you don't want them all working on the same codebase. Split also when you want separate deploys to scale horizontally perhaps (but first profile and make sure horizontal scaling is the solution). Basically, don't split into new services by default, but do consider it a tool in your arsenal. Don't be dogmatic, don't engage in "mono vs micro" wars, don't be stuck in a school of thought. Be pragmatic.
You see your problem is that you’re not picking a side. You simply can’t live in a world of in betweens. Sorry. It’s either one god, or millions. Nothing in between makes any sense. Heathen.
Summary: "Use the right tool for the job."
these level of decisions are only relevant if you're a big fish. like who cares in your 100 users if you're using microservices or not. as long as it works.
The people who have to write the software care.
It's more about building your app with an eye toward organizational and technological scaling than anything else. Is it really any wiser to write a giant lump of tech debt that will only hamper your ability to quickly scale up and out when you could take some basic steps early on that could enable you to scale as needed? Microservices don't have to be absurdly complex, but to build a basic architectural foundation on which you can build services is wise, imo.
I often agree with what DHH says, but I still don't like Rails and how prescriptive it is.
just that you built microservices
doesn't mean you didn't build a monolith
based
yes, and just like my boss recently realizes the fact that microservices is a big problem, team with several devs applies microservices is a joke
The huge drama was created because of one guy who took the advantage of the situation. He just wanted to put his frustration of listening to an opposite VERY STRONG opinion, so he USED his followers to bully his opposing VIEW. How right is this?
Last time he did the same on react repo to FORCE people to see that his view was the ultimate. The problem wasn't making a genuine PR to invite comments, instead he drove his bullish followers along with him in it. Now, he did the same on dhh's repo. Shame on you dude.
The guy is Theo.
Don't blame me I just got here!
I beg to differ microservices allows us the ability to be more nimble/elastic thus allowing/ enabling features like autoscaling
You obviously haven't worked in a microservice environment.
Microservices allows for Multi- tenant environment
When we speak of a monolith
Are we going as far back as a JVM running on a Windows Server box ?
Your Quote "Replacing all your method calls with Network calls" is where Microservice implementations will FAIL. IMO this is the wrong approach, the systems need to be decoupled by was a messaging system using Event Driven Architecture principles. EDA provides fault tolerance for various sub-systems to go offline and for recovery to occur.
Network calls includes not only point to point rest/grpc calls but also event driven messages over any broker. If the implementation involves calling a function outside its own process, it is likely using the microservices pattern.
Sure. IF you can tolerate being "eventually consistent". If you work in finance or medical or any of these other mission critical type systems you may need actual consistency instead.
@@kray3883 I understand the complexity in certain scenarios, but it's not just about being eventually consistent, it's about background processing of tasks.
@@nthonymiller I should have been more specific, it's not that I'm a fan of synchronous network calls, but that people choose to split up systems in ways that are unnecessary and inappropriate in order to chase the microservice dream. And once you've done that no amount of event driven architecture will save you, instead you will just be on outage calls monitoring the rising number of messages in the queue while waiting for some other team to fix it please. (Truly. My running joke is that it would be easier to have an alert when all queues are under their SLA levels.)
There are well-known patterns and best practices on decoupling and modularization that you can (and should) apply in a non-microservice (monolith) application
What a coincidence
Microservices is about independent deployment. It's not about separation for teams.
Conway's Law states your system structure mirrors your team structure. They are related.
@@zAlbee2 absolute non-sense. You can and should separate your concerns regardless of your deployment strategy. You can do that just as well with a 'monolith'' service. If having a 'monolith' service means to you that you have no separation of concerns you should give up programming.
@@bartholomewtott3812 Yes, of course separation of concerns is good practice. I'm not sure how you inferred the opposite. I didn't say anything about that in my comment.
@@zAlbee2 system structure includes separation of concerns in fact it's a fundamental ingredient.
@@bartholomewtott3812 Sounds like you have it all figured out then. What's the microservice to team ratio in your org?
Microservices allow finer-grained scaling.
The need for independent scaling is overexaggerated. If your services depend on each other in any way, they most likely need to scale together anyway, otherwise one would just bottleneck the others. Like my colleague says, it's about as useful as having 4 independently sized wheels on your car.
Even if your microservices were truly independent (no communication) and could successfully scale independently... Have you really saved that much by scaling just A and not scaling B? Yes having both A and B in the same monolith means you increase resources to run B when you just need more A... But it's a monolith. The resources are shared! They haven't gone to waste just because B isn't using them.
Scaling independently is nowhere near as useful as proponents say. Where smaller services do help is in fault isolation and faster turnaround time for development, testing, and deployment.
@@zAlbee2 The car analogy doesn't seem apt since, usually, not all the services are the same.
You probably have more experience in this realm, but I'm thinking of a monolith needing a certain size CPU and memory, and when either of those limits is hit, a whole new instance is spun up. So, the increment size is large.
And yet, every startup I've been at that has lasted for at least 10 years has spent YEARS breaking up Ruby on Rails monoliths into microservices. Why? Because RoR monoliths are too hard to maintain, slow to innovate upon, and contain massive amounts of defects. It doesn't help that Ruby has several layers of magic that essentially destroy the ability to reason about the functional nature of the code base, or avoid hidden surprises. Ruby on Rails particularly is too opinionated in all the wrong ways for teams that need to diverge from each other in their working style and requirements. Thus, I'll take a hard pass on taking advice from Mr. Hansson.
Listen, as someone at a large fintech that has fully migrated from a Rails monolith to dozens of microservices in Kotlin/Java running in Kubernetes with all the autoscaling bells and whistles and eventing via Kafka and data pipelines etc. etc…. I can say that the attitude you are showing is very similar to practically everyone I worked with that learned Ruby and Rails for the first time while working on an existing monolith.
Because they hadn’t seen good Ruby codebases, and they hadn’t been excited by the features of the language/framework, and they didn’t have anything they wanted to try and experiment with. Because all they saw was something bad that they wanted to move away from.
Imagine every single part of your experience was the same, except it was a Java Spring monolith. I guarantee you’d be feeling way way worse about those technologies. I would put serious money on it.
Hating on a technology that others love is doing harm to the industry. Especially if you have never experienced it flexing its muscles.
I run Neovim and Arch (btw).
@@HikarusVibrator The following reddit comment regarding "ruby on rails magic" best describes my view of the situation: "You start knowing nothing and the magic works and you get a lot done. Then you encounter somewhere that the magic is not doing what you expect and you are confused. It is hard to trace and you complain to people that rails has too much magic. Then eventually you understand how the magic works and you're ridiculously productive." The problem is that too often, developers within a project change, and no one has infinite time or attention to learn and comprehend all the magic. Thus, instead of being "ridiculously productive", most developers will just try to fix a production bug quickly, and wrongly, so they can get back to what they were supposed to be working on. Because of this, I would prefer to have a straight-forward solution that doesn't rely upon magic at all, and is instead easy to reason about even if one completely lacks subject matter expertise.
@@DejayClayton okay so let’s not have something “ridiculously productive” around because our developers will have to become real engineers one day and spend thousands of hours learning Spring and JVM magic instead for all the serious code the world needs.
The real magic of ruby has nothing to do with “rails magic”. The real magic is it’s unbelievable expressiveness and low barrier to entry. And it’s hated for it.
Similar sentiments have always been held towards javascript, but the difference was that “serious” engineers were never as jealous towards javascript kids as they were towards the people coding in that other toy language that people earn too much money for.
Human beings amarite. And now people are salivating over the prospect of dancing on ruby’s grave.
We sure told them.
@@HikarusVibrator JavaScript has much less "magic" behind the scenes. It's easy to understand how logic is programmed in JavaScript, because we never have to worry about things like meta-programming, magic methods, overly-deep convention, etc.
Can’t wait for all the frothy typescript nerds to come in here and prove DHH wrong with their todo apps.
Also can’t wait for the social media influencers to argue against DHH so they can sell courses to more idiots 😂
Can't wait for DHH to tell us all how is it is to maintain Basecamp after the next re-write
> ...with their todo apps.
I can't tell if this is trolling or a really ignorant argument.
Cringe