3 ms·

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

• lofties 7y ago
  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-monzo https://monzo.com/blog/2018/06/27/engineering-management-at-...
  • okal 7y ago
    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.
    • Nextgrid 7y ago
      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.
      • conjectures 7y ago
        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?