6 ms·

> A microservice is about the size of a service Is it? Isn't it a purely organizational paradigm where each teams are responsible for a specific service and cl

> A microservice is about the size of a service Is it? Isn't it a purely organizational paradigm where each teams are responsible for a specific service and clear API boundaries are defined between teams? rather than the "size" of an application? (which is hard to quantify, if my app does AI and needs 100,000 line of code for a single endpoint, is it still micro?). That's why I believe "micro" is an unfortunate qualifier what is essentially basic SOA.

steveklabnik 9y ago
I see them as different axes. A service can be small, and it can be the only service. SOA means your larger service is comprised of smaller services, but says nothing about the size of those services. An URL shortener is a micro service without SOA. A huge web application with four services that are half a million LOC each is SOA, but not micro services. I wonder what Martin Folwer has to say...
- jbf1001 9y ago
  He and James Lewis had this to say about it. https://www.thoughtworks.com/insights/blog/microservices-nutshell https://www.thoughtworks.com/insights/blog/microservices-nut... I believe James' talk at the end of the article says he wishes it was called something else because of the implication of size.
- stronglikedan 9y ago
  > How big is a microservice?[0] > Although “microservice” has become a popular name for this architectural style, its name does lead to an unfortunate focus on the size of service, and arguments about what constitutes “micro”. In our conversations with microservice practitioners, we see a range of sizes of services. The largest sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the smaller size scale we've seen setups where a team of half-a-dozen would support half-a-dozen services. > This leads to the question of whether there are sufficiently large differences within this size range that the service-per-dozen-people and service-per-person sizes shouldn't be lumped under one microservices label. At the moment we think it's better to group them together, but it's certainly possible that we'll change our mind as we explore this style further. [0]https://martinfowler.com/articles/microservices.html https://martinfowler.com/articles/microservices.html
  - steveklabnik 9y ago
    Thanks! I was on mobile so it was a bit awkward. I'll have to revise my understanding :)
    - pdpi 9y ago
      For what it’s worth, I much prefer your version. It emphasises the similarities between “empterprisey” SOA and the “cool hip” Microservice, while also highlighting one of the bigger differences. People get too caught up in “how small is micro”, which is just silly extremism.
Floegipoky 9y ago
There is at least a 1:, possibly :*, relationship between teams:microservices. The "micro" refers to responsibilities, each service fulfills a single purpose. So yeah, a 100k line service could still be "micro" if it owns 1 thing. That's the beauty, you can start out with a quick hackjob to get the doors open and then replace it with a 100k behemoth later. Mapping each team directly to a microservice seems dangerous because it encourages the service to be as big as the team, rather than as big as it needs to be. The "microservices" approach is all about keeping your components small. But you're right, microservices is pretty indistinguishable from a (healthy) SOA. And SOA is pretty indistinguishable from the UNIX philosophy when you get down to it.

steveklabnik 9y ago

I see them as different axes. A service can be small, and it can be the only service. SOA means your larger service is comprised of smaller services, but says nothing about the size of those services. An URL shortener is a micro service without SOA. A huge web application with four services that are half a million LOC each is SOA, but not micro services. I wonder what Martin Folwer has to say...

jbf1001 9y ago
He and James Lewis had this to say about it. https://www.thoughtworks.com/insights/blog/microservices-nutshell https://www.thoughtworks.com/insights/blog/microservices-nut... I believe James' talk at the end of the article says he wishes it was called something else because of the implication of size.
stronglikedan 9y ago
> How big is a microservice?[0] > Although “microservice” has become a popular name for this architectural style, its name does lead to an unfortunate focus on the size of service, and arguments about what constitutes “micro”. In our conversations with microservice practitioners, we see a range of sizes of services. The largest sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the smaller size scale we've seen setups where a team of half-a-dozen would support half-a-dozen services. > This leads to the question of whether there are sufficiently large differences within this size range that the service-per-dozen-people and service-per-person sizes shouldn't be lumped under one microservices label. At the moment we think it's better to group them together, but it's certainly possible that we'll change our mind as we explore this style further. [0]https://martinfowler.com/articles/microservices.html https://martinfowler.com/articles/microservices.html
- steveklabnik 9y ago
  Thanks! I was on mobile so it was a bit awkward. I'll have to revise my understanding :)
  - pdpi 9y ago
    For what it’s worth, I much prefer your version. It emphasises the similarities between “empterprisey” SOA and the “cool hip” Microservice, while also highlighting one of the bigger differences. People get too caught up in “how small is micro”, which is just silly extremism.

Floegipoky 9y ago

There is at least a 1:, possibly :*, relationship between teams:microservices. The "micro" refers to responsibilities, each service fulfills a single purpose. So yeah, a 100k line service could still be "micro" if it owns 1 thing. That's the beauty, you can start out with a quick hackjob to get the doors open and then replace it with a 100k behemoth later. Mapping each team directly to a microservice seems dangerous because it encourages the service to be as big as the team, rather than as big as it needs to be. The "microservices" approach is all about keeping your components small. But you're right, microservices is pretty indistinguishable from a (healthy) SOA. And SOA is pretty indistinguishable from the UNIX philosophy when you get down to it.