> There are plenty of monoliths that scale in terms of number of contributors and organizational changes. For example, the Linux kernel. I've worked on massive monoliths that were 20 years old and changed hands and org structures tons of times and nobody ever thought "this needs to be microservices!"
> Microservices are not the only way to modularize code.
Nobody said that it was the only way to modularize code.
However, but to be frank, most of those require greater discipline than most of the engineering teams going to microservices have. These teams don't do a great job at microservices, but probably would do a worse job with a monolith.
> Also, there is TONS of bike-shedding with regard to HTTP. Which HTTP method do you use? How do you structure your paths? What does the body of the request look like? How to we translate failures into the various HTTP error codes? Do you send a 200 or a 201 status for this particular request? I could go on and on... Even among well established HTTP APIs, there are differences.
You can bike shed anything, that's why it's called bikeshedding. Referring to nobody being able to contribute to the design review of a nuclear reactor so the committee just fights over the color of the bikeshed. That being said, the state space of an HTTP API is strictly smaller than a local library's API, and you can generally expect backend engineers to at least know what complete the state space of options looks like and what the tradeoffs are.
> This is very much a double edged sword. I've seen this happen and people just tend to avoid services in languages/frameworks that they don't know. And even if they don't avoid them, they are less productive in them. We have a critical services written in Rust and one guy at the company knows Rust. We have 2 services written in a particular Java reactive framework which only a few people know how to use. Any newcomers to these services have to spend a lot of time learning a new thing.
The other end I've seen is that having the whole org on one tech stack is a single organizational point of failure. It's not an issue for smaller orgs, but if you have more than say, 200 devs working on the same product, you want a little experimentation and a lower barrier to new technology. If something is abandoned you can simply replace it, since it's not your literal entire stack. And forcing your devs to be polylingual I've found makes them better in all of the language they use, even their primary language.
> Microservices are not the only way to modularize code.
Nobody said that it was the only way to modularize code.
However, but to be frank, most of those require greater discipline than most of the engineering teams going to microservices have. These teams don't do a great job at microservices, but probably would do a worse job with a monolith.
> Also, there is TONS of bike-shedding with regard to HTTP. Which HTTP method do you use? How do you structure your paths? What does the body of the request look like? How to we translate failures into the various HTTP error codes? Do you send a 200 or a 201 status for this particular request? I could go on and on... Even among well established HTTP APIs, there are differences.
You can bike shed anything, that's why it's called bikeshedding. Referring to nobody being able to contribute to the design review of a nuclear reactor so the committee just fights over the color of the bikeshed. That being said, the state space of an HTTP API is strictly smaller than a local library's API, and you can generally expect backend engineers to at least know what complete the state space of options looks like and what the tradeoffs are.
> This is very much a double edged sword. I've seen this happen and people just tend to avoid services in languages/frameworks that they don't know. And even if they don't avoid them, they are less productive in them. We have a critical services written in Rust and one guy at the company knows Rust. We have 2 services written in a particular Java reactive framework which only a few people know how to use. Any newcomers to these services have to spend a lot of time learning a new thing.
The other end I've seen is that having the whole org on one tech stack is a single organizational point of failure. It's not an issue for smaller orgs, but if you have more than say, 200 devs working on the same product, you want a little experimentation and a lower barrier to new technology. If something is abandoned you can simply replace it, since it's not your literal entire stack. And forcing your devs to be polylingual I've found makes them better in all of the language they use, even their primary language.