5 ms·

What exactly is the problem with short downtime during updates/deployments? A lot of people don't care if their deployment requires a few seconds of downtime. A

What exactly is the problem with short downtime during updates/deployments? A lot of people don't care if their deployment requires a few seconds of downtime. And most users of $randomwebsite don't really care if they need to hit reload button every now and then.

bionsystem 4y ago
I guess if you have great ambitions about "web scale" and client retention, a few seconds downtime on your website might mean a loss on a significant amount of potentially new customer. As for me, I actually like downtimes. We have data migrations to do anyway on most major updates (they are automatic when the new container boots but the app is unavailable), which can sometimes take hours, and that leaves us notifying our customers for updates and gives us time to do some sanity checks before handing them over control. Compose is a great tool for single (and probably few) VM(s) deployments. I used to love swarm for slightly bigger ones as well since it's a lot easier to manage than kube and can easily be tailored to ones need, still sad it's being deprecated.
- ancieque 4y ago
  Classic Swarm was deprecated and hardly anyone has been using it. Swarm mode, which everyone usually is talking about is not being deprecated. Docker 23.0.0 shipped with new features for Docker Swarm. https://docs.docker.com/engine/release-notes/23.0/ https://docs.docker.com/engine/release-notes/23.0/
josegonzalez 4y ago
Dokku is in use in production by a large number of companies. Those companies might setup Dokku on a single, large host - perhaps collocated somewhere - and not want to have downtime for their product(s). Others host a swarm of Dokku installations and also want to avoid downtime during deployments. I suspect that "most users" will actually bounce if a site is down for more than a few seconds, or at least become frustrated with the availability of the site they are accessing. Aside, I'd rather not field support requests from folks about how one of the main features Dokku promotes doesn't work when they configure it one way or another.
brightball 4y ago
It depends on the site. If there are a lot of users and you need to deploy an update during the middle of the day, even a little downtime could be disruptive. If you have a global audience then maybe there's no safe "after hours" time to deploy. Zero downtime deployments are fairly critical for a lot of Continuous Delivery / Deployment workflow, so more solutions the merrier as far as I'm concerned.
justinsaccount 4y ago
Zero downtime deployments are just a side effect of doing any kind of A/B deployment. The same features can help you avoid longer downtime. I use dokku at home to run a little web portal. I have a CHECKS file in the repo that has WAIT=1 TIMEOUT=1 ATTEMPTS=10 / Portal ... If I try to update to a new version and the site doesn't come up at all (or a GET for / doesn't have "Portal" in the response), the update is aborted and requests never fail.
simonw 4y ago
If you work on a site with production traffic that you care about, you won't want users to see intermittent errors. Even if you are OK with the occasional error like that, if your deployment system DOES produce intermittent errors, you'll deploy less often... which can become a significant drag on your overall culture of shipping new code. You'll end up wanting to bundle fixes together and deploy them once a twice a week, where the same team with zero-downtime deploys might happily ship new code to production several times an hour. So I see zero-downtime deploys as a very impactful way to encourage a healthy culture around shipping code often. They're also one of those things that's relatively easy to engineer into a system early on, but ferociously difficult to add to a system years down the line when it's already serving large amounts of production traffic and has lots of existing code already built for it.
bityard 4y ago
People might not care, but APIs do.
- vbezhenar 4y ago
  I'd say it's the other way around. Any sane API client would retry for 503. But people might not.
vbezhenar 4y ago
Why few seconds? Some java applications can easily take minutes to initialize.
- dboreham 4y ago
  But that's a bug that could be fixed.
  - biorach 4y ago
    In the Java world very long start-up times are a feature, not a bug
jchw 4y ago
Honestly, I have a slightly different answer than most; because there shouldn't be. Docker already goes through great pains to achieve much of what it can do, and it would be bizarre to go through the effort to use it and then not take advantage of some of the core things it can enable. Even without Docker, service managers like systemd can be used to implement zero downtime deployments too. At this point it'd feel weird and broken if a service management tool just had no support for a "gapless" deployment. I'd feel uneasy using it. The way I see it, what Kubernetes does with health and liveness checks is actually just good hygiene irrespective of how many requests you can tolerate dropping, or if your container even serves requests to begin with. Tools that manage services should strive to provide similar functionality where possible.
rahoulb 4y ago
The apps that I build (and use dokku to deploy - thank you josegonzalez, it's a great tool) are critical to their users. While ten, twenty, thirty seconds isn't much in the grand scheme of things, if it happens just as someone is doing an important update, it reduces trust in the software. If it happens a couple of times, they're going to report back to their boss that the system is unreliable and fails just when they need it most. And with international users, I can't be sure that I'm picking a time to do a deployment where no-one is going to be using it.

bionsystem 4y ago

I guess if you have great ambitions about "web scale" and client retention, a few seconds downtime on your website might mean a loss on a significant amount of potentially new customer. As for me, I actually like downtimes. We have data migrations to do anyway on most major updates (they are automatic when the new container boots but the app is unavailable), which can sometimes take hours, and that leaves us notifying our customers for updates and gives us time to do some sanity checks before handing them over control. Compose is a great tool for single (and probably few) VM(s) deployments. I used to love swarm for slightly bigger ones as well since it's a lot easier to manage than kube and can easily be tailored to ones need, still sad it's being deprecated.

ancieque 4y ago
Classic Swarm was deprecated and hardly anyone has been using it. Swarm mode, which everyone usually is talking about is not being deprecated. Docker 23.0.0 shipped with new features for Docker Swarm. https://docs.docker.com/engine/release-notes/23.0/ https://docs.docker.com/engine/release-notes/23.0/

josegonzalez 4y ago

Dokku is in use in production by a large number of companies. Those companies might setup Dokku on a single, large host - perhaps collocated somewhere - and not want to have downtime for their product(s). Others host a swarm of Dokku installations and also want to avoid downtime during deployments. I suspect that "most users" will actually bounce if a site is down for more than a few seconds, or at least become frustrated with the availability of the site they are accessing. Aside, I'd rather not field support requests from folks about how one of the main features Dokku promotes doesn't work when they configure it one way or another.

brightball 4y ago

It depends on the site. If there are a lot of users and you need to deploy an update during the middle of the day, even a little downtime could be disruptive. If you have a global audience then maybe there's no safe "after hours" time to deploy. Zero downtime deployments are fairly critical for a lot of Continuous Delivery / Deployment workflow, so more solutions the merrier as far as I'm concerned.

justinsaccount 4y ago

Zero downtime deployments are just a side effect of doing any kind of A/B deployment. The same features can help you avoid longer downtime. I use dokku at home to run a little web portal. I have a CHECKS file in the repo that has WAIT=1 TIMEOUT=1 ATTEMPTS=10 / Portal ... If I try to update to a new version and the site doesn't come up at all (or a GET for / doesn't have "Portal" in the response), the update is aborted and requests never fail.

simonw 4y ago

If you work on a site with production traffic that you care about, you won't want users to see intermittent errors. Even if you are OK with the occasional error like that, if your deployment system DOES produce intermittent errors, you'll deploy less often... which can become a significant drag on your overall culture of shipping new code. You'll end up wanting to bundle fixes together and deploy them once a twice a week, where the same team with zero-downtime deploys might happily ship new code to production several times an hour. So I see zero-downtime deploys as a very impactful way to encourage a healthy culture around shipping code often. They're also one of those things that's relatively easy to engineer into a system early on, but ferociously difficult to add to a system years down the line when it's already serving large amounts of production traffic and has lots of existing code already built for it.

bityard 4y ago

People might not care, but APIs do.

vbezhenar 4y ago
I'd say it's the other way around. Any sane API client would retry for 503. But people might not.

vbezhenar 4y ago

Why few seconds? Some java applications can easily take minutes to initialize.

dboreham 4y ago
But that's a bug that could be fixed.
- biorach 4y ago
  In the Java world very long start-up times are a feature, not a bug

jchw 4y ago

Honestly, I have a slightly different answer than most; because there shouldn't be. Docker already goes through great pains to achieve much of what it can do, and it would be bizarre to go through the effort to use it and then not take advantage of some of the core things it can enable. Even without Docker, service managers like systemd can be used to implement zero downtime deployments too. At this point it'd feel weird and broken if a service management tool just had no support for a "gapless" deployment. I'd feel uneasy using it. The way I see it, what Kubernetes does with health and liveness checks is actually just good hygiene irrespective of how many requests you can tolerate dropping, or if your container even serves requests to begin with. Tools that manage services should strive to provide similar functionality where possible.

rahoulb 4y ago

The apps that I build (and use dokku to deploy - thank you josegonzalez, it's a great tool) are critical to their users. While ten, twenty, thirty seconds isn't much in the grand scheme of things, if it happens just as someone is doing an important update, it reduces trust in the software. If it happens a couple of times, they're going to report back to their boss that the system is unreliable and fails just when they need it most. And with international users, I can't be sure that I'm picking a time to do a deployment where no-one is going to be using it.