Top 5 Most-Used Deployment Strategies
Top 5 Most-Used Deployment Strategies
Get a Free System Design PDF with 158 pages by subscribing to our weekly newsletter: https://bytebytego.ck.page/subscribe
Animation tools: Adobe Illustrator and After Effects.
Checkout our bestselling System Design Interview books:
Volume 1: https://amzn.to/3Ou7gkd
Volume 2: https://amzn.to/3HqGozy
The digital version of System Design Interview books: https://bit.ly/3mlDSk9
ABOUT US:
Covering topics and trends in large-scale system design, from the authors of the best-selling System Design Interview series.
Content
1.68 -> foreign
9.38 -> into the world of deploying code to
12 -> production nothing beats the
14.219 -> satisfaction of seeing our code go live
16.26 -> to millions of users it is always
18.72 -> thrilling to see beginning there is not
21.24 -> always easy let's explore some of the
23.58 -> common strategies
25.68 -> one of the earliest methods of deploying
27.96 -> changes to production is the Big Bang
30.18 -> deployment
31.32 -> picture it as like ripping off a
33.48 -> Band-Aid we push all our changes at once
36.239 -> this causes a bit of down time as we
38.82 -> have to shut down the old system to
40.8 -> switch on a new one
42.78 -> the downtime is usually short but be
45.3 -> careful you can Sting If things don't go
47.879 -> as planned preparation and testing are
50.879 -> key if things goes wrong we roll back to
53.82 -> the previous version
55.98 -> rolling back is not always paying free
57.84 -> though we still might disrupt users and
60.78 -> that could still be data implication we
63.6 -> need to have a solid Roblox plan
66.119 -> Big Bang is sometimes the only choice
68.58 -> for example when an intricate database
71.28 -> upgrade is involved
73.34 -> then we have the rolling deployment
76.14 -> it is more like a marathon than a Sprint
78.479 -> this method let us incrementally update
81.6 -> different parts of the system over time
84.06 -> it's a stage rollout where we gradually
86.82 -> deploy the new version of the
88.32 -> application to the production
89.939 -> environment
91.38 -> here's an example of how it might work
94.02 -> imagine we have 10 servers running in
96.6 -> our application in a rolling deployment
99.119 -> we might take down the first server
101.159 -> deploy the new version of our
103.14 -> application there and bring it back
105.36 -> online once we've confirmed everything
107.759 -> is working as expected we'll move on to
110.939 -> the second server and so on this
113.7 -> approach allows a new version to
115.92 -> gradually replace the old one server by
118.56 -> server until the entire system is
120.899 -> updated
122.34 -> one big advantage of rolling deployment
124.86 -> is that it usually prevents down time
127.32 -> while we are updating one server the
130.319 -> others are still up and running serving
132.239 -> our users
133.62 -> another Advantage is that we can spot
136.02 -> and mitigate any issues early during the
139.08 -> rollout
140.04 -> this reduces the risk of widespread
142.56 -> problems we're only ever exposing a
145.8 -> small part of our system to the new
147.72 -> version at any one time
150.36 -> however rolling deployment is typically
152.819 -> a slower process and while it reduces
155.7 -> the risk of system-wide issues it
158.4 -> doesn't entirely eliminate it
160.68 -> if an issue slip past our initial checks
163.44 -> it might still propagate as we update
165.599 -> more servers
166.86 -> this strategy doesn't support targeted
169.26 -> rollouts we can't control Rich users get
172.62 -> the new version during the rollout all
175.2 -> users will gradually see the new version
177.48 -> as we update the servers we can direct
180.54 -> the new version to specific users based
183.599 -> on criteria like location device type
186.72 -> Etc
187.92 -> rolling deployment is a popular choice
190.08 -> for many teams it balances risk and user
193.56 -> impact in a control methodical way
197.28 -> now let's take a look at blue green
198.84 -> deployment
199.98 -> here we maintain two identical
201.84 -> production systems
203.58 -> cleverly named blue and green
206.94 -> at any given time one site is active and
209.819 -> visible to users and the other side is
212.22 -> Idle the active environment say blue
215.54 -> serves the current live version of the
218.04 -> application to the users the idle one is
221.34 -> our playground where we can safely
223.56 -> deploy and test the new version
226.319 -> here's how it might work when we have a
228.599 -> new version ready to go we deploy it to
231.72 -> the green environment while this is
234.06 -> happening the blues system is still live
237 -> in serving the current version of the
239.22 -> application to users
241.68 -> our QA team then tests a new version in
244.739 -> the green environment this gives us the
247.14 -> chance to catch and fix any bugs or
249.48 -> issues before they reach our users
252.42 -> once the new version in the green
254.58 -> environment is steam ready we simply
256.799 -> switch the load balancer to redirect
258.6 -> traffic from the blue environment to the
260.88 -> green one users are seamlessly
263.04 -> transitioned to the new version of the
265.08 -> application with zero downtime
267.72 -> now the blue environment becomes idle
270.24 -> and serves as a safety net
272.34 -> it will encounter any issues with the
274.44 -> new version we can quickly switch back
276.6 -> to the blue environment effectively
278.58 -> rolling back the previous version
281.28 -> while blue green deployment allows for
283.74 -> seamless transitions for an easy
285.54 -> rollbacks there's a catch
288 -> just like the rolling deployment we can
290.4 -> direct the new version to specific users
292.68 -> the switch from blue to green happens
295.259 -> for all users at once
297.9 -> it is also resource intensive
300.02 -> maintaining two identical production
302.34 -> environments doubles the infrastructure
304.919 -> and resource needs
306.9 -> we could spin down the idle environment
308.94 -> between deployments but this
310.68 -> reintroduces complexity
313.02 -> managing two parallel production
314.94 -> environments and ensuring seamless data
317.34 -> synchronization can add significant
319.62 -> complexity to the deployment process it
322.56 -> requires sophisticated infrastructure
324.479 -> management and tooling
326.58 -> however with its high level of control
329.1 -> and minimized risk blue green deployment
331.979 -> remains a popular strategy for smooth
334.5 -> user experience and reliable rollbacks
338.58 -> next up is Canary deployment named after
341.759 -> the HDO practice of using canaries in
344.4 -> Coal Mines to detect dangerous gases
347.52 -> if the canary was in distress miners
350.46 -> knew it was time to evacuate
352.86 -> similarly in software deployment we use
356.1 -> this strategy to test our air before the
358.68 -> full-scale rollout
360.72 -> here's how it goes instead of deploying
363.06 -> the new version to all servers or users
365.639 -> we choose a small subset our canaries it
369.479 -> can be a percentage of servers or group
371.699 -> of users
373.08 -> often selected based on certain criteria
376.38 -> for example we may start by deploying to
379.08 -> a single server or a small cluster or
382.319 -> even a certain geographical location
384.08 -> this allows us to monitor the
386.58 -> performance of the new version and the
388.62 -> real world conditions but on a much
390.78 -> smaller scale
392.22 -> if everything goes well and our new
394.319 -> version performs as expected we can
396.66 -> gradually roll it out to the rest of the
398.639 -> servers or users
400.38 -> but if something goes wrong we've got a
403.259 -> safety net we can hold the deployment
405.6 -> fix the issues and try again all without
408.9 -> impacting the majority of our user base
411.84 -> this incremental approach give us both
414.36 -> safety and control
416.4 -> Canary deployment also give us the power
418.979 -> of targeted rollouts unlike rolling or
422.52 -> blue green deployments we can direct our
425.16 -> Canary based on user-specific criteria
427.919 -> like geographical location or device
430.38 -> type
431.699 -> however Canary deployment does come with
434.639 -> its own set of challenges it requires
437.28 -> careful monitoring and automated testing
440.16 -> for the canaries it requires somewhat
443.099 -> complicated infrastructure tooling to
445.56 -> ramp up or hold the deployment as needed
448.62 -> the strategy can be complex to implement
451.08 -> and manage especially when dealing with
453.479 -> database schema changes or API
456 -> compatibility issues
458.099 -> Canary deployment is usually not a
460.319 -> standalone strategy it's often combined
462.78 -> with rolling deployment to create an
464.88 -> approach that brings together the best
467.099 -> of both worlds
469.62 -> finally as a bonus strategy we have
472.5 -> feature toggle it stands a bit apart
475.259 -> from the other strategies we've
477.12 -> discussed it's not about deploying a new
479.699 -> version of the entire application but
482.16 -> rather about managing specific new
484.139 -> features within the application
486.84 -> with feature toggle we introduce a
489.3 -> toggle or switch in the code for new
491.94 -> features this allows us to turn the
494.4 -> feature on or off for certain users or
497.039 -> circumstances
498.419 -> think of it as a gate that we can open
500.759 -> or close it controls who gets to see the
503.879 -> new feature
505.319 -> feature toggle can be used in
507.18 -> combination with any of the deployment
508.919 -> strategies we've discussed let's say
511.56 -> we're doing a canary deployment we can
514.26 -> turn on the feature toggle for just the
516.18 -> canary users letting them test out the
519.06 -> new feature while the rest of the user
521.219 -> base carries on with the current version
524.76 -> future tacos offers excellent control
527.22 -> over new features and allow for targeted
530.16 -> user testing it's great for a b testing
533.279 -> or gradually rolling out a feature to
536.04 -> see how it performs
538.26 -> however feature toggle
540.66 -> has its down size if not managed
543.24 -> properly toggles can add complexity to
545.94 -> the code base and make testing more
547.98 -> difficult
549 -> o or obsolete toggles need to be cleaned
551.82 -> up to prevent toggle debt which can make
554.76 -> the system increasingly hard to maintain
558.12 -> so there you have it five deployment
560.399 -> strategies each with their strengths
562.74 -> challenges and use cases
565.68 -> remember the best strategy depends on
568.26 -> the application's characteristics and
570.42 -> the user's expectations
572.519 -> now it's over to you which deployment
575.16 -> strategy have you used what works best
577.5 -> for your team let's discuss in the
579.779 -> comments below
581.88 -> if you like our videos you may like our
584.339 -> system design newsletter as well it
586.68 -> covers topics and Trends in large-scale
589.019 -> system design trusted by 400 000 readers
592.519 -> subscribe that blog.bygo.com
Source: https://www.youtube.com/watch?v=AWVTKBUnoIg