To enable daytime deployments, we regularly perform zero-downtime deployments.
Understanding the Impact of Downtime on User Experience
Whether it is scheduled or not, downtime is bad. Users are annoyed when they visit a website to finish a task but are unable to do so because it is unavailable. It doesn't really matter if the website displayed a charming banner alerting you to the outage a week beforehand. You cannot finish your mission, banner or not. In light of this, allow me to introduce you to Diana, a fictitious Australian user of our goods. Let's examine in detail how someone who is in a different time zone than our US-based personnel is affected by planned downtime.
It is a common procedure to deploy changes with downtime during "off-hours." By creating downtime during periods of reduced traffic, it lessens the impact on your users. But there are no "off-hours" when your product is in use all over the world. Diana's workday is her "off-hours" in the United States. Let's go over some crucial zero downtime deployment concerns and their significance while keeping Diana in mind. Globally, consumers anticipate little to no downtime for the goods they depend on and pay for. Additionally, we are aware that teams that deploy frequently and steadily produce better products. Engineers who deploy throughout the day report higher job satisfaction because it promotes a better work/life balance.
Let's define deployments with zero downtime. Ideally, clients aren't affected and are unaware that a new code version has been implemented. Rolling disruptions for certain services, such as making a user reauthenticate or making a function unavailable to a group of users, are the next best alternative. It's an intriguing idea during the day, especially for workers who are dispersed around the world. Day means exactly the opposite thing to Diana than it does to an employee who works in the US. In light of this, it's useful to define "day" as the team responsible for the deployment's working hours.
All of this sounds fantastic, but we're not quite there yet, you may be thinking. No issue, little steps toward deployments with no downtime are also very beneficial!
Exploring Strategies for Achieving Zero Downtime Deployments
List all of the possible approaches and configurations that can bring you there. For instance, does a certain portion of your app crash with each deployment? If so, is it possible to isolate it such that it crashes only when you alter its features and not the app itself? Monitoring the amount of downtime that each deployment requires on a regular basis is one of the greatest places to start. Is there a specific method that requires less time? Are there any steps that could be skipped or completed in advance? Use your imagination to plan out your deployment from beginning to end. Additionally, you can examine user behavior to determine when your software is most rarely used.
Maximizing Efficiency while Minimizing Disruption
Use caution when using this strategy as it could infuriate even more Dianas. There are situations when you can take advantage of time disparities. For instance, in Australia and other surrounding countries, Fridays are actually Saturdays. Any decrease in downtime is a significant step forward for the engineers developing the product as well as for your customers. Deployments during "off-hours" may be a viable solution, but they can also exacerbate engineer burnout and drive away customers who are located in different time zones. Even if you're not quite at zero downtime during daytime deployments, your team and users will be grateful for any advancements you make!
0 Comments