Last time I did a survey of my peers, companies that were all in on microservices in the cloud spent about 25% of their engineering time on the support systems

Last time I did a survey of my peers, companies that were all in on microservices in the cloud spent about 25% of their engineering time on the support systems for microservices. That number is probably a bit lower now since there are some pretty good tools to handle a lot of the basics. And the author sums up the advice I've been giving for a long time perfectly: > Splitting an application into services adds a lot of complexity to the overall system. Because of that, it’s generally best to start with a monolith and split it up only when there is a good reason to do so. And usually that good reason is that you need to optimize a particular part of the system (which often manifests as using another language) or your organization has grown such that the overhead of microservices is cheaper than the management overhead. But some of the things in this article are not quite right. > Nothing forbids the use of different languages, libraries, and datastores for each microservice - but doing so transforms the application into an unmaintainable mess. You build a sidecar in a specific language, and any library you produce for others to consume is for that language/sidecar. Then you can write your service in any language you want. Chances are it will be one of a few languages anyway that have a preferred onramp (as mentioned in the article), and if it's not, then there is probably a good reason another language was chosen, assuming you have strong technical leadership. > Unlike with a monolith, it’s much more expensive to staff each team responsible for a service with its own operations team. As a result, the team that develops a service is typically also on-call for it. This creates friction between development work and operational toll as the team needs to decide what to prioritize during each sprint. A well run platform removes most of the ops responsibility from the team. The only thing they really have to worry about is if they have built their system in a way to handle failures well (chaos engineering to the rescue!) and if they have any runaway algorithms. Otherwise it's a good thing that they take on that ops load, because it helps them prioritize fixing things that break a lot.