8 ms·

I never get this desire for micro services. You IDE can help if there are 500 functions, but nothing would help you if you have 500 micro services. Almost no on

I never get this desire for micro services. You IDE can help if there are 500 functions, but nothing would help you if you have 500 micro services. Almost no one fully understands such a system. Is is hard to argue who parts of code are unused. And large scale refactoring is impossible. The upside seems to be some mythical infinite scalability which will collapse under such positive feedback loops.

delusional 2y ago
I think the dream is that you can reason locally. I'm not convinced that it actually help any, but the dream is that having everything as services, complete with external boundaries and enforced constraints, you're able to more accurately reason about the orchestration of services. It's hard to reason about your order flow if half if it depends on some implicit procedure that's part of your shopping cart. The business I'm part of isn't really after "scalable" technology, so that might color my opinion, but a lot of the arguments for microservices I hear from my colleagues are actually benefits of modular programs. Those two have just become synonyms in their minds.
- klabb3 2y ago
  > […] the dream is that having everything as services, […], you're able to more accurately reason about the orchestration of services. Well.. I mean that’s an entirely circular point. Maybe you mean something else? That you can individually deploy and roll back different functionality that belong to a team? There’s some appeal for operations yeah. > but a lot of the arguments for microservices I hear from my colleagues are actually benefits of modular programs Yes I mean from a development perspective a library call is far, far superior to an http call. It is much more performant and orders of magnitude easier to reason about since the caller and callee are running the same version of the code. That means that breaking changes is a refactor and single commit, whereas with a service boundary you need a whole migration. You can’t avoid services altogether, like say external services like a payment portal by a completely different company. But to deliberately create more of these expensive boundaries for no reason, within the same small org or team, is madness, imo.
  - scubbo 2y ago
    > That means that breaking changes is a refactor and single commit, whereas with a service boundary you need a whole migration. This decoupling-of-updates-across-a-call-boundary is one of the key reasons why I _prefer_ microservices. Monoliths _force_ you to update your caller and callee at the same time, which appears attractive when they are 1-1 but becomes prohibitively difficult when there are multiple callers of the same logic - changes take longer and longer to be approved, and you drift further from CD. Microservices allow you to gradually roll out a change across the company at an appropriate rate - the new logic can be provided at a different endpoint for early adopters, and other consumers can gradually migrate to it as they are encouraged or compelled to do so. Similarly with updates to cross-cutting concerns. Say there's a breaking change to your logging or testing framework, or an encryption library, or something like that. You can force all your teams to down tools and to synchronize in collaborating on one monster commit to The Monolith that will update everything at once - or you can tell everyone to update their own microservices, at their own pace (but by a given deadline, if InfoSec so demands), without blocking each other. Making _and testing and deploying_ one large commit containing lots of changes is, counter-intuitively, much harder than making lots of small commits containing the same quantity of actual change - your IDE can find-and-replace easily across the monorepo, but most updates due to breaking changes require human intervention and cannot be scripted. The ability for different microservices within the same company to consume different versions of the same utility library at the same time (as they are gradually, independently, updated) is a _benefit_, not a drawback. > a library call[...]is much more performant [...than] these expensive boundaries I mean, no argument here - but latency tends to be excessively sought by developers, beyond the point of actual experience improvement. If it's your limiting factor, then by all means look for ways to improve it - but designing for fast development and deployment has paid far greater dividends, in my experience, than overly optimizing for latency.
    - sa46 2y ago
      > Monoliths _force_ you to update your caller and callee at the same time It's possible to migrate method calls incrementally (create a new method or add a parameter). In large codebases, it's necessary to migrate incrementally. The techniques overlap those of changing an RPC method.
- deterministic 2y ago
  You can absolutely reason locally with libraries. A library has an API that defines its boundary. And you can enforce that only the API can be called from the main application.
FooBarWidget 2y ago
The point of microservices is not technical, it's so that the deployment- and repository ownership structure matches your organization structure, and that clear lines are drawn between responsibilities.
- sim7c00 2y ago
  its also easier to find devs that have the skills to create and maintain thin services than a large complicated monolith, despite the difficulties found when having to debug a constellation of microservices during a crisis.
  - phil21 2y ago
    For the folks who downvoted this - why? I hire developers and this is the absolute truth of the matter. You can get away with hiring devs able to only debug their little micro empire so long as you can retain some super senior rockstar level folks able to see the big picture when it inevitably breaks down in production under load. These skills are becoming rarer by the day, when they used to be nearly table stakes for a “senior” dev. Microservices have their place, but many times you can see that it’s simply developers saying “not my problem” to the actual hard business case things.
    - pards 2y ago
      > retain some super senior rockstar level folks able to see the big picture This is the critical piece that many organisations miss. Microservices are the bricks; but the customer needs those assembled into a house.
    - mannyv 2y ago
      You need those senior folks who can see the big picture, whether you use monoliths or microservices. The real benefit of a microservice is that it's easier to see the interactions, because you can't call into some random and unexpected part of the codebase...or at least it's much harder to do something that's not noticeable like that.
morningsam 2y ago
>The upside seems to be some mythical infinite scalability which will collapse under such positive feedback loops. Unless I misunderstand something here, they say pretty early in the article that they didn't have autoscaling configured for the service in question and there is no indication they scaled up the number of replicas manually after the downtime to account for the accumulated backlog of requests. So, in my mind, of course there can be no infinite, or really any, scalability if the service isn't allowed to scale...
- vrosas 2y ago
  I’ve seen monumental engineering effort go into managing systems because for one reason or another people refused to use (or properly configure) autoscaling.
dropofwill 2y ago
The concepts here apply to any client-server networking setup. Monoliths could still have web clients, native apps, IOT sensors, third party APIs, databases, etc.
lmm 2y ago
The real reason is that it's impossible to safely upgrade a dependency in Python. And by the time you realise this you're probably already committed to building your system in Python (for mostly good reasons). So the only way to get access to new functionality is to break off parts of your system into new deployables that can have new versions of your dependencies, and you keep doing this forever.
jeffbee 2y ago
> but nothing would help you if you have 500 micro services. Have you pondered the likelihood that your IDE sucks?
liampulles 2y ago
What you are describing, where 1 function = 1 service, is serverless architectures. The "ideal" with any service (micro or macro) is to get it so that it maximises richness of functionality over scale of API. But I agree one should do monolith by default.
golergka 2y ago
> You IDE can help if there are 500 functions, but nothing would help you if you have 500 micro services. Using micro-services doesn't mean you're using individual repositories and projects for each one. The best approach I've seen is one repo, with inter-linked packages/assemblies (lingo can vary depending on the language).
hinkley 2y ago
Meanwhile if you use an Erlang language you can horizontally scale later.
deterministic 2y ago
Agree 100% A monolith with N libraries (instead of N microservices) work so much better in my experience. You avoid the networking overhead, and the complexity of reasoning about all the possible ways N microservices will behave when one or more microservices crash.

delusional 2y ago

I think the dream is that you can reason locally. I'm not convinced that it actually help any, but the dream is that having everything as services, complete with external boundaries and enforced constraints, you're able to more accurately reason about the orchestration of services. It's hard to reason about your order flow if half if it depends on some implicit procedure that's part of your shopping cart. The business I'm part of isn't really after "scalable" technology, so that might color my opinion, but a lot of the arguments for microservices I hear from my colleagues are actually benefits of modular programs. Those two have just become synonyms in their minds.

klabb3 2y ago
> […] the dream is that having everything as services, […], you're able to more accurately reason about the orchestration of services. Well.. I mean that’s an entirely circular point. Maybe you mean something else? That you can individually deploy and roll back different functionality that belong to a team? There’s some appeal for operations yeah. > but a lot of the arguments for microservices I hear from my colleagues are actually benefits of modular programs Yes I mean from a development perspective a library call is far, far superior to an http call. It is much more performant and orders of magnitude easier to reason about since the caller and callee are running the same version of the code. That means that breaking changes is a refactor and single commit, whereas with a service boundary you need a whole migration. You can’t avoid services altogether, like say external services like a payment portal by a completely different company. But to deliberately create more of these expensive boundaries for no reason, within the same small org or team, is madness, imo.
- scubbo 2y ago
  > That means that breaking changes is a refactor and single commit, whereas with a service boundary you need a whole migration. This decoupling-of-updates-across-a-call-boundary is one of the key reasons why I _prefer_ microservices. Monoliths _force_ you to update your caller and callee at the same time, which appears attractive when they are 1-1 but becomes prohibitively difficult when there are multiple callers of the same logic - changes take longer and longer to be approved, and you drift further from CD. Microservices allow you to gradually roll out a change across the company at an appropriate rate - the new logic can be provided at a different endpoint for early adopters, and other consumers can gradually migrate to it as they are encouraged or compelled to do so. Similarly with updates to cross-cutting concerns. Say there's a breaking change to your logging or testing framework, or an encryption library, or something like that. You can force all your teams to down tools and to synchronize in collaborating on one monster commit to The Monolith that will update everything at once - or you can tell everyone to update their own microservices, at their own pace (but by a given deadline, if InfoSec so demands), without blocking each other. Making _and testing and deploying_ one large commit containing lots of changes is, counter-intuitively, much harder than making lots of small commits containing the same quantity of actual change - your IDE can find-and-replace easily across the monorepo, but most updates due to breaking changes require human intervention and cannot be scripted. The ability for different microservices within the same company to consume different versions of the same utility library at the same time (as they are gradually, independently, updated) is a _benefit_, not a drawback. > a library call[...]is much more performant [...than] these expensive boundaries I mean, no argument here - but latency tends to be excessively sought by developers, beyond the point of actual experience improvement. If it's your limiting factor, then by all means look for ways to improve it - but designing for fast development and deployment has paid far greater dividends, in my experience, than overly optimizing for latency.
  - sa46 2y ago
    > Monoliths _force_ you to update your caller and callee at the same time It's possible to migrate method calls incrementally (create a new method or add a parameter). In large codebases, it's necessary to migrate incrementally. The techniques overlap those of changing an RPC method.
deterministic 2y ago
You can absolutely reason locally with libraries. A library has an API that defines its boundary. And you can enforce that only the API can be called from the main application.

FooBarWidget 2y ago

The point of microservices is not technical, it's so that the deployment- and repository ownership structure matches your organization structure, and that clear lines are drawn between responsibilities.

sim7c00 2y ago
its also easier to find devs that have the skills to create and maintain thin services than a large complicated monolith, despite the difficulties found when having to debug a constellation of microservices during a crisis.
- phil21 2y ago
  For the folks who downvoted this - why? I hire developers and this is the absolute truth of the matter. You can get away with hiring devs able to only debug their little micro empire so long as you can retain some super senior rockstar level folks able to see the big picture when it inevitably breaks down in production under load. These skills are becoming rarer by the day, when they used to be nearly table stakes for a “senior” dev. Microservices have their place, but many times you can see that it’s simply developers saying “not my problem” to the actual hard business case things.
  - pards 2y ago
    > retain some super senior rockstar level folks able to see the big picture This is the critical piece that many organisations miss. Microservices are the bricks; but the customer needs those assembled into a house.
  - mannyv 2y ago
    You need those senior folks who can see the big picture, whether you use monoliths or microservices. The real benefit of a microservice is that it's easier to see the interactions, because you can't call into some random and unexpected part of the codebase...or at least it's much harder to do something that's not noticeable like that.

morningsam 2y ago

>The upside seems to be some mythical infinite scalability which will collapse under such positive feedback loops. Unless I misunderstand something here, they say pretty early in the article that they didn't have autoscaling configured for the service in question and there is no indication they scaled up the number of replicas manually after the downtime to account for the accumulated backlog of requests. So, in my mind, of course there can be no infinite, or really any, scalability if the service isn't allowed to scale...

vrosas 2y ago
I’ve seen monumental engineering effort go into managing systems because for one reason or another people refused to use (or properly configure) autoscaling.

dropofwill 2y ago

The concepts here apply to any client-server networking setup. Monoliths could still have web clients, native apps, IOT sensors, third party APIs, databases, etc.

lmm 2y ago

The real reason is that it's impossible to safely upgrade a dependency in Python. And by the time you realise this you're probably already committed to building your system in Python (for mostly good reasons). So the only way to get access to new functionality is to break off parts of your system into new deployables that can have new versions of your dependencies, and you keep doing this forever.

jeffbee 2y ago

> but nothing would help you if you have 500 micro services. Have you pondered the likelihood that your IDE sucks?

liampulles 2y ago

What you are describing, where 1 function = 1 service, is serverless architectures. The "ideal" with any service (micro or macro) is to get it so that it maximises richness of functionality over scale of API. But I agree one should do monolith by default.

golergka 2y ago

> You IDE can help if there are 500 functions, but nothing would help you if you have 500 micro services. Using micro-services doesn't mean you're using individual repositories and projects for each one. The best approach I've seen is one repo, with inter-linked packages/assemblies (lingo can vary depending on the language).

hinkley 2y ago

Meanwhile if you use an Erlang language you can horizontally scale later.

deterministic 2y ago

Agree 100% A monolith with N libraries (instead of N microservices) work so much better in my experience. You avoid the networking overhead, and the complexity of reasoning about all the possible ways N microservices will behave when one or more microservices crash.