[jedberg]

> We have approximately 12 developers spread across 2 feature teams and a support team.

If I were consulting for this company, I would have told them to stop right there, microservices are probably not for them. Unless you build from the start for microservices on something like AWS lambda, doing with such a small team would be really hard.

And as they eventually discovered, a lot of unnecessary overhead for such a small team.

[jeremyjh]

Yeah, honestly this should be the entire content of the article. Not only do they only have two small teams but they all overlap completely anyway. There is no reason even a significantly larger org - say 40+ people in 8-10 teams cannot work effectively in a single repository and monolith architecture. Beyond that there are certain growing pains and if you don't effectively manage those then I could see how you end up going with micro-services.

Beyond scaling a large development org the primary benefits of micro-services accrue to consultants who bill by the hour.

[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.

[jayd16]

I don't know if I agree. Deploying servers and calling out to services should be a core competency. I don't think it's as drastic as you make it out to be.

No ownership is a bigger problem than team size imo.

That said, no reason to do it just because it's trendy.

[terrorobe]

> calling out to services should be a core competency.

What’s the typical failure rate of a method call within a process of a language of your choice?

If it’s not Java2k it will be one or two orders of magnitude lower than any cross-process, host or provider RPC call you’re ever going to make.

At smaller scales, just not having to deal with all the bugs and cleanup work missed error handling brings - and then building proper error handling for all relevant cases - can make a huge difference.

[karmakaze]

I came looking for this in the comments. Invalidates the rest of the post, really.

[Twisol]

The post is very explicitly coming from a perspective of "we didn't know what we were getting ourselves into". The story begins after the decision to move to microservices was made, and the backstory of the decision isn't dwelt on (beyond allusions to top-down pressure from management).

The important lessons here are on how they recognized the mistake before they had fully committed. Having worked on a team with a similar story, it all rings very true.

[karmakaze]

I can certainly see how this happens. Points to how poorly all the chatter about microservices obscures important points. This post itself doesn't strongly enough highlight that 12 developers is a full-stop no microservices decision point.

Or to phrase it differently, it's like a horror film where a small/skinny person goes into a dark unknown basement by themselves. Sure there's a story to be had, but the important bits to know come before the decision. I suppose it could be useful how to best defend oneself in a rare situation but avoiding it altogether is better if easy to learn.