4 ms·
It is definitely the first one. Microservices at AWS typically grow boundaries at team boundaries, even if it would make much more technical sense for them to b
by thrtythreeforty 3y ago
It is definitely the first one. Microservices at AWS typically grow boundaries at team boundaries, even if it would make much more technical sense for them to be combined. Each team knows which other team provides the APIs they need.
(Under the hood, the service may in fact be distributed to a large pool of resources. But a microservice doesn't shout into a void "hey could someone please handle a LaunchInstanceInRegion class??" - it's like using a library, but over the network.)
- twisteriffic 3y agoHow do they avoid cycles in calls to dependencies? Some golden rule of "thou shalt only call services that are less abstract than thyself?"
- ecshafer 3y agoIn my experience building these type of microservices, it just doesn't really happen often. Team A is responsible for customer data, Team B is responsible for inventory data, so you are usually don't have situations where A calls B and vice versa. The checkout service knows to call A and B.