Reassessing Granularity

Microservices are great… until they’re not. Years ago when I adopted 12 Factor as my way of life, never to be questioned, my only concern was high availability. Cost, development overhead, and network complexity were afterthoughts. Then, the real world set in. Working DevOps gave me a little more insight into how much kool-aid we had drank. Don’t get me wrong, microservices are a very good conceptual model. However, much like any idea taken to an extreme, you can cause more harm than good by not thinking about what excessive decomposition of services can cost you. What’s the most scarce resource to you? 1. Bandwidth? 2. Storage? 3. Compute power? How much effort is going into marshalling, throttling, message passing, and job queueing instead of solving the problem you set out to solve? Sometimes it’s strange watching tech trends cost people as much money as they do. Not paying attention to the details seems industry indemic. Recently, I’ve seen some really good microservice frameworks that solve these basic issues like Micro. Cool, so teams don’t need to waste so much development time building these pesky “non-functional requirements”. So now we can keep our Scrum Master happy. Life is great; all we had to do to implement good microservices was build a monolithic service platform that manages serialization, service discovery, queueing, and messaging, and we have our perfect solution… oh, wait. This is like the Torvalds vs Tanenbaum microkernel debate all over again. I think there’s a lesson to be learned here. Developers with pragmatism and a slight amount of diplomacy are a lot more valuable than super genius trendy hipster zealots.
Anyway I digress. Wouldn’t it be cool if there was some sort of monolithic web framework that had tons of optional libraries for different tasks, and maybe you could even run it headless as an API if you wanted to use it as a microservice. It would have to be battle tested for like, 14 years at least, and be based on a expressive flexible language that could handle OOP paradigms well. If only some people had the foresight to have created something like that.
Everything old is new again.