[choeger]

If I was CTO of a company, microservices would give me nightmares. How do you do due diligence on used free software (licenses and security updates)? How do you plan the resource usage of your whole setup if every developer can add a new autoscaling service? Who is actually keeping track on deployments so we don't accidentally overload the system? How do you refactor a cross-service feature consistently? And the worst part: Who keeps track of the n*n contracts between the services?

I mean yes, I know that each of these problems can be solved, sometimes in a relatively straightforward manner. But who really has all these aspects covered and doesn't run some services that started to smell weirdly a couple of months ago?

[clintonb]

> How do you do due diligence on used free software (licenses and security updates)?

Use the same process you would use if you had a monolith.

The rest of your issues can be solved by planning out your services, rather than giving everyone free reign to make a new service. Switching to services doesn't magically mean your teams stop talking and designing together.

[choeger]

Yeah and the inter-service specification lives where? How is it monitored, tested, enforced?

I have the feeling that with the (quite possible!) addition of an inter-service codebase we would end up with a distributed monolith, i.e., a program that doesn't target a single computer but a particular substrate. I don't know whether that's a good design, though.

Benefits: The program becomes more transparent and resilient to nonfunctional problems. It is also much easier to replace parts of the program. Downsides: Executing on a developer's workstation (critical for productivity and quality, IMO) might become harder. Efficiency gets reduced by orders of magnitude in certain spots.