They also make sense if you have heavily uneven traffic, either time-wise, service-wise, or both. Being able to scale up/down individual components is the point
Nah, there have been some blogs recently from engineers who were bucking the Microservice trend - Notably Amazon Prime Video moved back to more of a monolith deployment and saw performance improvement and infrastructure cost reduction
I mean, Prime Video is still a bunch of microservices, it comes down to where you define the boundary between 'service and 'microservice'. That blogpost was specifically about "the Prime Video audio/video monitoring service". Eg it's a service/microservice for QA, not for all of Prime Video. I'm sure there are seperate services for billing, browsing, captioning, and streaming.
And although the author called it "moving from microservices to monolith" it's more about moving from serverless to more traditional compute.
The Prime Video example was more like moving from nano-service insanity to sanity. They basically split EVERY POSSIBLE STEP into separate lambdas. They switched to still using microservices, but they do all transcoding steps for a single video on the same microservice instance (aka sanity).
People make microservices way too small sometimes. Then you have the opposite problem with people trying to cram everything into one system. You need to recognize when some functions are related and should go together, or when something has a weird dependency and should just be separate.
Add comment