3 ms·
> And then, when you start growing, that's when you break out an independently scalable part of the system into a microservice (with it's own data store!). Was
by rewmie 3y ago
> And then, when you start growing, that's when you break out an independently scalable part of the system into a microservice (with it's own data store!).
Wasn't this the rule of thumb for microservices from the very start? That the main driving force is to ensure separate teams work independently on stand-alone projects they own exclusively? Scaling tends to only become an issue when the project grows considerably.
- jedberg 3y agoYes. But that idea got lost in the fray. Even I tried to build a system from scratch with microservices at one point.
- rewmie 3y ago> Yes. But that idea got lost in the fray. I don't think so. One of the very first things that people learn when onboarding into microservices is the microservices tax, whose corollary is don't onboard onto microservices if there isn't a clear significant win that justifies all the tradeoffs. Moreover, the main selling point of microservices is organizational. That's also right in the first lesson on microservices. If you're not working in a large team who owns a large project and wants to lower managerial overhead by splitting up the team, you need to try very hard to find a justification to peel off specific responsibilities from a service into an independent microservice. That's microservices 101. Those who jump onto the microservicss bandwagon without having a concrete justification have only themselves to blame, and not any particular architectural style. They are making the piss poor decisions and blaming abstract concepts for their own mistakes.