3 ms·

> We run about 1,100 microservices written in Go Asking as a university student: is this a common number of microservices to have running in production? It loo

by Shoop 7y ago

> We run about 1,100 microservices written in Go Asking as a university student: is this a common number of microservices to have running in production? It looks like monzo has about 1,351 total employees [0]. If all of them were software engineers, this would be a little less than one microservice per engineer. How do you handle code reuse and reliability among thousands of microservices? It seems like the number of possible failure states would be unthinkable. [0] https://en.wikipedia.org/wiki/Monzo_(bank) https://en.wikipedia.org/wiki/Monzo_(bank)

p10jkle 7y ago
I don't think its particularly common for a company of our size. They are mostly very small and handle very specific things. It's one approach, with some benefits, although it makes projects that affect all services quite tricky!
- Shoop 7y ago
  Does 1,100 microservices mean 1,100 distinct programs or 1,100 running instances of dozens or hundreds of distinct programs?
  - Spinosaurus 7y ago
    The former.
  - OJFord 7y ago
    I assume they're mostly RPC, and one procedure is one 'microservice'. There seems to be a bit of difference in what people mean by 'microservices' - some orgs will have a few REST collections per 'service' so you might end up with 'users', 'products', 'transactions' as your three services, and it being totally unimaginable that you'd ever break 1000. I'd argue that's still a Service-Oriented Architecture (SOA), but I'm sure it's not anywhere near as 'micro' as what Monzo counts over a thousand of.
    - p10jkle 7y ago
      Microservices generally have 0-10 RPC handlers (we use https://github.com/monzo/typhon https://github.com/monzo/typhon). We have a lot of different object types at Monzo, it goes way beyond 'transaction' or 'user' and each object type is going to be at least one service, but can be several. Services that mostly just consume off queues are often separated from services that handle requests so they can scale separately.
      - OJFord 7y ago
        Oh I wasn't suggesting user/product/transaction were what Monzo would use! (Should have made that clearer since 'transaction' is right domain...) Just the first things that came to my mind for very basic sort of service splitting that I'm familiar with. Thanks for replying, that does clear things up. My experience didn't really embrace RPC, so used gRPC for one small bit (< all of the service that contained it as I recall) but most was JSON HTTP APIs - the service boundaries pretty much just being team boundaries, though some (incl. mine) had a few services to the team.
  - kgthegreat 7y ago
    Distinct but small services each with 1-5 endpoints
dastx 7y ago
Just earlier today on another thread on HN I read Uber runs 1,500 micro services. I've yet to work for a company that runs over 100 micro services (or at least, that I'm aware of). But I can tell you having a tool like Kubernetes certainly makes a whole lot easier to maintain this many micro services. I think without a container orchestration it would be much harder to do so.
kgthegreat 7y ago
In web scale companies, it is not uncommon to have that many. (including the engineer:microservice ratio). Code re-use is generally handled by standardisation of services (including, language, libraries and frameworks). Reliability is taken care by metrics based measurements. It is truly a wonderful world. Of course, the path to el dorado lies in investing in world class platform and devops including painless CI/CD, Rollout/Rollback.

by Shoop 7y ago

p10jkle 7y ago

I don't think its particularly common for a company of our size. They are mostly very small and handle very specific things. It's one approach, with some benefits, although it makes projects that affect all services quite tricky!

Shoop 7y ago
Does 1,100 microservices mean 1,100 distinct programs or 1,100 running instances of dozens or hundreds of distinct programs?
- Spinosaurus 7y ago
  The former.
- OJFord 7y ago
  I assume they're mostly RPC, and one procedure is one 'microservice'. There seems to be a bit of difference in what people mean by 'microservices' - some orgs will have a few REST collections per 'service' so you might end up with 'users', 'products', 'transactions' as your three services, and it being totally unimaginable that you'd ever break 1000. I'd argue that's still a Service-Oriented Architecture (SOA), but I'm sure it's not anywhere near as 'micro' as what Monzo counts over a thousand of.
  - p10jkle 7y ago
    Microservices generally have 0-10 RPC handlers (we use https://github.com/monzo/typhon https://github.com/monzo/typhon). We have a lot of different object types at Monzo, it goes way beyond 'transaction' or 'user' and each object type is going to be at least one service, but can be several. Services that mostly just consume off queues are often separated from services that handle requests so they can scale separately.
    - OJFord 7y ago
      Oh I wasn't suggesting user/product/transaction were what Monzo would use! (Should have made that clearer since 'transaction' is right domain...) Just the first things that came to my mind for very basic sort of service splitting that I'm familiar with. Thanks for replying, that does clear things up. My experience didn't really embrace RPC, so used gRPC for one small bit (< all of the service that contained it as I recall) but most was JSON HTTP APIs - the service boundaries pretty much just being team boundaries, though some (incl. mine) had a few services to the team.
- kgthegreat 7y ago
  Distinct but small services each with 1-5 endpoints

dastx 7y ago

Just earlier today on another thread on HN I read Uber runs 1,500 micro services. I've yet to work for a company that runs over 100 micro services (or at least, that I'm aware of). But I can tell you having a tool like Kubernetes certainly makes a whole lot easier to maintain this many micro services. I think without a container orchestration it would be much harder to do so.

kgthegreat 7y ago

In web scale companies, it is not uncommon to have that many. (including the engineer:microservice ratio). Code re-use is generally handled by standardisation of services (including, language, libraries and frameworks). Reliability is taken care by metrics based measurements. It is truly a wonderful world. Of course, the path to el dorado lies in investing in world class platform and devops including painless CI/CD, Rollout/Rollback.