I downvoted because without context this just seems like the typical know-it-all statement from someone who has yet to realize how little they really know. There's no attempt to even try to appreciate how their situation may be different, just the default disdain so typical from some professionals incapable of thinking outside of their own perspective.
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?
"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 :)
If "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.
I think he is literally asking for the other perspective? "I run 8 services myself" can be read as arrogant, OR it can be read as "I do things very differently", which is how I read it initially.
That’s how I meant it, that the advantage of microservices is bite size pieces of work, so 10 people on the same service sounds like they’d step on each other’s toes. I run a bunch of services but they’re each debugged enough to be fairly low maintenance and small enough that the edges are well defined.
It’s 8 or so but it’s possible for me to handle it all. If we add features they’re going to be new services, so adding big features to the services I manage is unlikely. It is more likely that I get a new service on my plate in 6 months time than getting additional members of the engineering team to work on already completed services.
I’m obviously not entirely alone... I’ll ask for help if I need it, and I help out with other people’s stuff too, but I am primarily in charge of them and I am responsible for keeping everything working well.
It's not the number of people that are micro, it's the scope of the service... So what is the right level of manpower for a scoped service with unspecified operational demands? Unknowable.
The definition isn't small teams, per se, it's a small area of responsibility with singular focus. A lego block instead of duplo. That lends itself very well to small teams, but you could reasonably have 100 people working on a service and call it "micro".
Reason being: if those 100 people weren't working on their scoped 'microservice' they would be part of a much, much, much larger pool working on the shared 'product', 'platform', or 'service' that contains that exact same functionality, only without the clarity/scalability of application boundaries surrounding the individual service components.
That's not to say microservices are ideal, just that the size of "micro" is highly relative to ongoing operations.
I suppose it depends if those 10 people are purely developers or include the other teams you'd need - monitoring, devops, etc. For a critical, high-performance microservice, I can easily see it needing the involvement of 2+ devs (at least one senior), product owner, project manager, QA, devops, monitoring, etc.
