3 ms·
I prefer working on monoliths as opposed to microservices. Microservices (2-pizza team model microservices, or microservices uses for this one little thing) are
by ecshafer 3y ago
I prefer working on monoliths as opposed to microservices. Microservices (2-pizza team model microservices, or microservices uses for this one little thing) are a reaction to be development practices. Many companies have a monolith which requires a dedicated team doing builds and deploys because its built on decades of bad practice and bolted on scripts deploying to bespoke servers; the company then build a new cicd pipeline and makes microservices that use the pipeline to deploy into a cloud with a vm, then they are shocked at how much better the experience is. But the improvement is from better infra and cicd, not moving monolith to microservices.
The sweet spot is IMO: Monolith until the monolith becomes truly unwieldy, then break off core pieces of functionality into other services. So 1 monolith -> 4 "microservices". The 100s of microservices is a mistake.
- tail_exchange 3y agoWhat do you consider tryly unwielding, and what happens when the 4 microservices become that? Do they all break up into 16 microservices? In a few more iterations you'll have over 100 microservices running, so it seems inevitable for a large organization.
- ecshafer 3y agoI think many teams should manage a single service, which really drastically lowers on call support burden. Unwieldy is a single team (10 or fewer people) supporting a service by themselves, or more than one service by themselves. If at the point you have 16 microservices, that means you should have 16 very distinct areas of technology and business. The monolith to 4 services was an example, and I think you should really be careful each time you carve out any area of business, and the better focus is on focusing on how to scale the monolith further.