[wpietri]

One of the questions I like asking developer pals is what ratio their company has between engineers and services/deployable units. Anybody reading this care to share?

For me, that number says a lot more about the day-to-day life of devs than the microservices vs monolith label does.

[jedberg]

I don't remember the hard numbers, but on average each service at Netflix was maintained by about 4 people but there were outliers in both directions. Sometimes there were four or five services maintained by one person, and sometimes there was one service backed by a team of 25+.

The other important number was that about 25% of engineering was dedicated to building the tools to manage the microservices. We didn't work on customer facing software -- the other engineers were our customers. And I found that number to be pretty consistent amongst any company that was fully invested into microservices.

[hackerfromthefu]

For anyone with a monolith considering microservices, that 25% of total is 33% more work than the monolith.

But if 33% more work isn't enough, we can things in languages with undefined behaviour like Javascript, and also use lots of different languages in the services so out support gets more complex!

Jokes aside, the saving grace is t25% sounds like empirical observation so it probably an all up figure so probably includes the large amounts of bikeshedding that often accompanies a microservices implementation.

[lelandbatey]

Where I currently work, there are 10 services per developer, actively running (if we're counting in the least charitable manner, maybe 4 per dev with most charitable counting). Our ratio is this huge due to large changes in company size over time. Consolidation is very helpful at this stage. If there's one thing I recommend to everyone who encounters this situation, you absolutely must keep a copy of all the source for all the repos on your computer, all at the same time, to make cross-repo grepping easy. For this purpose I recommend ghorg[0], but however you do it, it'll make everything easier.

[0] - https://github.com/gabrie30/ghorg

[bluehatbrit]

At my last place, a team of about 4 would usually handle maybe 2 services, possibly a 3rd if it was some kind of light weight shim. Larger teams towards about 8 might have 4-5 components. There were some outliers as ever in an org with 100's of engineers, typically teams who had more components struggled to deliver their roadmaps. They'd also often end up with huge blocks of work when a bit of technical debt cropped up as it was complicated by having more services.

We eventually got to the point where we started re-definining everything in terms of "business processes" (ie: creating a basket, paying for an order, making a complaint, etc). Teams were moving towards talking about processes rather than services, how we chose to organise the code and deploy it was starting to become more about practicalities. Such as: this collection of endpoints services an internal tool and scales differently to this other collection which service customer facing clients.

I left not long ago but my team of around 7 engineers had 2 primary service where 90% of the work happened. The other 10% of the work was on a few edge services, typically small serverless functions, which were mostly set and forget. It felt like we could move at a good pace with this setup. My new job is even more monolithic leaning and it's even faster to get work done and build internal tools.

[edude03]

We are currently between 3-7 services per dev depending on how you count (~40 services developed in house, ~70 if you include third party micro services we run)

It would likely be insurmountable if not for using kubernetes, we choice the idiomatic options (gke/GitHub actions/Argo/Prometheus/etc) so starting with micro services wasn’t too bad

[WatchDog]

Wow, that sounds like an utter nightmare.

[edude03]

I can imagine why you think that, but actually it works really well. I could write a blog post about it if there is some interest.

[wpietri]

I'm definitely interested!

[stephenboyd]

My team of 5 has 5 services. 3 of those are tiny function-as-a-service APIs. 2 of those are Azure App Services, where our involvement in the infrastructure is minimal. And we're about to add a 3rd one of those. That sounds like a lot but we wanted the flexibility of making those capabilities independently updatable and deployable. And only one of those has an API used by other teams, so as far as the rest of the company is concerned it's like we have only one service.

At one point we had twice as many teams and almost twice as many services. The team had grown too large for optimal performance. When it was time to divide the team, we were able to categorize our services in two ways by the path of the data (deep back-end data processing for internal customers vs product services). Then we were able to assign a category to each team so that we have minimal dependencies and no code conflicts between teams.

[karmakaze]

2 Pizza-sized per service is the rule of thumb. I'm happy with even somewhat less, as long as the scope narrows accordingly and there's CI/CD/infrastructure support experience deploying many services.