If the alternative to microservices is a monolith, and you can run the monolith locally, then logically microservices can also be run locally. If it's difficult to run all the microservices locally then that's just a sign of weak tooling.
Why does technical overhead take a backseat whenever a microservices vs monolith discussion comes up?
Yes, in a perfect world every org would have sufficient time and engineering resources to implement microservices for better scalability and code quality. In the real world, setting up and maintaining microservices has huge technical overhead, I'd estimate double that of the equivalent monolithic architecture.
If your company isn't flush with cash and the product you're building will never need massive scaling then it makes no sense to use microservices, at least from a business perspective.
There are many business reasons to use micro-services not only technical ones. In our org we could hire developers fast as we can use multiple programming languages (we have few approved stacks, as micro-services do not share code base).
It allows us split out teams in to small agile units. That can e.g. deploy independently.
Getting new developers on-board take less time as they work on few small services and they do not need to be aware of the whole code base (at the begin)
Yes I agree there is technical overhead, and proper CI&CD servers are required, docker or e.g. vagrant is a must with micro-services. But including all the benefits I wouldn't say that we loses 2x more time than having monolithic architecture.
"Why does technical overhead take a backseat whenever a microservices vs monolith discussion comes up?"
I don't think it does, but that's kind of off topic.
"In the real world, setting up and maintaining microservices has huge technical overhead, I'd estimate double that of the equivalent monolithic architecture."
What a ridiculous statement. Splitting a single process into N processes with no shared memory multiples startup memory by N. It takes a much beefier system to run 8 JVMs than one. The same goes for 8 Python processes. Matters are worse on a VM, which you probably are since basically every shop out there issues developers a Windows or OSX machine. Or maybe you don't have "weak tooling," as you put it, and everything's containerized, using even more resources.
"Splitting a single process into N processes with no shared memory multiples startup memory by N. It takes a much beefier system to run 8 JVMs than one. The same goes for 8 Python processes."
I agree, but I haven't seen the amount of memory ever being a limiting factor when running multiple microservices on a local developer machine. I'd estimate that you can run at least 50 JVM, Python and Node.js processes on a typical single machine, and most applications consisting of microservices have 50 or less microservices.
> I'd estimate that you can run at least 50 JVM, Python and Node.js processes on a typical single machine
Unless someone has convinced you that Spring is the right way to build microservices, in which case you're going to need a gigabyte per instance, and most people won't be able to run 50 on a typical machine. I worked on a project like that, and our beefy iMacs really laboured to bring up ten services.
It's not just the runtime. Each Python process will redundantly import modules. The same goes for libraries in a Java project. It definitely adds up, and I have seen memory usage be an issue, particularly on VMs.
Yes, the tooling is weak. Now, let's convince the engineering managers to spend a bunch of time building tooling to start everything together and fix service discovery on localhost. Turns out, they'd rather build features.
I'm with you 100%. It drives me crazy, but right now you cannot run multiple services locally without a bunch of fiddling.
It's not impossible. As a sibling comment says, it usually just requires a bunch of ad-hoc scripts to make sure everything is running. This does get increasingly complex, especially as microservices are written with different stacks, but that's part of the tradeoff.
