4 ms·

I ended up having a weird debate on Reddit over this. For some reason people seem to think that there is a single better choice and that if you ever go from a m

I ended up having a weird debate on Reddit over this. For some reason people seem to think that there is a single better choice and that if you ever go from a monolith to microservices that the monolith failed or whatever. One person even made the claim that microservices are easier to maintain and debug even tho a single code base that you can use tools on and easily keep in sync seems miles easier to maintain than microservices where you need to version your interfaces so older services continue to work while you upgrade newer versions. Then they were talking about with a monolith it takes longer to deploy. I assumed their actual deploy tasks took longer, which I can kind of see. But it turns out they were talking about how often they deploy. It seems nuts to me that people think switching to microservices from a monolith will suddenly mean their poor practices that got their monolith into a bad state will suddenly disappear. From my experience, it generally just means they develop a distributed monolith and have all the same problems with some extra problems. I'm of the opinion that if you can't develop a good monolith system you can't develop a good microservices system. A good microservices system while it has it's benefits is, in my opinion, harder to architect, develop, and maintain than a microservices based system.

janosdebugs 3y ago
Funnily enough, both things can be true depending on the context. Microservices are easier to debug: sure, if you compare a single monolithic binary with no logs and trace points to a microservice system that runs on top of a fancy trace the heck out of everything service mesh. Logging is still hard. Deployment time: the same reason why people wouldn't compile dependencies statically. It's easier to replace a .dll or .so than the entire application, less bandwith. However, mess up the versions and you end up having a really bad day. Same with microservices: sure, a tiny service is easy to deploy, but heaven forbid you deploy incompatible versions. etc etc. Microservices give people who don't have an architectural view/experience in building complex systems from scratch a framework to put their stuff in without thinking much about it. Good luck getting the same level of organization in a monolithic NodeJS application. It's hard, even seasoned veterans often get the abstraction layers wrong.
- marcus_holmes 3y ago
  I think part of the problem is that people who are wildly enthusiastic about microservices haven't experienced DLL Hell and don't understand the problems that can happen.
  - janosdebugs 3y ago
    No argument here, I personally don't think microservies are the solution to code organization problems. However, many ecosystems don't have a good structure that lets less experienced coders work efficiently on large-scale systems (NodeJS, Go, etc.)
- that_guy_iain 3y ago
  > Deployment time: the same reason why people wouldn't compile dependencies statically. It's easier to replace a .dll or .so than the entire application, less bandwith. However, mess up the versions and you end up having a really bad day. Same with microservices: sure, a tiny service is easy to deploy, but heaven forbid you deploy incompatible versions. That argument I could understand. But their argument turned out to be that they thought a monolith meant everyone has to spend weeks between deployments. So it wasn't how long it took do the deployment but how often they could do deployments. Which is entirely a process matter. With microservices in my experience it can turn in to a mess of we need to sync our deployments because they built a distributed monolith. To be honest, most of their arguments seemed to be they had tons of technical debt and blamed that it was a monolith for the technical debt existing than the fact it's technical debt. > Microservices give people who don't have an architectural view/experience in building complex systems from scratch a framework to put their stuff in without thinking much about it. Good luck getting the same level of organization in a monolithic NodeJS application. It's hard, even seasoned veterans often get the abstraction layers wrong. If you don't have the discipline to keep things organised in a monolith how are you going to manage with microservices? Especially, when there are literally tools to help you do this in monoliths. This is how people end up with distributed monoliths. Is building a high quality monolith hard? Yes. Is it harder than building a high quality microservices system, I would say no.

janosdebugs 3y ago

Funnily enough, both things can be true depending on the context. Microservices are easier to debug: sure, if you compare a single monolithic binary with no logs and trace points to a microservice system that runs on top of a fancy trace the heck out of everything service mesh. Logging is still hard. Deployment time: the same reason why people wouldn't compile dependencies statically. It's easier to replace a .dll or .so than the entire application, less bandwith. However, mess up the versions and you end up having a really bad day. Same with microservices: sure, a tiny service is easy to deploy, but heaven forbid you deploy incompatible versions. etc etc. Microservices give people who don't have an architectural view/experience in building complex systems from scratch a framework to put their stuff in without thinking much about it. Good luck getting the same level of organization in a monolithic NodeJS application. It's hard, even seasoned veterans often get the abstraction layers wrong.

marcus_holmes 3y ago
I think part of the problem is that people who are wildly enthusiastic about microservices haven't experienced DLL Hell and don't understand the problems that can happen.
- janosdebugs 3y ago
  No argument here, I personally don't think microservies are the solution to code organization problems. However, many ecosystems don't have a good structure that lets less experienced coders work efficiently on large-scale systems (NodeJS, Go, etc.)
that_guy_iain 3y ago
> Deployment time: the same reason why people wouldn't compile dependencies statically. It's easier to replace a .dll or .so than the entire application, less bandwith. However, mess up the versions and you end up having a really bad day. Same with microservices: sure, a tiny service is easy to deploy, but heaven forbid you deploy incompatible versions. That argument I could understand. But their argument turned out to be that they thought a monolith meant everyone has to spend weeks between deployments. So it wasn't how long it took do the deployment but how often they could do deployments. Which is entirely a process matter. With microservices in my experience it can turn in to a mess of we need to sync our deployments because they built a distributed monolith. To be honest, most of their arguments seemed to be they had tons of technical debt and blamed that it was a monolith for the technical debt existing than the fact it's technical debt. > Microservices give people who don't have an architectural view/experience in building complex systems from scratch a framework to put their stuff in without thinking much about it. Good luck getting the same level of organization in a monolithic NodeJS application. It's hard, even seasoned veterans often get the abstraction layers wrong. If you don't have the discipline to keep things organised in a monolith how are you going to manage with microservices? Especially, when there are literally tools to help you do this in monoliths. This is how people end up with distributed monoliths. Is building a high quality monolith hard? Yes. Is it harder than building a high quality microservices system, I would say no.