That is incorrect. Microservices do not force you to write good code. I have seen microservices done poorly where each microservice duplicates code from the others, and APIs are not well defined. For example project A has folders "api" "api2", project B has folder called "api", there's another project just called "api" which also has logic mixed in unrelated to APIs. Files named "server" that actually implement a client, etc.
It doesn't matter if your API is an http endpoint or a local function call, if you suck at naming things, your API will suck.
> You gain a lot of extra fault tolerance.
Also not true as a "fact of matter". You have to account for API requests between your own infrastructure failing. Adding more system boundaries reduces fault tolerance.
> Since both scaling and reliability directly impact the end user experience, they will be given more weight than the microservice tech debt.
But your competitor's monolith might run on one server. They might implement reliability with a passive failover server, and they might forgo the tech debt & focus on adding new features, which also directly impact the end user experience. Those features will be harder to shoe-horn into your micro-services if you get the boundaries wrong. All of the sudden you have a scalable "reliable" system no one uses, because your competitor has more features.
> all of these benefits only come when the microservices are implemented well
All of those benefits apply to writing good code in general (microservices or not). The only valid benefit you listed specific to microservices is scaling is easier. But you can still scale a monolith. Just deploy all code to all servers, but only run certain things on each tier of services. So again, you don't really need microservices to do that.
That is incorrect. Microservices do not force you to write good code. I have seen microservices done poorly where each microservice duplicates code from the others, and APIs are not well defined. For example project A has folders "api" "api2", project B has folder called "api", there's another project just called "api" which also has logic mixed in unrelated to APIs. Files named "server" that actually implement a client, etc.
It doesn't matter if your API is an http endpoint or a local function call, if you suck at naming things, your API will suck.
> You gain a lot of extra fault tolerance.
Also not true as a "fact of matter". You have to account for API requests between your own infrastructure failing. Adding more system boundaries reduces fault tolerance.
> Since both scaling and reliability directly impact the end user experience, they will be given more weight than the microservice tech debt.
But your competitor's monolith might run on one server. They might implement reliability with a passive failover server, and they might forgo the tech debt & focus on adding new features, which also directly impact the end user experience. Those features will be harder to shoe-horn into your micro-services if you get the boundaries wrong. All of the sudden you have a scalable "reliable" system no one uses, because your competitor has more features.
> all of these benefits only come when the microservices are implemented well
All of those benefits apply to writing good code in general (microservices or not). The only valid benefit you listed specific to microservices is scaling is easier. But you can still scale a monolith. Just deploy all code to all servers, but only run certain things on each tier of services. So again, you don't really need microservices to do that.