3 ms·

Most things don't need zero downtime deployment. Now it's nice to have and might be an interesting technical challenge to solve, but it's usually not strictly n

Most things don't need zero downtime deployment. Now it's nice to have and might be an interesting technical challenge to solve, but it's usually not strictly needed. edit: when I worked as a sysadmin we would have to schedule outages for updating apps that were designed for zero downtime anyways because those were the processes of the organisation.

maxthegeek1 4y ago
What? I've never worked for a company that would tolerate downtime during deployments. Downtime is ok for personal projects, but not for most business applications.
- chillfox 4y ago
  Most business have daily downtime where the entire business is closed as in not business hours. Being sensitive to downtime is more common for companies that has some kind of online service as their primary product, but most companies are not online companies, or even global companies with offices across all the time zones. Even for online business some downtime might be acceptable or even preferred. I used to work for a company that made most of it's money through a website and it would take the site offline for 8 hours a few weeks before important events to run a full scale load test on the production infrastructure. Another place I worked we had to schedule downtime even when updating applications that were designed for zero downtime. I have never worked a place that didn't allow for downtime or even heard of such a place other than the big tech companies.
  - fomine3 4y ago
    scheduled maintenance downtime at night != unplanned failure downtime at random time
    - chillfox 4y ago
      Correct, but in the context of deploys I would hope they are not random failures, but rather planned events that you do when you have updates to... deploy.
      - maxthegeek1 4y ago
        Yes, but you also don't want to have to deploy in the middle of the night in order to avoid downtime during peak hours. Not only is that a pain for whoever is monitoring the deployment, but now if the deployment breaks something you're going to have to go wake up all of the relevant stakeholders, if you even know who they are. Not to say late night deployments are never justified, but definitely not something devs want to be doing regularly.
        chillfox 4y ago
        There’s alternatives like making rollbacks really easy, and then automating it.
sanderjd 4y ago
Yeah I've realized this is just a disagreement over the word "most" which won't really be resolvable empirically. It doesn't fit my experience that most applications are single node with lax uptime and failover requirements.
- chillfox 4y ago
  That's fair.
- mixmastamyk 4y ago
  There’s likely to be many more intranet apps than customer-facing ones.

maxthegeek1 4y ago

What? I've never worked for a company that would tolerate downtime during deployments. Downtime is ok for personal projects, but not for most business applications.

chillfox 4y ago
Most business have daily downtime where the entire business is closed as in not business hours. Being sensitive to downtime is more common for companies that has some kind of online service as their primary product, but most companies are not online companies, or even global companies with offices across all the time zones. Even for online business some downtime might be acceptable or even preferred. I used to work for a company that made most of it's money through a website and it would take the site offline for 8 hours a few weeks before important events to run a full scale load test on the production infrastructure. Another place I worked we had to schedule downtime even when updating applications that were designed for zero downtime. I have never worked a place that didn't allow for downtime or even heard of such a place other than the big tech companies.
- fomine3 4y ago
  scheduled maintenance downtime at night != unplanned failure downtime at random time
  - chillfox 4y ago
    Correct, but in the context of deploys I would hope they are not random failures, but rather planned events that you do when you have updates to... deploy.
    - maxthegeek1 4y ago
      Yes, but you also don't want to have to deploy in the middle of the night in order to avoid downtime during peak hours. Not only is that a pain for whoever is monitoring the deployment, but now if the deployment breaks something you're going to have to go wake up all of the relevant stakeholders, if you even know who they are. Not to say late night deployments are never justified, but definitely not something devs want to be doing regularly.
      - chillfox 4y ago
        There’s alternatives like making rollbacks really easy, and then automating it.

sanderjd 4y ago

Yeah I've realized this is just a disagreement over the word "most" which won't really be resolvable empirically. It doesn't fit my experience that most applications are single node with lax uptime and failover requirements.

chillfox 4y ago
That's fair.
mixmastamyk 4y ago
There’s likely to be many more intranet apps than customer-facing ones.