In any discussion or critique of microservices, some people very clearly have never worked on monoliths (or haven’t worked at enough companies to see the bad ones) and it shows. A poorly designed monolithic codebase is just as bad as a poorly designed microservice one. The problem isn’t the ideology.
I began my career in the times when monoliths were king but virtualization was just around the corner. For sufficiently complex software systems, monoliths were such a nightmare. Merging new code into a monolith is like trying to merge lanes in a 16 wheeler. You’re not merging until everyone is out of the way or you accidentally knock other people off the road. Testing took forever because who knows how many places one code change affected, or how many teams have collectively merged conflicting code changes one after the other. Heaven forbid trying to snapshot the database. Or backing it up. The codebase was often so large that regression testing and deployments took 6 - 8 hours, which had to be done overnight because you can’t have the software go down during business hours. None of that is fixed decades later. It has the same problems. In fact the problems are worse in the modern age of reliability engineering. Nothing can ever go down.
For single purpose apps like Instagram, I would be surprised if a monolithic structure was big enough to fail. It makes sense for smaller designs. For larger stuff, with multiple data sets and purposes like Amazon, it doesn’t make sense at all. Every company expects to grow as big as the top dogs, and so they do microservice architecture from the start to prevent the headaches of future migration work. But if they never get there it’s just service bloat.
This whole architectural war is idiotic. Do what makes sense.
In any discussion or critique of microservices, some people very clearly have never worked on monoliths (or haven’t worked at enough companies to see the bad ones) and it shows. A poorly designed monolithic codebase is just as bad as a poorly designed microservice one. The problem isn’t the ideology.
I began my career in the times when monoliths were king but virtualization was just around the corner. For sufficiently complex software systems, monoliths were such a nightmare. Merging new code into a monolith is like trying to merge lanes in a 16 wheeler. You’re not merging until everyone is out of the way or you accidentally knock other people off the road. Testing took forever because who knows how many places one code change affected, or how many teams have collectively merged conflicting code changes one after the other. Heaven forbid trying to snapshot the database. Or backing it up. The codebase was often so large that regression testing and deployments took 6 - 8 hours, which had to be done overnight because you can’t have the software go down during business hours. None of that is fixed decades later. It has the same problems. In fact the problems are worse in the modern age of reliability engineering. Nothing can ever go down.
For single purpose apps like Instagram, I would be surprised if a monolithic structure was big enough to fail. It makes sense for smaller designs. For larger stuff, with multiple data sets and purposes like Amazon, it doesn’t make sense at all. Every company expects to grow as big as the top dogs, and so they do microservice architecture from the start to prevent the headaches of future migration work. But if they never get there it’s just service bloat.
This whole architectural war is idiotic. Do what makes sense.