The weird thing about the discussions on this topic is that we are talking about a narrow service in the first place. We aren't talking about all of Prime Video. I'm sure they still have plenty of services (micro or otherwise) for website, for billing, for transcoding video files, and for this use case: product analytics.
The entire article is just about their analytics system. And it make sense, that probably should have been, with the benefit of hindsight, a monolith to begin with. But that doesn't really tell you anything about the design of the overall system.
My personal take is that the DDD book had it right. Designs Services around distinct domains, that have independent problem domains, teams operating and clear interfaces and state seperation.
I think when it comes to groups like Amazon- the narrow services are themselves very complicated. It is not unreasonable to expect that Amazon Prime analytics interacts with servers in Amazon store etc. This interconnectedness is what drives recommendations but also probably really muddies the situation. That might be why they opted for microservices.
I haven't read the book. Will check it out. Thank you for that.
Sure. I guess my point is when you look at the system from the perspective of Amazon Video - then you could consider their analytics a "microservice" you could consider billing/store integration a microservice, etc ...
So the question isn't really microservices or not. The question is what are the right boundaries for any given set of microservice/services in a system? Should you have 5 or 12 or whatever? Under what basis should you be analyzing the architecture to identify the design?
Larger companies often implement services more for reason of Conway's law and team coordination issues rather than anything technical as such. The communication overheard of managing delivery of monolithic services in larger organizations is really high.
Another concern is coupling of the systems ... if your change will necessarily span many distinct services and then you need a coordinated rollout of all the services to deliver your change ... then that overhead is too high.
So the optimal size is something like: an independent team can deliver a user-story, value-delivering feature, most of the time by only making changes their service/s with limited coordination required with other teams.
The DDD book provides some other thoughts, focused on the "language" or problem domain. So if you are working on the billing system, an Account object might refer to something like a checking account, or the ledger records for a vendor. But on the customer facing side, the Account might be the tenant for the end-paying customer. Something these things might be the same, somethings they are different (like a customer have many tenants for different divisions, but only one billing relationships). From a data-model or object-oriented perspective, and from cognitive-load perspective separating these system with distinct boundaries are interfaces provides a good architecture.
Then you have the performance and operational concerns, do you need knobs to independently scale different subsystems due to varying load characteristics and so a network boundary make sense.
But short of any of these type of concerns, you would want to minimize networking overheard, using different data-stores, using different programming languages/frameworks, different running processes, etc ...
The weird thing about the discussions on this topic is that we are talking about a narrow service in the first place. We aren't talking about all of Prime Video. I'm sure they still have plenty of services (micro or otherwise) for website, for billing, for transcoding video files, and for this use case: product analytics.
The entire article is just about their analytics system. And it make sense, that probably should have been, with the benefit of hindsight, a monolith to begin with. But that doesn't really tell you anything about the design of the overall system.
My personal take is that the DDD book had it right. Designs Services around distinct domains, that have independent problem domains, teams operating and clear interfaces and state seperation.
I think when it comes to groups like Amazon- the narrow services are themselves very complicated. It is not unreasonable to expect that Amazon Prime analytics interacts with servers in Amazon store etc. This interconnectedness is what drives recommendations but also probably really muddies the situation. That might be why they opted for microservices.
I haven't read the book. Will check it out. Thank you for that.
Sure. I guess my point is when you look at the system from the perspective of Amazon Video - then you could consider their analytics a "microservice" you could consider billing/store integration a microservice, etc ...
So the question isn't really microservices or not. The question is what are the right boundaries for any given set of microservice/services in a system? Should you have 5 or 12 or whatever? Under what basis should you be analyzing the architecture to identify the design?
Larger companies often implement services more for reason of Conway's law and team coordination issues rather than anything technical as such. The communication overheard of managing delivery of monolithic services in larger organizations is really high.
Another concern is coupling of the systems ... if your change will necessarily span many distinct services and then you need a coordinated rollout of all the services to deliver your change ... then that overhead is too high.
So the optimal size is something like: an independent team can deliver a user-story, value-delivering feature, most of the time by only making changes their service/s with limited coordination required with other teams.
The DDD book provides some other thoughts, focused on the "language" or problem domain. So if you are working on the billing system, an Account object might refer to something like a checking account, or the ledger records for a vendor. But on the customer facing side, the Account might be the tenant for the end-paying customer. Something these things might be the same, somethings they are different (like a customer have many tenants for different divisions, but only one billing relationships). From a data-model or object-oriented perspective, and from cognitive-load perspective separating these system with distinct boundaries are interfaces provides a good architecture.
Then you have the performance and operational concerns, do you need knobs to independently scale different subsystems due to varying load characteristics and so a network boundary make sense.
But short of any of these type of concerns, you would want to minimize networking overheard, using different data-stores, using different programming languages/frameworks, different running processes, etc ...
Skip this post and just read what Amazon said.
:(