It is easier to isolate business logic with a microservice architecture, but as the microservice graph gets more complicated so too does administering it.
How do you make graphs that make sense of your various microservices? How do you make sure code doesn't get stale/all versions are compatible/rolling back code doesn't take out your website? How do you do capacity planning? How are service specific configurations done? How does service discovery work? How do you troubleshoot these systems? How do you document these systems? How do you onboard new people to these systems? What about setting up integration testing? Build systems? Repositories? Oncall? What happens when a single dev spins up a microservice and they quit? What happens when a new dev wants to create a new service in the latest greatest language? What happens when you want to share a piece of business logic of some sort? What about creating canaries for all these services? What about artifact management/versioning?
What about when your microservice becomes monolithic?
Complexity is complexity no matter where it exists. Microservices are an exchange of one complexity for another. Building modular software is a reduction of complexity. A microservice that has business logic mixed with server logic is still going to suffer from being brittle.
I definitely agree. I'm actually thinking that the microservices architecture punishes team earlier for creating a mess, which is a good thing. It forces you to adapt good patterns, because otherwise nothing will work.
I'm not sure, but I feel that with monoliths the teams get punished later and thus create a bigger mess. But I guess it's more like 60/40 rather than 99/1.
An SRE might help you build systems, but that is a lot of system to build depending on number of microservices. Managing the complexity of N services comes at a cost, maybe that cost is in how seamless and wonderful the testing infra is.
A very well built monolith is very easy to manage.
Most product devs want to trivially build a feature, not deal with the complexities of running a service in production. Abstracting away a request handler is going to be an easier overall system than abstracting services.
As for the oncall/onboarding etc, SRE is there to support and enable, not to be an ops monkey, so that stuff scales with number of services/engineers.
How do you make graphs that make sense of your various microservices? How do you make sure code doesn't get stale/all versions are compatible/rolling back code doesn't take out your website? How do you do capacity planning? How are service specific configurations done? How does service discovery work? How do you troubleshoot these systems? How do you document these systems? How do you onboard new people to these systems? What about setting up integration testing? Build systems? Repositories? Oncall? What happens when a single dev spins up a microservice and they quit? What happens when a new dev wants to create a new service in the latest greatest language? What happens when you want to share a piece of business logic of some sort? What about creating canaries for all these services? What about artifact management/versioning?
What about when your microservice becomes monolithic?
Complexity is complexity no matter where it exists. Microservices are an exchange of one complexity for another. Building modular software is a reduction of complexity. A microservice that has business logic mixed with server logic is still going to suffer from being brittle.