4 ms·
10 people managing a single "micro service" does raise a red flag to me as well. It may be normal based on the complexity, but my first thought is, why is the c
by Clubber 9y ago
10 people managing a single "micro service" does raise a red flag to me as well. It may be normal based on the complexity, but my first thought is, why is the codebase require so many people to maintain and add features to? Are they just adding features like mad, or something squirrelly in there where most modifications take a lot of man hours?
- jblow 9y agoHow micro can it possibly be if it takes 10 people to deal with it? Seriously.
- BatFastard 9y agoCause it's not very micro?
- deleted 9y ago[deleted]
- sbov 9y agoThe scope of a microservice is commonly a bounded context in DDD. So depending upon the problem you might be talking about a lot of code.
- snowwrestler 9y agoIf "micro" refers to the scope of the service (i.e. very limited feature set), you might still need a team to run it, if the service has to handle a very high volume of transactions or provide very low latency, or both.
- sameline 9y agoIt’s not unreasonable to imagine that any of the examples provided in the source post could require a team larger than 10 people.
- bonesss 9y ago"Micro" in this case relates to the services scope, not its operational footprint. So if Netflix has a "User logon" service, and a "payment processing" service, used across their clients clients you might be looking at a couple of "microservice"s with hundreds of related employees. Imagine services for Googles search autocomplete, ML, or analytics... As the article states the "micro" aspect is mostly in terms of deployment responsibility, freeing those 10-1000 employees from thinking about the totality of Googles/Netflixes' operations before rolling out a patch :)
- deleted 9y ago[deleted]