The complexity is still there even with microservices or a Go or a Clojure codebase, it's just that either you've created a mess or you've created your own fram

The complexity is still there even with microservices or a Go or a Clojure codebase, it's just that either you've created a mess or you've created your own framework. In my experience, you either use one of these big frameworks, or you end up building one. I've seen that happen more than once, and these "home made frameworks" are far worse, less documented, more buggy and have like 6 different patterns depending which generation of developers before me built it (and of course, I had left own opinions and mistakes too). Writing microservices in Go or Flask or Sinatra won't make all the complexity related to the Web go away magically. The're still there. Now they're distributed across services and implemented mostly from scratch. If you are not FAANG and don't use one of these big frameworks, you have only two options: 1. Create a distributed spaghetti mess of random libraries tied together 2. Build your own "big framework". I've been many times in companies which were through the process of breaking up the monolith into separate services. It never finished, and every single service was just a proxy to the monolith, and everything took twice the time to implement, and now both all the services and the monolith have to be kept running and maintained. The only "positive" was the group of devs that wanted to play with new tech and somehow managed to become a team that only works on one of those services, so now they're "free" from the monolith hell. Business wise it was a disaster, would have been better to just let those engineers find another job with the tech stack they preferred and hire new ones willing to work on a single codebase and keep things simple. Again, this was not a Google scale company, these were 50 ~ 100 engineers organizations.