2 ms·

Some reasons may be: 1. Multiple languages/tech stacks. Have something like protobufs and now any language can "import" your library instead of it just being t

Some reasons may be: 1. Multiple languages/tech stacks. Have something like protobufs and now any language can "import" your library instead of it just being things that can handle cffi. 2. State management. For example, redis couldn't be an in-process library. There are in-process kv stores but that's not the idea of redis. 3. Transparent monitoring for all languages. I can passively detect all retries, latencies, request counts, etc since there is a protocol. 4. Centralized fixes. Similarly to dynamic linking I can now update a single component and "fix the world" rather than redeploying every binary. 5. Canaries: I can deploy version N+1 to a mirror of production traffic and make sure it doesn't explode. Then I can route 1%, 10%, 50%, 100% of traffic and check those metrics as well. 6. If something goes horribly wrong I can rewrite the entire service for performance or maintenance or whatever within a tightly bounded amount of time. Discord has many blog posts about doing this for some of their services. Great talk: https://www.youtube.com/watch?v=-UKEPd2ipEk https://www.youtube.com/watch?v=-UKEPd2ipEk

erik_seaberg 5y ago
> Multiple languages/tech stacks. This is what I'm excited about--enabling a team to use the most powerful tools that address their own problems, rather than whichever Blub is approachable enough for the entire staff.
- throwawaaarrgh 5y ago
  But this is a problem at large scale. Each language and stack carries a variety of overhead. The more of them you have, the higher the overhead is. Say you run a factory, and everyone needs a hammer. When there's only two teams, two kinds of hammer is fine. But fast forward to 10 teams. Can you always get all of those hammers when you need them? What if team #3 needs extra support? You need to find a new engineer who knows hammer #3, or take an engineer off of team #6 and train them on how to use hammer #3. And if all the hammers need a slight modification specific to that company, you need to make 10 different modifications. And how will all the teams benefit from shared hammer tips-n-tricks if they all use different hammers? There's a lot more overhead than you think at first.
  - erik_seaberg 5y ago
    I don’t care what brand of chainsaw I may use, but we’re going to have trouble hiring and retaining chainsaw experts if our staff is only allowed steak knives (which is what other teams are familiar with).
  - adjkant 5y ago
    It's a problem if you assume that your infrastructure needs won't scale. For many of the positives listed upthread, it can be a worthwhile trade to heavily invest in infrastructure. It just needs to be a conscious choice, and it also does more or less eliminate any small or even medium sized companies from making microservives work best. Unless you can afford to have an infra team bigger than multiple of your product feature teams, you're not at the point of needing microservices probably.

erik_seaberg 5y ago

> Multiple languages/tech stacks. This is what I'm excited about--enabling a team to use the most powerful tools that address their own problems, rather than whichever Blub is approachable enough for the entire staff.

throwawaaarrgh 5y ago
But this is a problem at large scale. Each language and stack carries a variety of overhead. The more of them you have, the higher the overhead is. Say you run a factory, and everyone needs a hammer. When there's only two teams, two kinds of hammer is fine. But fast forward to 10 teams. Can you always get all of those hammers when you need them? What if team #3 needs extra support? You need to find a new engineer who knows hammer #3, or take an engineer off of team #6 and train them on how to use hammer #3. And if all the hammers need a slight modification specific to that company, you need to make 10 different modifications. And how will all the teams benefit from shared hammer tips-n-tricks if they all use different hammers? There's a lot more overhead than you think at first.
- erik_seaberg 5y ago
  I don’t care what brand of chainsaw I may use, but we’re going to have trouble hiring and retaining chainsaw experts if our staff is only allowed steak knives (which is what other teams are familiar with).
- adjkant 5y ago
  It's a problem if you assume that your infrastructure needs won't scale. For many of the positives listed upthread, it can be a worthwhile trade to heavily invest in infrastructure. It just needs to be a conscious choice, and it also does more or less eliminate any small or even medium sized companies from making microservives work best. Unless you can afford to have an infra team bigger than multiple of your product feature teams, you're not at the point of needing microservices probably.