5 ms·

Is this correct? Practically every job advert I've seen claims they are using microservices (and want candidates with such experience).

by arunix 2y ago

Alupis 2y ago
It is not correct. This is the sentiment people who don't understand k8s often have, because of handwavy complexity blah blah blah. The predictable quote is always along the lines of "unless you're Google scale..." - which misses perhaps 80% of what microservices bring to the table. Then they go off and build complicated monorepos that take 6 months to learn before you can effectively contribute. All paradigms have trade offs. Engineering is about understanding those trade offs and using them where appropriate. Unfortunately too many people just jump on the "k8s is complicated" bandwagon (because it challenges most of the assumptions they've previously held in software development) and entirely write-off microservices without taking the time to learn what problems microservices solve.
- int_19h 2y ago
  People are well aware of what problems microservices solve. They are also aware of all the numerous problems they introduce, such as making debugging much more complicated, for starters.
  - Alupis 2y ago
    Well, you're repeating one of the myths yourself here. Debugging is different and some people find that harder because it's not what they are used to. That does not mean it is actually more complicated.
    - chucke 2y ago
      Debugging IS more difficult. Observability is much harder, sometimes needlessly. When you're 4 languages deep and have to enable distributed tracing across a variety of brokers/protocols (http, sqs, grpc, queue in a database) you know the lord intended you to spend your time in a more useful way.
      - Alupis 2y ago
        So you're describing a bunch of unnecessary things, and stating they make microservices more difficult to debug? Nobody says you need http, sqs, grpc, and queue (message broker) all in the same system. Nor does anyone say you need to use 4 languages for these things, nor does anyone say you need to only enable observability when there's issues. Bunch of handwavy "it's complicated" nonsense basically - demonstrating yet again most people don't really understand microservices. A microservice can be as simple as studying it's inputs and outputs and nothing more. All of which can be observed via tracing, logging or whatever you prefer, either on a sampled-basis, only on errors, or all the time. Microservices make you rethink almost all of your software engineering assumptions - and some people are just not in the right headspace to make the jump. The biggest change is viewing/treating your codebases like cattle more than pets. Automate everything, fail quickly, stop caring about crashes, keep services as small and focused as possible, stop worrying about multiple supported releases, etc. It is very different, but that doesn't mean it needs to be complex. That doesn't mean microservices are the solution to every problem. It does mean, however, it's a solution to more problems than some people are willing to admit and/or take the time to understand.
        Tainnor 2y ago
        Microservices are distributed and distributed systems are inherently more complex than non-distributed ones.[0] > A microservice can be as simple as studying it's inputs and outputs and nothing more. All of which can be observed via tracing, logging or whatever you prefer, either on a sampled-basis, only on errors, or all the time. In a statically-typed monolith, function calls are typed, I can jump to the declaration site with a mouse click and if I pass the wrong type, the code won't compile. That's way easier than "you can observe the inputs and outputs" (and hope that your observations generalise sufficiently). And yes, there are solutions for this (contract tests, Avro schemas, etc.), but they are inherently more complicated (maybe the most interesting idea I've seen in this space is Unison[1], but that's not gonna gain a lot of traction anytime soon, I predict). Of course, microservices have valid use cases, but they come at a significant cost. I don't understand how one can argue that that cost doesn't exist. [0]: https://en.m.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.m.wikipedia.org/wiki/Fallacies_of_distributed_com... [1]: https://www.unison-lang.org/ https://www.unison-lang.org/
    - int_19h 2y ago
      It is inevitably more complicated because there are more moving pieces to coordinate. This applies to all IPC, not just in this context. To some extent you can mitigate this with tooling that tries to hide the complexity, but that usually only works for simple cases.

Is this correct? Practically every job advert I've seen claims they are using microservices (and want candidates with such experience).

by arunix 2y ago

Is this correct? Practically every job advert I've seen claims they are using microservices (and want candidates with such experience).

Alupis 2y ago

It is not correct. This is the sentiment people who don't understand k8s often have, because of handwavy complexity blah blah blah. The predictable quote is always along the lines of "unless you're Google scale..." - which misses perhaps 80% of what microservices bring to the table. Then they go off and build complicated monorepos that take 6 months to learn before you can effectively contribute. All paradigms have trade offs. Engineering is about understanding those trade offs and using them where appropriate. Unfortunately too many people just jump on the "k8s is complicated" bandwagon (because it challenges most of the assumptions they've previously held in software development) and entirely write-off microservices without taking the time to learn what problems microservices solve.

int_19h 2y ago
People are well aware of what problems microservices solve. They are also aware of all the numerous problems they introduce, such as making debugging much more complicated, for starters.
- Alupis 2y ago
  Well, you're repeating one of the myths yourself here. Debugging is different and some people find that harder because it's not what they are used to. That does not mean it is actually more complicated.
  - chucke 2y ago
    Debugging IS more difficult. Observability is much harder, sometimes needlessly. When you're 4 languages deep and have to enable distributed tracing across a variety of brokers/protocols (http, sqs, grpc, queue in a database) you know the lord intended you to spend your time in a more useful way.
    - Alupis 2y ago
      So you're describing a bunch of unnecessary things, and stating they make microservices more difficult to debug? Nobody says you need http, sqs, grpc, and queue (message broker) all in the same system. Nor does anyone say you need to use 4 languages for these things, nor does anyone say you need to only enable observability when there's issues. Bunch of handwavy "it's complicated" nonsense basically - demonstrating yet again most people don't really understand microservices. A microservice can be as simple as studying it's inputs and outputs and nothing more. All of which can be observed via tracing, logging or whatever you prefer, either on a sampled-basis, only on errors, or all the time. Microservices make you rethink almost all of your software engineering assumptions - and some people are just not in the right headspace to make the jump. The biggest change is viewing/treating your codebases like cattle more than pets. Automate everything, fail quickly, stop caring about crashes, keep services as small and focused as possible, stop worrying about multiple supported releases, etc. It is very different, but that doesn't mean it needs to be complex. That doesn't mean microservices are the solution to every problem. It does mean, however, it's a solution to more problems than some people are willing to admit and/or take the time to understand.
      - Tainnor 2y ago
        Microservices are distributed and distributed systems are inherently more complex than non-distributed ones.[0] > A microservice can be as simple as studying it's inputs and outputs and nothing more. All of which can be observed via tracing, logging or whatever you prefer, either on a sampled-basis, only on errors, or all the time. In a statically-typed monolith, function calls are typed, I can jump to the declaration site with a mouse click and if I pass the wrong type, the code won't compile. That's way easier than "you can observe the inputs and outputs" (and hope that your observations generalise sufficiently). And yes, there are solutions for this (contract tests, Avro schemas, etc.), but they are inherently more complicated (maybe the most interesting idea I've seen in this space is Unison[1], but that's not gonna gain a lot of traction anytime soon, I predict). Of course, microservices have valid use cases, but they come at a significant cost. I don't understand how one can argue that that cost doesn't exist. [0]: https://en.m.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.m.wikipedia.org/wiki/Fallacies_of_distributed_com... [1]: https://www.unison-lang.org/ https://www.unison-lang.org/
  - int_19h 2y ago
    It is inevitably more complicated because there are more moving pieces to coordinate. This applies to all IPC, not just in this context. To some extent you can mitigate this with tooling that tries to hide the complexity, but that usually only works for simple cases.