4 ms·

> A recent blog post by neobank Monzo explains that they have reached the crazy amount of 1500 microservices (a ratio of ~10 microservices per engineer) That’s

> A recent blog post by neobank Monzo explains that they have reached the crazy amount of 1500 microservices (a ratio of ~10 microservices per engineer) That’s wild. Microservices are mostly beneficial organizationally — a small team can own a service and be able to communicate with the services of other small teams. If anything I think a 10:1 software engineers:services is probably not far off from the ideal.

snowoutside 6y ago
I think 10:1 is a bit much. If services are well-scoped, 3 engineers/service can be an effective ratio.
djsumdog 6y ago
At a goto; talk, an Uber engineer said they had so many microservices it was impossible to really count how many they had: https://www.youtube.com/watch?v=kb-m2fasdDY https://www.youtube.com/watch?v=kb-m2fasdDY
- hrpnk 6y ago
  That really depends how you count them and how you manage the entire application landscape. For audit, compliance, security, and risk management purposes you really need to know what the service is doing and what criticality level it is. Surely, you can make the creation of services really easy - so easy that it's not even viable to define meaningful business names for the services, thus creating an unmaintainable mess. But still, having an application registry or automation that crawls the cloud resources for services can be done afterwards without significantly impacting the speed of creating new services.
michaelbuckbee 6y ago
When I hear things like that all I can think is that I have a wildly different idea of what a "service" is that it can be broken down to such a small chunk of functionality. Are there examples of the size of these individual services? What are they doing?
- spc476 6y ago
  At work, we have: * two services that accept requests via telephony protocols (SS7, SIP, these are quite small) and forwards the request to: * the business logic component (large only because of the complexity of the business logic implemented). When there's some state changes, it sends a request to: * the replication module (say, midsized), which ensures that the state change is replicated at The Other Site to handle geographical redundancy (a requirement from our customer). * There's one other microservice that the business logic uses and that's to send some data to Apple so they can hand it off to iOS phones (all our stuff internally uses UDP (except for the SS7 stuff)---the addition of a TLS based service was too much to add to the business logic component and this is quite small as well). All of these modules are owned by the team I'm on, namely due to the esoteric nature of it (the telephony protocols, this is real time since it's part of the call path [1], etc.). Within our team, we can work on any component, but generally speaking, we tend to specialize on a few components (I work with the telephony interfaces and the Apple interface; my fellow office mate deals with the business logic). [1] As a cell phone call is being made.
  - michaelbuckbee 6y ago
    Thanks for replying, I'm so used to thinking of just CRUD apps or fairly small sized projects, this was really helpful.
axlee 6y ago
> That’s wild. Microservices are mostly beneficial organizationally — a small team can own a service and be able to communicate with the services of other small teams. And a cross-concern fix that a dev used to be able to apply by himself in a day, now has to go through 5 teams, 5 programming languages, 5 kanban boards and 5 QA runs to reach production. I never understood the appeal of teams "owning" services. In my dream world, every engineer can and should be allowed to intervene in as many layers/slices of the code as his mental capacity and understanding allows. Artificial - and sometimes bureaucratic - boundaries are hurtful. To me, it's the result of mid-to-senior software engineers not being ready to let go of their little turfs as the company grows, so they build an organizational wall around their code and call it a service. It has nothing to do with computer science or good engineering. It is pure Conway's law.
- hrpnk 6y ago
  In my experience, ownership of services is usually defined to ensure that in the engineering organization it's clear who will react as the first responder when there are security patches, production incidents to deal with and also when there are questions about the service's inner workings. It's especially required when the documentation of the services is sparse which is likely to happen when the change rate in the team is high. In more mature engineering organizations, you would define a set of maintainers for the service, who will define the contribution mechanisms and guidelines, so that anyone can make changes to the code. This is further enabled by common patterns and service structures, especially when there is a template to follow. Strict assumed "ownership" creates anti-patterns where each team will define their favourite tech stack or set of libraries making it difficult for others to contribute and decreasing the possible leverage effects in the team.
  - axlee 6y ago
    Maybe it is simply a terminology issue, but what you describe, I would call it responsibility rather than ownership. Ownership implies strong exclusivity. Agree with your post otherwise.
    - 6y ago
twic 6y ago
If you have ten people working full-time on it, it is not a microservice, it is just a service. I think the discussion about microservices has suffered more than anyone realises from a lack of shared understanding about what a microservice actually is.
- pojzon 6y ago
  What in case when that „service” is actually a thousend of „microservice instances” thats communicating with other „services” via some „api gateways”? And the teams managing those „services” do full DevSecOps? 10 people working on such component is actually pretty decent team size for that task...

snowoutside 6y ago

I think 10:1 is a bit much. If services are well-scoped, 3 engineers/service can be an effective ratio.

djsumdog 6y ago

At a goto; talk, an Uber engineer said they had so many microservices it was impossible to really count how many they had: https://www.youtube.com/watch?v=kb-m2fasdDY https://www.youtube.com/watch?v=kb-m2fasdDY

hrpnk 6y ago
That really depends how you count them and how you manage the entire application landscape. For audit, compliance, security, and risk management purposes you really need to know what the service is doing and what criticality level it is. Surely, you can make the creation of services really easy - so easy that it's not even viable to define meaningful business names for the services, thus creating an unmaintainable mess. But still, having an application registry or automation that crawls the cloud resources for services can be done afterwards without significantly impacting the speed of creating new services.

michaelbuckbee 6y ago

When I hear things like that all I can think is that I have a wildly different idea of what a "service" is that it can be broken down to such a small chunk of functionality. Are there examples of the size of these individual services? What are they doing?

spc476 6y ago
At work, we have: * two services that accept requests via telephony protocols (SS7, SIP, these are quite small) and forwards the request to: * the business logic component (large only because of the complexity of the business logic implemented). When there's some state changes, it sends a request to: * the replication module (say, midsized), which ensures that the state change is replicated at The Other Site to handle geographical redundancy (a requirement from our customer). * There's one other microservice that the business logic uses and that's to send some data to Apple so they can hand it off to iOS phones (all our stuff internally uses UDP (except for the SS7 stuff)---the addition of a TLS based service was too much to add to the business logic component and this is quite small as well). All of these modules are owned by the team I'm on, namely due to the esoteric nature of it (the telephony protocols, this is real time since it's part of the call path [1], etc.). Within our team, we can work on any component, but generally speaking, we tend to specialize on a few components (I work with the telephony interfaces and the Apple interface; my fellow office mate deals with the business logic). [1] As a cell phone call is being made.
- michaelbuckbee 6y ago
  Thanks for replying, I'm so used to thinking of just CRUD apps or fairly small sized projects, this was really helpful.

axlee 6y ago

> That’s wild. Microservices are mostly beneficial organizationally — a small team can own a service and be able to communicate with the services of other small teams. And a cross-concern fix that a dev used to be able to apply by himself in a day, now has to go through 5 teams, 5 programming languages, 5 kanban boards and 5 QA runs to reach production. I never understood the appeal of teams "owning" services. In my dream world, every engineer can and should be allowed to intervene in as many layers/slices of the code as his mental capacity and understanding allows. Artificial - and sometimes bureaucratic - boundaries are hurtful. To me, it's the result of mid-to-senior software engineers not being ready to let go of their little turfs as the company grows, so they build an organizational wall around their code and call it a service. It has nothing to do with computer science or good engineering. It is pure Conway's law.

hrpnk 6y ago
In my experience, ownership of services is usually defined to ensure that in the engineering organization it's clear who will react as the first responder when there are security patches, production incidents to deal with and also when there are questions about the service's inner workings. It's especially required when the documentation of the services is sparse which is likely to happen when the change rate in the team is high. In more mature engineering organizations, you would define a set of maintainers for the service, who will define the contribution mechanisms and guidelines, so that anyone can make changes to the code. This is further enabled by common patterns and service structures, especially when there is a template to follow. Strict assumed "ownership" creates anti-patterns where each team will define their favourite tech stack or set of libraries making it difficult for others to contribute and decreasing the possible leverage effects in the team.
- axlee 6y ago
  Maybe it is simply a terminology issue, but what you describe, I would call it responsibility rather than ownership. Ownership implies strong exclusivity. Agree with your post otherwise.
  - 6y ago

twic 6y ago

If you have ten people working full-time on it, it is not a microservice, it is just a service. I think the discussion about microservices has suffered more than anyone realises from a lack of shared understanding about what a microservice actually is.

pojzon 6y ago
What in case when that „service” is actually a thousend of „microservice instances” thats communicating with other „services” via some „api gateways”? And the teams managing those „services” do full DevSecOps? 10 people working on such component is actually pretty decent team size for that task...