4 ms·

Gonna throw out an anti-cirlcenjerk take: We know. Absolutely no one has ever said that your super basic webapp that has the latency requirements of "make sure

Gonna throw out an anti-cirlcenjerk take: We know. Absolutely no one has ever said that your super basic webapp that has the latency requirements of "make sure it works", an SLO of "it's fine most of the time", and a code base under 10k lines of code worked on by one guy, needs these super complicated systems. Even FAANG will run internal services and dashboards on a single binary, but when every second of downtime can be translated into lost money, then you begin to care.

arnaudsm 3y ago
I wouldn't say complexity and reliability are correlated, worse, it's an inverse correlation.
- zeroCalories 3y ago
  Yes, programs that don't need to do anything can be very reliable.
Yeroc 3y ago
Unfortunately many of these super-complicated systems run at odds to having a reliable and fast, system even when every second of downtime can be translated into lost money.
- zeroCalories 3y ago
  Realistically, they are required. I don't care how you do it, but you need 1. Seamless fail overs 2. Easy horizontal scaling 3. Location based load balancing 4. A way to deploy and rollback all of these automatically. As a result, things are gonna get complicated no matter what you do. But as it turns out, using something like Kubernetes, Elixir, or AppEngine can make all of that very manageable.
  - Yeroc 3y ago
    #3 is debatable for many, many businesses. The other three are (almost) trivial with a decent load balancer and blue/green deployments. This is something very achievable without an over-complicated architecture.
    - zeroCalories 3y ago
      3 is incredibly important for global businesses. You ever try using a Japanese website? As for how "easy" the others are, the truth is that the options I provided will be easier to make, easier to maintain, and work better than your home grown solution once you need to account for multiple machines.
dehrmann 3y ago
> every second of downtime can be translated into lost money, then you begin to care You don't even need to be at FAANG-scale for this. Once you have paying customers, you care.
leeoniya 3y ago
this is the correct take, imo. i think a lot of projects start out overly complicated with the expectation of getting huge and needing to scale horizontally in a hurry, which a monolith cannot really do well. of course these expectations rarely become reality and you end up with some huge web of microservices that two devs need to orchestrate and manage for no benefit. at Grafana we're now decoupling a monolith primarily so teams working on different parts can manage their own deployments/rollbacks/incidents independently of "official" monolith versions. it's a very hard/expensive refactor once you're at a scale of millions of users and hundreds of engs. but really an impossible thing to predict at inception.

arnaudsm 3y ago

I wouldn't say complexity and reliability are correlated, worse, it's an inverse correlation.

zeroCalories 3y ago
Yes, programs that don't need to do anything can be very reliable.

Yeroc 3y ago

Unfortunately many of these super-complicated systems run at odds to having a reliable and fast, system even when every second of downtime can be translated into lost money.

zeroCalories 3y ago
Realistically, they are required. I don't care how you do it, but you need 1. Seamless fail overs 2. Easy horizontal scaling 3. Location based load balancing 4. A way to deploy and rollback all of these automatically. As a result, things are gonna get complicated no matter what you do. But as it turns out, using something like Kubernetes, Elixir, or AppEngine can make all of that very manageable.
- Yeroc 3y ago
  #3 is debatable for many, many businesses. The other three are (almost) trivial with a decent load balancer and blue/green deployments. This is something very achievable without an over-complicated architecture.
  - zeroCalories 3y ago
    3 is incredibly important for global businesses. You ever try using a Japanese website? As for how "easy" the others are, the truth is that the options I provided will be easier to make, easier to maintain, and work better than your home grown solution once you need to account for multiple machines.

dehrmann 3y ago

> every second of downtime can be translated into lost money, then you begin to care You don't even need to be at FAANG-scale for this. Once you have paying customers, you care.

leeoniya 3y ago

this is the correct take, imo. i think a lot of projects start out overly complicated with the expectation of getting huge and needing to scale horizontally in a hurry, which a monolith cannot really do well. of course these expectations rarely become reality and you end up with some huge web of microservices that two devs need to orchestrate and manage for no benefit. at Grafana we're now decoupling a monolith primarily so teams working on different parts can manage their own deployments/rollbacks/incidents independently of "official" monolith versions. it's a very hard/expensive refactor once you're at a scale of millions of users and hundreds of engs. but really an impossible thing to predict at inception.