Could just as well be at no additional cost. If your monolith separates services somewhat cleanly then you can run them on every node and not even touch the part of the codebase that's not related to the current task.
I wasn't talking about the cost of touching the codebase, but rather running a monolith horizontally with an overhead in terms of CPU-, disk- and RAM-usage.
For big companies it might me a miniscule difference, but for smaller companies it can be a deal-breaker.
Running costs or development costs? If you have a low-request / high complexity persistent application you may want to optimize for maintainability. Having all the code in one place _can_ make things easier to figure out in the long term.
> Having all the code in one place _can_ make things easier to figure out in the long term.
My experience is the exact opposite. A huge monolith makes it harder for developers - especially new ones - to get a grasp of how everything is connected. A separation of concern into micro services is sometimes a good solution.
You mean the few extra megabytes of RAM for some extra compiled code on each node?
If you refer to databases: Splitting one service into two services can at most give you a 2x scale-up potential (usually a lot less), and the effect diminishes for 3th, 4th service. Mathematically and logically. Splitting services = vertical scaling.
If you want 100x, 1000x scaling you need to invest in true horizontal scaling anyway, and that works pretty much the same way for monoliths as microservices.
> You mean the few extra megabytes of RAM for some extra compiled code on each node?
Few extra?
Have you not considered applications where you need to spin up/down _extremely_ resource intensive instances?
A year++ ago I worked on a health-related application which used a system for processing X-ray images. During typical work hour (6 am-6 pm) it required a _huge_ amount of CPU and RAM instances. By shifting those specific services out to specialised instanced, we saw a $50K/month saving.
The rest of the application is a lot more lightweight, but of course has to run 24/7, but being able to spin up/down required instances, and just pay for what you use, is a huge benefit for a lot of companies and organisations.
A monolith is not a giant blob that has to run fully on one instance or else nothing works. Although I'm sure plenty of horrible enterprise software works that way, it is not a property of a monolith.
I maintain a SaaS written as a monolith and I can absolutely spin instances that only load one part of the code and do a single thing, for example some instances only handle MQTT messages while others only serve HTTP endpoints. That does not make it microservices, it is all one code base sharing one database.
Overhead is way worse with microservices once you talk about network latency, database cost, infra for logging and monitoring, labor to manage that, and developer cost. Way, way, way, more than spinning up ten more identical webapps.