4 ms·

Uber have well over 1,500 microservices written in Go, it is the primary language backend services are written in at Uber.

OJFord 7y ago
> Uber have well over 1,500 microservices written in Go 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?
- pjmlp 7y ago
  I guess they suffer from "leftpad as service". http://left-pad.io/ http://left-pad.io/
- sidlls 7y ago
  The target is one microservice per syscall, maybe.
  - deleted 7y ago
    [deleted]
- badrequest 7y ago
  I don't work at Uber, so I can't answer your questions around motivation, but I took the 1,500 value from this presentation at Gophercon this year: https://www.youtube.com/watch?v=nLskCRJOdxM&t=22m59s https://www.youtube.com/watch?v=nLskCRJOdxM&t=22m59s
- jpalomaki 7y ago
  I would imagine quite a services to just deal with legislation/taxation stuff in all the different markets they operate in. These can also result on several integrations to government systems - all country specific. In some markets they are partnering with taxi companies - maybe more integrations for ordering and reporting. 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.
  - klodolph 7y ago
    > In general it is easy to underestimate the complexity of systems you are not familiar with. 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.
- deleted 7y ago
  [deleted]
- K0SM0S 7y ago
  I haven't worked with microservices directly but what I gather is: - 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.
  - weberc2 7y ago
    This seems really excessive. You'd have to have really good tooling to build, deploy, and debug (since log streams are oriented per-function, not per-request), and I'm not sure how that could be performant, especially if you're making O(N) (or worse) network calls per request. My understanding is that microservices are typically 1-5 per team.
- klodolph 7y ago
  My team has on the order of 20 microservices? 50 teams of that size would add up to 1,000. 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.
- joeblau 7y ago
  When I joined Amazon in 2014, there were ~120,000 microservices. A lot of them arne't used or just hello world tests apps. Every new employee had to spin one up during orientation.
- takeda 7y ago
  The must have a leftPad microservice. Edit: eh, looks like I was not the only one who immediately thought of that :)
pearjuice 7y ago
1500 microservices? Are they exposing each function as a microservice or something? At which point could be having 1500 microservices a good thing? I honestly cannot think of one unless you have some massive design flaw or have a different definition for microservice.
- badrequest 7y ago
  I don't work at Uber, so I can't answer your questions around motivation, but I took the 1,500 value from this presentation at Gophercon this year: https://www.youtube.com/watch?v=nLskCRJOdxM&t=22m59s https://www.youtube.com/watch?v=nLskCRJOdxM&t=22m59s

OJFord 7y ago

> Uber have well over 1,500 microservices written in Go 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?

pjmlp 7y ago
I guess they suffer from "leftpad as service". http://left-pad.io/ http://left-pad.io/
sidlls 7y ago
The target is one microservice per syscall, maybe.
- deleted 7y ago
  [deleted]
badrequest 7y ago
I don't work at Uber, so I can't answer your questions around motivation, but I took the 1,500 value from this presentation at Gophercon this year: https://www.youtube.com/watch?v=nLskCRJOdxM&t=22m59s https://www.youtube.com/watch?v=nLskCRJOdxM&t=22m59s
jpalomaki 7y ago
I would imagine quite a services to just deal with legislation/taxation stuff in all the different markets they operate in. These can also result on several integrations to government systems - all country specific. In some markets they are partnering with taxi companies - maybe more integrations for ordering and reporting. 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.
- klodolph 7y ago
  > In general it is easy to underestimate the complexity of systems you are not familiar with. 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.
deleted 7y ago
[deleted]
K0SM0S 7y ago
I haven't worked with microservices directly but what I gather is: - 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.
- weberc2 7y ago
  This seems really excessive. You'd have to have really good tooling to build, deploy, and debug (since log streams are oriented per-function, not per-request), and I'm not sure how that could be performant, especially if you're making O(N) (or worse) network calls per request. My understanding is that microservices are typically 1-5 per team.
klodolph 7y ago
My team has on the order of 20 microservices? 50 teams of that size would add up to 1,000. 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.
joeblau 7y ago
When I joined Amazon in 2014, there were ~120,000 microservices. A lot of them arne't used or just hello world tests apps. Every new employee had to spin one up during orientation.
takeda 7y ago
The must have a leftPad microservice. Edit: eh, looks like I was not the only one who immediately thought of that :)

pearjuice 7y ago

1500 microservices? Are they exposing each function as a microservice or something? At which point could be having 1500 microservices a good thing? I honestly cannot think of one unless you have some massive design flaw or have a different definition for microservice.

badrequest 7y ago
I don't work at Uber, so I can't answer your questions around motivation, but I took the 1,500 value from this presentation at Gophercon this year: https://www.youtube.com/watch?v=nLskCRJOdxM&t=22m59s https://www.youtube.com/watch?v=nLskCRJOdxM&t=22m59s