Experienced Devs

4013 readers

1 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 2 years ago

MODERATORS

[email protected]

Do your routine backend code releases require downtime? (lemm.ee)

submitted 2 years ago by [email protected] to c/[email protected]

34 comments fedilink hide all child comments

Curious to know how many people do zero-downtime deployment of backend code and how many people regularly take their service down, even if very briefly, to roll out new code.

Zero-downtime deployment is valuable in some applications and a complete waste of effort in others, of course, but that doesn't mean people do it when they should and skip it when it's not useful.

you are viewing a single comment's thread
view the rest of the comments

[–] none 1 points 2 years ago

Zero downtime here. We use ECS with services sitting behind ALBs. At deploy time we spin up a new task sets, wait for the new tasks to become healthy and then direct a small amount of traffic towards the new set for evaluation. If no alarms go off due to a degradation in metrics, the amount of traffic is increased until the old version has 0 traffic. After a period of time to allow for instant rollbacks if necessary, the old version is shut down.

What's more interesting to me is ways to accomplish the same thing for things that aren't just web services where it's trivial to direct traffic to one version or the other. For example, if you have workers consuming a queue, I haven't found a way to gradually increase the amount of work available to the new version without implementing custom application logic (I work on a platform with thousands of services, so I'm looking for ways to do it on an infrastructure level rather than each service implementing something).