3 ms·

I wonder, at which point is a service getting called microservice? The team-sized service advocated by the usual argument does not sound that "micro" to me - bu

by soco 11mo ago

I wonder, at which point is a service getting called microservice? The team-sized service advocated by the usual argument does not sound that "micro" to me - but is most of the times the right size.

xnx 11mo ago
Good point. They would not have been as popular if they were called "multi-services" or "team partitioned apps".
karmakaze 11mo ago
The definitional size I've read and heard is that you team could (with the benefit of hindsight) be able to reimplement a microservice in 2 weeks. That sounds fairly extreme but a month seems within reason to me. The other key difference between microservices and other architectures is that each microservice should do its primary function (temporarily) without hard dependencies, which basically means having a copy of the data that's needed. Service Oriented Architecture doesn't have this as one of its properties which is why I think of it as a mildly distributed monolith. "Distributed monolith" is the worst thing you could call a set of microservices--all the pain without the gains.
- ants_everywhere 11mo ago
  That's a pretty extreme definition in my opinion. Google played a role in popularizing the microservice approach. When I was at Google, a microservice would often be worked on with teams of 10-30 people and take a few years to implement. A small team of 4-5 people could get a service started, but it would often take additional headcount to productionize the service and go to market. I have a feeling people overestimate how small microservices are and underestimate how big monorepos are. About 9 times out of ten when I see something called a monorepo it's for a single project as opposed to a repo that spans multiple projects. I think the same is true of microservices. Many things that Amazon or Google considers microservices might be considered monoliths by the outside world.
  - treis 11mo ago
    That's the good old two pizza team service oriented architecture that Amazon is known for. Microservices are much smaller than that. At current job I think we have slightly more microservices than engineers on the team.
    - ants_everywhere 11mo ago
      > At current job I think we have slightly more microservices than engineers on the team. You are free to do that, but that's a very specific take on microservices that is at odds with the wider industry. As I said above, what I was describing is what Google referred to internally as microservices. Microservices are not smaller than that as a matter of definition, but you can choose to make them extra tiny if you wish to. If you look at what others say about microservices, it's consistent with what I'm saying. For example, Wikipedia gives as a dichotomy: "Service-oriented architecture can be implemented with web services or Microservices." By that definition every service based architecture that isn't built on web services is built on microservices. Google Cloud lists some examples: > Many e-commerce platforms use microservices to manage different aspects of their operations, such as product catalog, shopping cart, order processing, and customer accounts. Each of these microservices is a heavy lift. It takes a full team to implement a shopping cart correctly, or customer accounts. In fact each of these has multiple businesses offering SaaS solutions for that particular problem. What I hear you saying is that if your team were, for example, working on a shopping cart, they might break the shopping cart into smaller services. That's okay, but that's not in any way required by the definition of microservices. Azure says https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices https://learn.microsoft.com/en-us/azure/architecture/guide/a... > Model services around the business domain. Use DDD to identify bounded contexts and define clear service boundaries. Avoid creating overly granular services, which can increase complexity and reduce performance. Azure also has a guide for determining microservice boundary where again you'd need a full team to build microservices of this size https://learn.microsoft.com/en-us/azure/architecture/microservices/model/microservice-boundaries https://learn.microsoft.com/en-us/azure/architecture/microse...
  - hosh 11mo ago
dragonwriter 11mo ago
"Microservices" were called "microservices" because "service-oriented architecture" had devolved in practice, and even moreso in the general consciousness which had largely rejected it for this reason, into near-monoliths that supported SOAP and the WS-* series of standards for integration. Then, after they became popular, people got carried away with the "micro" bit, and "microservices" started getting rejected because the associated practice had skewed in the opposite direction that had caused "SOA" to be rejected. I guess the next iteration needs to be "goldilocks services".

by soco 11mo ago

I wonder, at which point is a service getting called microservice? The team-sized service advocated by the usual argument does not sound that "micro" to me - but is most of the times the right size.

xnx 11mo ago

Good point. They would not have been as popular if they were called "multi-services" or "team partitioned apps".

karmakaze 11mo ago

The definitional size I've read and heard is that you team could (with the benefit of hindsight) be able to reimplement a microservice in 2 weeks. That sounds fairly extreme but a month seems within reason to me. The other key difference between microservices and other architectures is that each microservice should do its primary function (temporarily) without hard dependencies, which basically means having a copy of the data that's needed. Service Oriented Architecture doesn't have this as one of its properties which is why I think of it as a mildly distributed monolith. "Distributed monolith" is the worst thing you could call a set of microservices--all the pain without the gains.

ants_everywhere 11mo ago
That's a pretty extreme definition in my opinion. Google played a role in popularizing the microservice approach. When I was at Google, a microservice would often be worked on with teams of 10-30 people and take a few years to implement. A small team of 4-5 people could get a service started, but it would often take additional headcount to productionize the service and go to market. I have a feeling people overestimate how small microservices are and underestimate how big monorepos are. About 9 times out of ten when I see something called a monorepo it's for a single project as opposed to a repo that spans multiple projects. I think the same is true of microservices. Many things that Amazon or Google considers microservices might be considered monoliths by the outside world.
- treis 11mo ago
  That's the good old two pizza team service oriented architecture that Amazon is known for. Microservices are much smaller than that. At current job I think we have slightly more microservices than engineers on the team.
  - ants_everywhere 11mo ago
    > At current job I think we have slightly more microservices than engineers on the team. You are free to do that, but that's a very specific take on microservices that is at odds with the wider industry. As I said above, what I was describing is what Google referred to internally as microservices. Microservices are not smaller than that as a matter of definition, but you can choose to make them extra tiny if you wish to. If you look at what others say about microservices, it's consistent with what I'm saying. For example, Wikipedia gives as a dichotomy: "Service-oriented architecture can be implemented with web services or Microservices." By that definition every service based architecture that isn't built on web services is built on microservices. Google Cloud lists some examples: > Many e-commerce platforms use microservices to manage different aspects of their operations, such as product catalog, shopping cart, order processing, and customer accounts. Each of these microservices is a heavy lift. It takes a full team to implement a shopping cart correctly, or customer accounts. In fact each of these has multiple businesses offering SaaS solutions for that particular problem. What I hear you saying is that if your team were, for example, working on a shopping cart, they might break the shopping cart into smaller services. That's okay, but that's not in any way required by the definition of microservices. Azure says https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices https://learn.microsoft.com/en-us/azure/architecture/guide/a... > Model services around the business domain. Use DDD to identify bounded contexts and define clear service boundaries. Avoid creating overly granular services, which can increase complexity and reduce performance. Azure also has a guide for determining microservice boundary where again you'd need a full team to build microservices of this size https://learn.microsoft.com/en-us/azure/architecture/microservices/model/microservice-boundaries https://learn.microsoft.com/en-us/azure/architecture/microse...
- hosh 11mo ago

dragonwriter 11mo ago

"Microservices" were called "microservices" because "service-oriented architecture" had devolved in practice, and even moreso in the general consciousness which had largely rejected it for this reason, into near-monoliths that supported SOAP and the WS-* series of standards for integration. Then, after they became popular, people got carried away with the "micro" bit, and "microservices" started getting rejected because the associated practice had skewed in the opposite direction that had caused "SOA" to be rejected. I guess the next iteration needs to be "goldilocks services".