Uber have well over 1,500 microservices written in Go, it is the primary language backend services are written in at Uber.
1500?! I can't even imagine how micro a microservice could be such that Uber could have so many.
edit: Having said that, the Monzo blog post also on the front page says it has 1100 microservices, so I suppose I've just not worked somewhere with 'actual' microservices. What constitutes a 'service', a single procedure for RPC?
- build a UNIX philosophy, "efficient atomicity" so 1 microservice = 1 command
- you then build logic with these like Lego bricks, that's your glue code => backend ties that together
On a typical base Linux install you have something between 250 and 1500 packages. Average Java repo has like, what, 80 files maybe? 120? Break it down to functions / structs and you can see the 1500 being a reasonable estimate of a modular architecture.
So you have one microservice to return a catalog, another to take a search input, another to serialize this stuff, another to autofill something, another to autofill some other thing, etc. Your app architecture schema is produced by/in microservices.
That's the extreme approach to microservice architecture (the 1 command / 1 object / 1 function / 1 struct atomicity Lego-style), and in such a case most microservices would typically look very much alike, with exactly the same "general" parts (auth, db connect, etc) and just your business logic varying in between.
With so small microservices, a team of 4 may be responsible for a good dozen microservices, a team of 10 may handle a hundred... You quickly rise to high hundreds in such scenarios.
Disclaimer: This is extensively parroted from the latest episode of "Go Time", a fantastic podcast imho.
In general it is easy to underestimate the complexity of systems you are not familiar with. The devil is in the details and deeper you look, more complicated it usually gets.
Very easy.
A key-value store is theoretically easy, “just store data and give it back”, but a distributed / highly reliable key value store is a crazy beast.
Collision detection and response seems like a “solved” problem but perk at the code and you’ll find just how many lines of code a basic game spends preventing players from waking through walls.
These services include all sorts of worker processes, things that manage queues or monitor things, probers, administration, public interface and configuration. It works really well for us.
Edit: eh, looks like I was not the only one who immediately thought of that :)