Hacker News Reader

Comment by GrumpyNl | Hacker News Reader

Cant find how many developers they have to maintain this monster.

An article[1] from 2018 mentions 70 engineers. Let's assume 50% growth yoy which puts them at 157 engineers now. Making another assumption that only 20% of these engineers are productive which gives us 31 engineers. That's 1600 microservices for 31 engineers.

That sounds large but if you have 1600 microservices you are _most likely_ writing a single service where you'd normally write a class. Does 50 classes per engineer sound like a lot? Sure does but they didn't create this infrastructure out of thin air - this is an accumulation of many years. For sake of the arguments let's say 2 years. Across 24 months that's only 2 microservices per developer per month.

Not unthinkable, and this is assuming only 20% of their engineering force is actually productive.

[1]https://monzo.com/blog/2018/06/27/engineering-management-at-...

I think a lot of people are extrapolating from their experience with monoliths and imagining that Monzo devs are maintaining 1600 tiny monoliths. That's an anxiety-inducing thought.

I would prefer maintaining a "tiny monolith" over a micro service. At least with the monolith you're writing value-delivering business-logic code. From my experience with micro services you spend more time on boilerplate and the whole HTTP/RPC part and the communication with other services than the actual task the service is supposed to be doing.

Or, maybe you are spending a bunch of time making sure you don't break a rats' nest of dependencies and waiting for things to build.

After the n^th iteration of building an rpc server, such things may be fairly standardised, no?

Reply on news.ycombinator.com