18 ms·

Don't disagree with the article, but to play Devil's Advocate, here are some examples of when IME the cost IS worth it: 1) there are old 3rd party dependency i

Don't disagree with the article, but to play Devil's Advocate, here are some examples of when IME the cost IS worth it: 1) there are old 3rd party dependency incompatibilities that you can spin off and let live separately instead of doing a painful refactor, rebuilding in house, or kludgy gluing 2) there are deploy limitations on mission critical high available systems that should not hold up other systems deployment that have different priorities/sensitive business hours time windows 3) system design decisions that cannot be abstracted away are at the mercy of some large clients of the company that are unable or unwilling to change their way of doing things - you can silo the pain. And to be clear, it's not that these things are "cost free". It's just a cost that is worth paying to protect the simpler monolith from becoming crap encrusted, disrupted with risky deploys, or constrained by business partners with worse tech stacks.

eterevsky 3y ago
1) Why is it better than wrapping it in an interface with a clear API without extracting it into a separate service?
- paulddraper 3y ago
  Those dependencies might cross language boundaries, or interfere with your other dependencies running in the same process.
  - bingemaker 3y ago
    On the contrary, when they fail silently, it is hard debug "dependent" services
    - mark_undoio 3y ago
      In the Java world, we've developed record/replay across microservice boundaries, so it's effectively possible to step from a failure in one microservice and into the service that sent it bad data. https://docs.undo.io/java/Microservices.html https://docs.undo.io/java/Microservices.html [Edit: for which, by the way, any feedback is welcome - it's technically quite promising but real world experience is worth a lot!]
- voxic11 3y ago
  Because of dependency issues like he mentioned. If I am using Library A which depends on version 1 of Library C and I need to start using Library B which depends on version 2 of Library C then I have a clear problem because most popular programming languages don't support referencing multiple different versions of the same library.
  - furstenheim 3y ago
    This node got it just right. You only get this issue for big stateful libraries, like frameworks
  - rmbyrro 3y ago
    Can't we just isolate these two services in containers, using different library versions? They don't need to be microservices in order to isolate dependencies, do they? In Python, for instance, you don't even need containers. Just different virtual environments running on separate processes.
    - mjr00 3y ago
      If you have two separate processes running in two separate containers... those are two separate services. You need to solve the same problems that would come with running them on two different EC2 instances: what's the method for communicating with the other container? What happens if the other container I'm calling is down? If the other container is down or slow to respond to my API calls, am I dealing with backpressure gracefully or will the system start to experiencing a cascade of failures?
    - jethro_tell 3y ago
      I suppose if you do that, they will communicate over the network likely via api and have the ability to scale independently. You just invented microservices, lol.
  - foobiekr 3y ago
    You’re not wrong here but usually this comes down to having one or a small number of version specific container processors (and I do not mean container in the docker sense) to host those functions. Not microservices. That said, almost always, if you are seriously trying to keep old unsupported dependencies running, you’re violating any reasonable security stance. I’m not saying it never happens, but often the issues that the code is not understood, and no one is capable of supporting it, and so you are deep in the shit already.
- collyw 3y ago
  More moving part. A network call can fail in more ways than a function call. Also something no one has mentioned until now, the more "services" you have the more of a pain in the arse it is to get a development environment running.
paulddraper 3y ago
And those would apply to < 10% of your total code base.
eduction 3y ago
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
j45 3y ago
There are many ways to architecture well that doesn’t mean prematurely introducing micro services. I’m a fan of microservices btw. Premature optimization and scaling is almost as bad of a form of technical debt as others when you have to optimize in a completely different manner and direction.
jupp0r 3y ago
To add another to your list: Being able to easily use different programming languages. Not every language is a good fit for every problem. Being able to write your machine learning deduction services in Python, your server side rendered UI in Rails and your IO and concurrency heavy services in Go might justify the additional overhead of having separate services for these three.
- renegade-otter 3y ago
  These are almost never pragmatic decisions. Giving teams independence over the stack usually results in resume-driven development, and now your JS developers are forced to maintain a Go server because some jock thought it was a cool thing to do . Due diligence in these cases is rare.
  - Cthulhu_ 3y ago
    I don't believe a team should have that much say in their technology, unless they themselves are also responsible for hiring, training, etcetera - so it kinda depends on how autonomous a team is. That said, as the article also mentions, "micro" can be a bit of a misnomer; you could have a 50 person team working on a single "micro" service, in which case things like hiring and training are much more natural. (to add, I've never worked in a team of 50 on one product; 50 people is A Lot)
  - marcus_holmes 3y ago
    I've seen this play out for reals at a place a few years ago. Every team used a different tech, and all of them selected because of resume-driven development. People moving teams to get a particular tech on their resume. No common method for deployment, and endless issues getting things deployed. Everyone's a newbie because we were all learning a new, cool, stack. And everyone making stupid newbie mistakes. Never again. When I build teams forevermore, I pick the tech stack and I recruit people who know that tech stack, or want to learn that tech stack. And we stick to that tech stack whenever possible.
    - sgarland 3y ago

eterevsky 3y ago

1) Why is it better than wrapping it in an interface with a clear API without extracting it into a separate service?

paulddraper 3y ago
Those dependencies might cross language boundaries, or interfere with your other dependencies running in the same process.
- bingemaker 3y ago
  On the contrary, when they fail silently, it is hard debug "dependent" services
  - mark_undoio 3y ago
    In the Java world, we've developed record/replay across microservice boundaries, so it's effectively possible to step from a failure in one microservice and into the service that sent it bad data. https://docs.undo.io/java/Microservices.html https://docs.undo.io/java/Microservices.html [Edit: for which, by the way, any feedback is welcome - it's technically quite promising but real world experience is worth a lot!]
voxic11 3y ago
Because of dependency issues like he mentioned. If I am using Library A which depends on version 1 of Library C and I need to start using Library B which depends on version 2 of Library C then I have a clear problem because most popular programming languages don't support referencing multiple different versions of the same library.
- furstenheim 3y ago
  This node got it just right. You only get this issue for big stateful libraries, like frameworks
- rmbyrro 3y ago
  Can't we just isolate these two services in containers, using different library versions? They don't need to be microservices in order to isolate dependencies, do they? In Python, for instance, you don't even need containers. Just different virtual environments running on separate processes.
  - mjr00 3y ago
    If you have two separate processes running in two separate containers... those are two separate services. You need to solve the same problems that would come with running them on two different EC2 instances: what's the method for communicating with the other container? What happens if the other container I'm calling is down? If the other container is down or slow to respond to my API calls, am I dealing with backpressure gracefully or will the system start to experiencing a cascade of failures?
  - jethro_tell 3y ago
    I suppose if you do that, they will communicate over the network likely via api and have the ability to scale independently. You just invented microservices, lol.
- foobiekr 3y ago
  You’re not wrong here but usually this comes down to having one or a small number of version specific container processors (and I do not mean container in the docker sense) to host those functions. Not microservices. That said, almost always, if you are seriously trying to keep old unsupported dependencies running, you’re violating any reasonable security stance. I’m not saying it never happens, but often the issues that the code is not understood, and no one is capable of supporting it, and so you are deep in the shit already.
collyw 3y ago
More moving part. A network call can fail in more ways than a function call. Also something no one has mentioned until now, the more "services" you have the more of a pain in the arse it is to get a development environment running.

paulddraper 3y ago

And those would apply to < 10% of your total code base.

eduction 3y ago

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

j45 3y ago

There are many ways to architecture well that doesn’t mean prematurely introducing micro services. I’m a fan of microservices btw. Premature optimization and scaling is almost as bad of a form of technical debt as others when you have to optimize in a completely different manner and direction.

jupp0r 3y ago

To add another to your list: Being able to easily use different programming languages. Not every language is a good fit for every problem. Being able to write your machine learning deduction services in Python, your server side rendered UI in Rails and your IO and concurrency heavy services in Go might justify the additional overhead of having separate services for these three.

renegade-otter 3y ago
These are almost never pragmatic decisions. Giving teams independence over the stack usually results in resume-driven development, and now your JS developers are forced to maintain a Go server because some jock thought it was a cool thing to do . Due diligence in these cases is rare.
- Cthulhu_ 3y ago
  I don't believe a team should have that much say in their technology, unless they themselves are also responsible for hiring, training, etcetera - so it kinda depends on how autonomous a team is. That said, as the article also mentions, "micro" can be a bit of a misnomer; you could have a 50 person team working on a single "micro" service, in which case things like hiring and training are much more natural. (to add, I've never worked in a team of 50 on one product; 50 people is A Lot)
- marcus_holmes 3y ago
  I've seen this play out for reals at a place a few years ago. Every team used a different tech, and all of them selected because of resume-driven development. People moving teams to get a particular tech on their resume. No common method for deployment, and endless issues getting things deployed. Everyone's a newbie because we were all learning a new, cool, stack. And everyone making stupid newbie mistakes. Never again. When I build teams forevermore, I pick the tech stack and I recruit people who know that tech stack, or want to learn that tech stack. And we stick to that tech stack whenever possible.
  - sgarland 3y ago