Most apps should not start as a monolith. However the first time a senior engineer is attempting to grok microservice design patterns, definitely they should go that route of decomposing monolith into microservices. Training wheels aren't needed forever unless they're doing a poor job implementing those patterns, training/selling their teammates on it, or failing to convince their bosses on the efficacy of microservice architecture.
If that's the case, monolith away: let the team balloon around that beast, increase the cost of technical debt, increase the ramp-up time for new engineers, slow down & formalize those release cycles & code freezes, and let's party like it's 2011!!
Most apps should not start as a monolith. However the first time a senior engineer is attempting to grok microservice design patterns, definitely they should go that route of decomposing monolith into microservices. Training wheels aren't needed forever unless they're doing a poor job implementing those patterns, training/selling their teammates on it, or failing to convince their bosses on the efficacy of microservice architecture.
If that's the case, monolith away: let the team balloon around that beast, increase the cost of technical debt, increase the ramp-up time for new engineers, slow down & formalize those release cycles & code freezes, and let's party like it's 2011!!
Microservices is a pattern to solving a particular problem. It's not the hammer for every nail.