4 ms·

> The problem with monoliths is when you have a million LoC Java application that is on Java 6, and will take months of work to get up to date, take 20 minutes

> The problem with monoliths is when you have a million LoC Java application that is on Java 6, and will take months of work to get up to date, take 20 minutes to load on a dev machine, starts to fail because its getting too big for a dev machine to handle, can't bring in any new dependencies because of how old the Java version is, and has an old bespoke Ant + Maven + Jenkins + Bash + Perl build and deploy system that has been built up over the last 30 years. - a million LoC Java application that is on Java 6 -> Congrats, now you have two half a million LoC Java application on two different Java versions. And if the set up is like most apps, you will likely need both running to debug most issues because most issues happen at the system to system interface - take 20 minutes to load on a dev machine -> that is fair enough, I have only ever seen an app that takes that long on a modern machine once, most shops doing micro services don't have apps that big - has an old bespoke Ant + Maven + Jenkins + Bash + Perl build and deploy system that has been built up over the last 30 years -> you can have the same problem on a micro service architecture, you can actually have that problem multiplied by 10 and now you can spend a whole sprint updating dependencies. Fun! Breaking off pieces of the code into microservices that can run on a new Spring boot and can run on a newer nice IaC set up is an easy win -> You conveniently forget to mention the additional team to fix issues related to system to system communication

tracker1 11mo ago
> > has an old bespoke Ant + Maven + Jenkins + Bash + Perl build and deploy system that has been built up over the last 30 years > you can have the same problem on a micro service architecture, you can actually have that problem multiplied by 10 and now you can spend a whole sprint updating dependencies. Fun! Definitely true... Not to mention when your entire orchestration becomes too big to run anything locally, that's where the real fun and complexity starts. There's definitely such a thing as too many micro-services, or too micro for that matter...
jimbokun 11mo ago
You are focusing on the hyperbole to ignore the basic point: being unable to change, build and release different parts of the code independently can and eventually will bring your development velocity to a crashing halt.
- netdevphoenix 11mo ago
  Sure you can release quickly, but when your whole constellation of services is too big to be run on a local machine, your development velocity will also come to a crashing halt
simianwords 11mo ago
> And if the set up is like most apps, you will likely need both running to debug most issues because most issues happen at the system to system interface wrong. well architected services would have a good interface and problems rarely span multiple services. >- has an old bespoke Ant + Maven + Jenkins + Bash + Perl build and deploy system that has been built up over the last 30 years -> you can have the same problem on a micro service architecture, you can actually have that problem multiplied by 10 and now you can spend a whole sprint updating dependencies. Fun! this is no un-nuanced. the point is if you have decomposed the codebase into smaller ones - migrations are easier.
- netdevphoenix 11mo ago
  Surely if your monolith codebase is good enough, migrations will be easy too. And a well architected system can be run on a single machine. If you don't believe me, try running windows 95 on your machine. These are True Scotsman fallacies that devs often use to justify whatever paradigm/philosophy they believe in. Most code in the wild is not perfectly designed or if it is, it doesn't stay so for long. Paradigms that rely on optimal conditions to work decently aren't universally useful imo. If your car only works on pristine, smooth roads, it's not a good car, no matter how many cool features it has or how fast you can ride it.

tracker1 11mo ago

> > has an old bespoke Ant + Maven + Jenkins + Bash + Perl build and deploy system that has been built up over the last 30 years > you can have the same problem on a micro service architecture, you can actually have that problem multiplied by 10 and now you can spend a whole sprint updating dependencies. Fun! Definitely true... Not to mention when your entire orchestration becomes too big to run anything locally, that's where the real fun and complexity starts. There's definitely such a thing as too many micro-services, or too micro for that matter...

jimbokun 11mo ago

You are focusing on the hyperbole to ignore the basic point: being unable to change, build and release different parts of the code independently can and eventually will bring your development velocity to a crashing halt.

netdevphoenix 11mo ago
Sure you can release quickly, but when your whole constellation of services is too big to be run on a local machine, your development velocity will also come to a crashing halt

simianwords 11mo ago

> And if the set up is like most apps, you will likely need both running to debug most issues because most issues happen at the system to system interface wrong. well architected services would have a good interface and problems rarely span multiple services. >- has an old bespoke Ant + Maven + Jenkins + Bash + Perl build and deploy system that has been built up over the last 30 years -> you can have the same problem on a micro service architecture, you can actually have that problem multiplied by 10 and now you can spend a whole sprint updating dependencies. Fun! this is no un-nuanced. the point is if you have decomposed the codebase into smaller ones - migrations are easier.

netdevphoenix 11mo ago
Surely if your monolith codebase is good enough, migrations will be easy too. And a well architected system can be run on a single machine. If you don't believe me, try running windows 95 on your machine. These are True Scotsman fallacies that devs often use to justify whatever paradigm/philosophy they believe in. Most code in the wild is not perfectly designed or if it is, it doesn't stay so for long. Paradigms that rely on optimal conditions to work decently aren't universally useful imo. If your car only works on pristine, smooth roads, it's not a good car, no matter how many cool features it has or how fast you can ride it.