News for hackers. Stuff that matters.
Re:Amazon Prime Video’s Microservices Move Doesn’t Lead to a... by ecshafer on Monday July 10, 2023 @10:39AM (#36667137)
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.

Re:Amazon Prime Video’s Microservices Move Doesn’t Lead to a... by tail_exchange on Monday July 10, 2023 @11:39AM (#36667999)
What happens when the 4 microservices become truly unwielding? Do they all break up into 16 microservices? In two more iterations you'll have over 100 microservices running, so it seems inevitable for a large organization.
Re:Amazon Prime Video’s Microservices Move Doesn’t Lead to a... by ecshafer on Monday July 10, 2023 @12:40PM (#36668897)
I 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.