10 ms·

Wouldn't this just be "having one or two services"? I don't think that's the same as "microservices". Correct me if I'm wrong, but isn't "microservices" when y

Wouldn't this just be "having one or two services"? I don't think that's the same as "microservices". Correct me if I'm wrong, but isn't "microservices" when you make internal components into services by default, instead of defaulting to making a library or class?

Dudester230602 3y ago
Exactly, just use well-factored services of any size and smack anyone saying "micro..." with a wet towel for they are just parroting some barely-profitable silicon valley money sinks.
rmbyrro 3y ago
Exactly my thoughts
- sroussey 3y ago
  Microservices is a newer term than SOA.
  - PedroBatista 3y ago
    They are not the same thing! Microservices is a discount version of SOA with a new coat of paint.
    - sroussey 3y ago
      Clearly. But it’s also SOA taken to the extreme!
lr4444lr 3y ago
I don't want to get too tied up in the terminology, but "microservices-first" does not seem to be the problem the post is describing: One way to mitigate the growing pains of a monolithic backend is to split it into a set of independently deployable services that communicate via APIs. The APIs decouple the services from each other by creating boundaries that are hard to violate, unlike the ones between components running in the same process
- wongarsu 3y ago
  Without getting tied up in the whole "every language except assembly, Python and possibly JavaScript already solved this problem by forcing people to adhere to module-level APIs" argument, I think the crux of the issue is that the article just defines microservice architecture as any architecture consisting of multiple services, and explicitly states "there doesn’t have to be anything micro about the services". Which imho is watering down the term microservices too much. You don't have microservices as soon as you add a second or third service.
  - hinkley 3y ago
    I think we should start calling this Pendulum Blindness. We just go from 'one' to 'too many' as equally unworkable solutions to all of our problems, and each side (and each person currently subscribed to that 'side') knows the other side is wrong. The assumption is that this means their side is right instead of reality, which is nobody is right. The moderates are right, but their answers are wiggly and they're too busy getting stuff done to argue with the purists. But the optics are bad so here we go again on another swing of the swingset. 'Some Services' is probably right, but it varies with domain, company size, and company structure (Conway's Law). And honestly developer maturity, so while 7 may be right for me and my peers today, in a year it might be 6, or 9. There's no clever soundbite to parrot.
    - akrotkov 3y ago
      I've been looking for a concise soundbite (ironically) for this exact issue and Pendulum Blindness definitely fits what I've been trying to summarize. Going to definitely yoink it for next time I have this discussion. It applies to so many things!
    - antonvs 3y ago
      > There's no clever soundbite to parrot. Introducing the Revolutionary "Ten Service Applications" – because Ten is the Magic Number! Tired of the endless debates about how many services your applications should have? Frustrated with the constant struggle to find the "Goldilocks" number of services? Look no further! The future of software design is here, and it's as easy as 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10! The "Ten Service Applications" model is here to rescue you from your software design woes. We're not messing around with random numbers like 7 or 12 services. No, we've cracked the code, and it's all about that perfect "ten." You don't need any more services, and you definitely don't need any less. Ten is the answer to all your architectural problems! So, are you ready to embrace the simplicity, predictability, and coolness of the "Ten Service Applications" model? Join the revolution today and experience software development like never before! Act now, and we'll even throw in a bonus "Top 10 Services" list to inspire your next project. But remember, you only get 10 services, no more, no less—because why mess with perfection?
gedy 3y ago
For some reason, most of the people I've worked with recently are either fully into monoliths or lots of fine grained, interdependent microservices. They don't seem to understand there's a useful middleground of adding fewer, larger data services, etc. It's like SOA isn't a hot topic so people aren't aware of it.
- andorov 3y ago
  I've been using the term 'macro-services' to describe this middle ground.
  - anymouse123456 3y ago
    We used to just call them, "services"
  - girafffe_i 3y ago
    Microliths
- collyw 3y ago
  Start with a monolith and scale out the parts as needed.
philwelch 3y ago
This is why I prefer the old term "service oriented architecture" over "microservices". "Microservices" implies any time a service gets too big, you split it apart and introduce a network dependency even if it introduces more problems than it solves.
shados 3y ago
It's a pretty common issue. If you have 2-3 services, it's pretty easy to manage. And if you have 1000, you likely have the infra to manage them and get the full benefit. But if you have 20 engineers and 60 services, you're likely in a world of pain. That's not microservices, it's distributed monolith and it's the one model that doesn't work (but everyone seems to do)
- alrs 3y ago
  A "microservice" solves scaling issues for huge companies. If you have 60 microservices, you should probably have 600 engineers (10 per) to deal with them. If you're completely underwater and have 10 services per engineer, you're 100% absolutely play-acting "web-scale" for an audience of really dumb managers/investors.
  - benterix 3y ago
    It's not clear to me what you mean by dealing here. Do you mean developing? If so, I completely agree. If you mean deployments, a small number of engineers can manage hundreds of them easily.
  - collyw 3y ago
    I ended up getting into a few arguments at work with the over excited engineer in my last place. He wanted microservices. I said it was just going to add complexity. The app was already a mess, adding network calls rather than function calls wasn't going to help. We had a small teas - 3 backend devs, one of them doing mostly devops and two frontend.
  - shados 3y ago
    With proper devops tooling and a half decent design, even a junior engineer can manage several microservices without issues. Since microservices are about scaling people as much as they are about scaling tech, 10 people in one service is a lot to me in that world. The best company I worked at had about 5-10 deployable per engineers on average and it worked really well. They were small, deployed almost instantly, dependencies were straightforward, etc. Monoliths work fine too, it's just different tradeoffs.
buster 3y ago
Actually, you are wrong. Microservices are surely not about defaulting to new microservices, but to capture a specific context into one service. There is no rule about how big a context is. A context can contain other context's. There can be technical reasons to split deployments into different microservices, but that's not the norm. What you describe is what happens, when people get microservices wrong. In the end, i like the viewpoint that microservices are a deployment pattern, not so much an architecture pattern. Usually, you can draw a component diagram (containing an OrderService and a DeliveryService, etc.) and without technical details (execution environment, protocols), you couldn't tell if it's describing multiple microservices or multiple components in one service.

Dudester230602 3y ago

Exactly, just use well-factored services of any size and smack anyone saying "micro..." with a wet towel for they are just parroting some barely-profitable silicon valley money sinks.

rmbyrro 3y ago

Exactly my thoughts

sroussey 3y ago
Microservices is a newer term than SOA.
- PedroBatista 3y ago
  They are not the same thing! Microservices is a discount version of SOA with a new coat of paint.
  - sroussey 3y ago
    Clearly. But it’s also SOA taken to the extreme!

lr4444lr 3y ago

I don't want to get too tied up in the terminology, but "microservices-first" does not seem to be the problem the post is describing: One way to mitigate the growing pains of a monolithic backend is to split it into a set of independently deployable services that communicate via APIs. The APIs decouple the services from each other by creating boundaries that are hard to violate, unlike the ones between components running in the same process

wongarsu 3y ago
Without getting tied up in the whole "every language except assembly, Python and possibly JavaScript already solved this problem by forcing people to adhere to module-level APIs" argument, I think the crux of the issue is that the article just defines microservice architecture as any architecture consisting of multiple services, and explicitly states "there doesn’t have to be anything micro about the services". Which imho is watering down the term microservices too much. You don't have microservices as soon as you add a second or third service.
- hinkley 3y ago
  I think we should start calling this Pendulum Blindness. We just go from 'one' to 'too many' as equally unworkable solutions to all of our problems, and each side (and each person currently subscribed to that 'side') knows the other side is wrong. The assumption is that this means their side is right instead of reality, which is nobody is right. The moderates are right, but their answers are wiggly and they're too busy getting stuff done to argue with the purists. But the optics are bad so here we go again on another swing of the swingset. 'Some Services' is probably right, but it varies with domain, company size, and company structure (Conway's Law). And honestly developer maturity, so while 7 may be right for me and my peers today, in a year it might be 6, or 9. There's no clever soundbite to parrot.
  - akrotkov 3y ago
    I've been looking for a concise soundbite (ironically) for this exact issue and Pendulum Blindness definitely fits what I've been trying to summarize. Going to definitely yoink it for next time I have this discussion. It applies to so many things!
  - antonvs 3y ago
    > There's no clever soundbite to parrot. Introducing the Revolutionary "Ten Service Applications" – because Ten is the Magic Number! Tired of the endless debates about how many services your applications should have? Frustrated with the constant struggle to find the "Goldilocks" number of services? Look no further! The future of software design is here, and it's as easy as 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10! The "Ten Service Applications" model is here to rescue you from your software design woes. We're not messing around with random numbers like 7 or 12 services. No, we've cracked the code, and it's all about that perfect "ten." You don't need any more services, and you definitely don't need any less. Ten is the answer to all your architectural problems! So, are you ready to embrace the simplicity, predictability, and coolness of the "Ten Service Applications" model? Join the revolution today and experience software development like never before! Act now, and we'll even throw in a bonus "Top 10 Services" list to inspire your next project. But remember, you only get 10 services, no more, no less—because why mess with perfection?

gedy 3y ago

For some reason, most of the people I've worked with recently are either fully into monoliths or lots of fine grained, interdependent microservices. They don't seem to understand there's a useful middleground of adding fewer, larger data services, etc. It's like SOA isn't a hot topic so people aren't aware of it.

andorov 3y ago
I've been using the term 'macro-services' to describe this middle ground.
- anymouse123456 3y ago
  We used to just call them, "services"
- girafffe_i 3y ago
  Microliths
collyw 3y ago
Start with a monolith and scale out the parts as needed.

philwelch 3y ago

This is why I prefer the old term "service oriented architecture" over "microservices". "Microservices" implies any time a service gets too big, you split it apart and introduce a network dependency even if it introduces more problems than it solves.

shados 3y ago

It's a pretty common issue. If you have 2-3 services, it's pretty easy to manage. And if you have 1000, you likely have the infra to manage them and get the full benefit. But if you have 20 engineers and 60 services, you're likely in a world of pain. That's not microservices, it's distributed monolith and it's the one model that doesn't work (but everyone seems to do)

alrs 3y ago
A "microservice" solves scaling issues for huge companies. If you have 60 microservices, you should probably have 600 engineers (10 per) to deal with them. If you're completely underwater and have 10 services per engineer, you're 100% absolutely play-acting "web-scale" for an audience of really dumb managers/investors.
- benterix 3y ago
  It's not clear to me what you mean by dealing here. Do you mean developing? If so, I completely agree. If you mean deployments, a small number of engineers can manage hundreds of them easily.
- collyw 3y ago
  I ended up getting into a few arguments at work with the over excited engineer in my last place. He wanted microservices. I said it was just going to add complexity. The app was already a mess, adding network calls rather than function calls wasn't going to help. We had a small teas - 3 backend devs, one of them doing mostly devops and two frontend.
- shados 3y ago
  With proper devops tooling and a half decent design, even a junior engineer can manage several microservices without issues. Since microservices are about scaling people as much as they are about scaling tech, 10 people in one service is a lot to me in that world. The best company I worked at had about 5-10 deployable per engineers on average and it worked really well. They were small, deployed almost instantly, dependencies were straightforward, etc. Monoliths work fine too, it's just different tradeoffs.

buster 3y ago

Actually, you are wrong. Microservices are surely not about defaulting to new microservices, but to capture a specific context into one service. There is no rule about how big a context is. A context can contain other context's. There can be technical reasons to split deployments into different microservices, but that's not the norm. What you describe is what happens, when people get microservices wrong. In the end, i like the viewpoint that microservices are a deployment pattern, not so much an architecture pattern. Usually, you can draw a component diagram (containing an OrderService and a DeliveryService, etc.) and without technical details (execution environment, protocols), you couldn't tell if it's describing multiple microservices or multiple components in one service.