> This is pure survivor bias. The majority -- by far -- of 'failure stories' I know of in the software industry are ones in which a company tried to take their monolithic code base and modularize or microservice-ize it.
In my experience, this happens when a dev team has built a product but customers aren't flowing in. If they had customers, they wouldn't have time to fiddle with their architecture unless it was a growth-limiting problem. But the real problem ultimately is customer acquisition, not that they had to rearchitect the app.
> This is not because microservices-first is inherently flawed. This is purely a skill set issue. Microservices demand a greater skill set. A 'monolithic' approach puts much less of a demand on the engineer's skill set.
I disagree. I don't think "microservices-first" is inherently flawed, I think it's just really hard to know how you need to break apart your services in a way that seems logical to customers. It's less about good/bad architectural design skills (though I agree, that is a problem) and more about engineers being really awful at predicting demand.
But microservices are not a panacea that fixes everything on their own. You have to think about the entire deployment stack, from the hardware up. This means things like VM orchestration, network/load balancers/firewalls, configuration management, etc. that you don't have to worry about as much or as often with a monolithic application. Microservices optimize flexibility because they can be deployed in the widest variety of ways, but they do induce management overhead that is unnecessary in a lot of cases.
Besides, splitting out an app to a microservice architecture usually isn't that hard. I've architected this 3 or 4 times in the last year alone -- you use a proxy to break the traffic off to a different deployment endpoint and split the code up later. This assumes your monolithic app is stateless and using a separate persistence layer, but that's just basic software design.
In my experience, this happens when a dev team has built a product but customers aren't flowing in. If they had customers, they wouldn't have time to fiddle with their architecture unless it was a growth-limiting problem. But the real problem ultimately is customer acquisition, not that they had to rearchitect the app.
> This is not because microservices-first is inherently flawed. This is purely a skill set issue. Microservices demand a greater skill set. A 'monolithic' approach puts much less of a demand on the engineer's skill set.
I disagree. I don't think "microservices-first" is inherently flawed, I think it's just really hard to know how you need to break apart your services in a way that seems logical to customers. It's less about good/bad architectural design skills (though I agree, that is a problem) and more about engineers being really awful at predicting demand.
But microservices are not a panacea that fixes everything on their own. You have to think about the entire deployment stack, from the hardware up. This means things like VM orchestration, network/load balancers/firewalls, configuration management, etc. that you don't have to worry about as much or as often with a monolithic application. Microservices optimize flexibility because they can be deployed in the widest variety of ways, but they do induce management overhead that is unnecessary in a lot of cases.
Besides, splitting out an app to a microservice architecture usually isn't that hard. I've architected this 3 or 4 times in the last year alone -- you use a proxy to break the traffic off to a different deployment endpoint and split the code up later. This assumes your monolithic app is stateless and using a separate persistence layer, but that's just basic software design.