4 ms·

The fact the author was kidding by writing "you can't have (planned) downtime" in itself shows everything has downtime. So if your app can have downtime, why no

by slver 5y ago

The fact the author was kidding by writing "you can't have (planned) downtime" in itself shows everything has downtime. So if your app can have downtime, why not have some planned downtime as well? Oh the users can't take it, they'll go away, yadda yadda. That's usually BS. I've witnessed giant sites with massive traffic that go offline every night. Apple's own web store goes offline before updates every time (most valuable brand, looks like this doesn't affect them huh?). Every marketing exchange also goes offline every day and weekend (except the fancy cryptocoin ones I guess). My overall point is, keep things simple. Planned downtime can vastly simplify your update deployment, and planned downtime can result in less unplanned downtime. So don't give it up for cargo cult reasons. You're not Google Search until proven otherwise. Also you can have planned downtime piecemeal. If your data is sharded in some way (for example by user) you can update the user when they log out and you'll seemingly have no global downtime. But downtime is inherent to well working systems. You sleep every night. If you don't things go haywire.

0xbadcafebee 5y ago
I don't want to have to stay up late to do it. I don't want to have to deal with a rollback. I, and the developer, want to be able to make changes when we feel like it, not based on a schedule. The developer does their work at their pace, I go about my work without thinking about their deployment. Apps with planned downtime are often poorly designed and have other problems, usually due to nobody taking the time to make them work better or fix tech debt. Downtime deployments can lead to huge changes which, if not completed successfully, can lead to much longer downtimes in the event of a rollback. And, yeah, I don't want my customer to see any downtime or errors. Call me fussy, but I want our product to work better than everyone else's. It's 2021. We may not have flying cars, but we do have zero downtime deployments, sometimes. Let's not go back to the dark ages please.
- slver 5y ago
  Unfortunately "it's CURRENT_YEAR" and "downtime means you're poorly designed" are very poor, circular arguments. The only thing you said back which I can trace back to an objective problem is that you don't want to stay late.
  - 0xbadcafebee 5y ago
    Would you rather a change 1) depend on two people doing a series of precarious steps and recovery which could possibly lead to a large amount of downtime, or 2) depend on one person doing a series of predictable small steps through automation which won't lead to any downtime? I prefer #2. Also I don't want to stay late.
    - slver 5y ago
      Planned downtime means only one thing: you have an atomic update, that needs some downtime. It doesn't inform you that the steps are "precarious" vs. "predictable" or that you have have or don't have quick way of recovery, or how small or big the update is. You can just as easily screw up your application state without downtime. You gotta be careful thinking purely by association. It's natural and intuitive, but often causes you to group unrelated characteristics together. Maybe my update is as simple as adding a column to a table. If I have millions of rows, that won't be instant, it can take say half an hour. In InnoDB for example it'll do a full table copy to add a column. But it's not precarious or fragile, or dangerous. It's just what it says on the can. It'll either do the copy or it won't.
nickjj 5y ago
> So don't give it up for cargo cult reasons. You're not Google Search until proven otherwise. Agreed, and in a lot of cases the planned downtime is a matter of seconds which will only be noticeable if someone happens to be loading your page at the exact point in time where your web server is offline. In most cases it doesn't really take that long to change a column in a table with 15,000 rows on it. For most apps I'd much rather go the route of making this a dead simple operation with 5 seconds of downtime vs a multi-migration 8 step approach.
rtpg 5y ago
- people tend to want to use many systems during working hours - engineers/CS staff tend to want to work during working hours => it is hard to plan for downtime during normal working hours. If you want to deploy multiple times a day, and if you want to be able to merge in new code into your main branch, and you don't want to have to gate in merges etc for "deploy windows" with downtime, a great solution is to just do the extra work to avoid downtime on simple stuff. I think the irony is that you really need to already be a certain size to do downtime-centric workflows reasonably without asking a bunch of people to do stuff at weird hours.
- slver 5y ago
  I have to point out, it seems, that you don't change your database schema "multiple times a day". Nor is every database schema linked to downtime (especially if you follow service/module orientation with distinct aggregates, and don't throw everything in one shared database like it's the 90s). Most updates don't need downtime. Few rare ones, do, unless you want major complications. The irony you point out, isn't a huge irony. When your business is small, downtime is fine. As you grow and it becomes "not fine" you have people around the world that can handle it off-peak hours for the users during dev work hours.
  - rtpg 5y ago
    Sorry, I guess the rationale here is more that DB schema changes (at least for most "basic" web applications) go through the same codebase as normal application changes, so it's in the same pipeline of changes as other changes. By asking for changes to be done in a highly-available way, you reduce coordination efforts needed for release. "Our main branch is always deployable" is a great default! And while actualy DB schema changes aren't multiple times a day, even on a relatively small team simple DB changes come into the pipeline once a week? Most aren't backwards-incompatible, but the beauty of it is that we don't even have to consider that much, because of this strategy. Maybe the "no downtime" stuff is unreasonable. In my case, we are a relatively small team servicing a good amount of customers (who do time-sensitive work), so the effort here is worth it. But if you can get away with it (with downtime windows being big enough to recover from issues), then it's definitely gonna be easier.

by slver 5y ago

0xbadcafebee 5y ago

I don't want to have to stay up late to do it. I don't want to have to deal with a rollback. I, and the developer, want to be able to make changes when we feel like it, not based on a schedule. The developer does their work at their pace, I go about my work without thinking about their deployment. Apps with planned downtime are often poorly designed and have other problems, usually due to nobody taking the time to make them work better or fix tech debt. Downtime deployments can lead to huge changes which, if not completed successfully, can lead to much longer downtimes in the event of a rollback. And, yeah, I don't want my customer to see any downtime or errors. Call me fussy, but I want our product to work better than everyone else's. It's 2021. We may not have flying cars, but we do have zero downtime deployments, sometimes. Let's not go back to the dark ages please.

slver 5y ago
Unfortunately "it's CURRENT_YEAR" and "downtime means you're poorly designed" are very poor, circular arguments. The only thing you said back which I can trace back to an objective problem is that you don't want to stay late.
- 0xbadcafebee 5y ago
  Would you rather a change 1) depend on two people doing a series of precarious steps and recovery which could possibly lead to a large amount of downtime, or 2) depend on one person doing a series of predictable small steps through automation which won't lead to any downtime? I prefer #2. Also I don't want to stay late.
  - slver 5y ago
    Planned downtime means only one thing: you have an atomic update, that needs some downtime. It doesn't inform you that the steps are "precarious" vs. "predictable" or that you have have or don't have quick way of recovery, or how small or big the update is. You can just as easily screw up your application state without downtime. You gotta be careful thinking purely by association. It's natural and intuitive, but often causes you to group unrelated characteristics together. Maybe my update is as simple as adding a column to a table. If I have millions of rows, that won't be instant, it can take say half an hour. In InnoDB for example it'll do a full table copy to add a column. But it's not precarious or fragile, or dangerous. It's just what it says on the can. It'll either do the copy or it won't.

nickjj 5y ago

> So don't give it up for cargo cult reasons. You're not Google Search until proven otherwise. Agreed, and in a lot of cases the planned downtime is a matter of seconds which will only be noticeable if someone happens to be loading your page at the exact point in time where your web server is offline. In most cases it doesn't really take that long to change a column in a table with 15,000 rows on it. For most apps I'd much rather go the route of making this a dead simple operation with 5 seconds of downtime vs a multi-migration 8 step approach.

rtpg 5y ago

- people tend to want to use many systems during working hours - engineers/CS staff tend to want to work during working hours => it is hard to plan for downtime during normal working hours. If you want to deploy multiple times a day, and if you want to be able to merge in new code into your main branch, and you don't want to have to gate in merges etc for "deploy windows" with downtime, a great solution is to just do the extra work to avoid downtime on simple stuff. I think the irony is that you really need to already be a certain size to do downtime-centric workflows reasonably without asking a bunch of people to do stuff at weird hours.

slver 5y ago
I have to point out, it seems, that you don't change your database schema "multiple times a day". Nor is every database schema linked to downtime (especially if you follow service/module orientation with distinct aggregates, and don't throw everything in one shared database like it's the 90s). Most updates don't need downtime. Few rare ones, do, unless you want major complications. The irony you point out, isn't a huge irony. When your business is small, downtime is fine. As you grow and it becomes "not fine" you have people around the world that can handle it off-peak hours for the users during dev work hours.
- rtpg 5y ago
  Sorry, I guess the rationale here is more that DB schema changes (at least for most "basic" web applications) go through the same codebase as normal application changes, so it's in the same pipeline of changes as other changes. By asking for changes to be done in a highly-available way, you reduce coordination efforts needed for release. "Our main branch is always deployable" is a great default! And while actualy DB schema changes aren't multiple times a day, even on a relatively small team simple DB changes come into the pipeline once a week? Most aren't backwards-incompatible, but the beauty of it is that we don't even have to consider that much, because of this strategy. Maybe the "no downtime" stuff is unreasonable. In my case, we are a relatively small team servicing a good amount of customers (who do time-sensitive work), so the effort here is worth it. But if you can get away with it (with downtime windows being big enough to recover from issues), then it's definitely gonna be easier.