Apps require updating. The implementation of a new version is accompanied by challenges such as the possibility of downtime or incidents resulting in ineffective implementation. Unplanned downtime is one of the most unnerving types of failure that customers complain about. In this article, we show how to minimize the number of errors, both human and process, resulting in effective and repeatable implementation, in order to avoid application downtime.
What are the business goals of the implementation?
Depending on the assumed business goal, we deal with different types of implementations. One of them is to introduce changes without unnecessary downtime. Another may be the need to transform within the environment or a subset of users. Whatever your goal, the first step is to define an implementation strategy.
Application deployment strategies to avoid downtime
The launch of a new service is often separated from the fact that it is made available to users. However, in the case of services implemented in the in-place model, both deployment and provisioning take place simultaneously. This means that as soon as a new version is implemented, it begins to accept production traffic.
It is also possible to implement and share multiple versions of the service in parallel, which is where it comes in handy Kubernetes. We can also use three basic patterns for implementing new applications, which will ensure flexibility and the appropriate level of automation. The tools available within the framework will help us with Google Cloud, such as, among others, Load Balancer.
Recreate deployment pattern
Using the recreated deployment pattern, you can completely scale up the current version of your application. To deploy version 2, you must first scale the existing replicas of version 1 to zero, and then you deploy these replicas along with the new version of the application.
This model, characterized by simplicity, means that you do not have to manage more than one version of the application in parallel. This avoids problems related to backward compatibility of data and applications. However, choosing this method may result in downtime. While this is not a major issue for solutions that have scheduled maintenance outages, mission-critical services with high service level agreements (SLAs) as well as availability requirements will require a different way to implement changes.
Benefits of restorative implementation:
- simplicity,
- managing one application version at a time,
- avoiding data and application backward compatibility challenges.
Rolling update deployment pattern
The solution to the problem discussed above may be to choose a rolling deployment pattern. In this case, instead of updating each application instance simultaneously, a subset of the running instances are updated.
This method allows for gradual rolling of the application. The number of instances that update simultaneously is called window size. For larger clusters, it is necessary to increase the window size.
The rolling deployment pattern allows you to have more flexibility in how you make updates. You can choose whether you prefer to scale up the new application instance before you scale down the old application instance. On the other hand, you are able to specify the maximum number of application instances that will remain unavailable when scaling up new instances in parallel.
With this method, you can avoid application downtime. Based on the window size, you can choose a “one by one” or “two by two” deployment model. Traffic to updated destinations is only directed when the entire application is ready. Another benefit is the fact that any irregularities in the operation of the new version of the application will not be global – they may only affect some users.
Disable new replicas
If it turns out that the application is not stable after implementation, it is possible to disable new replicas and implement the old version (slow rollback). In this case, however, it is worth remembering that it is a gradual, incremental process, similar in structure to implementing a new version.
Note that when you choose the rolling deployment pattern, both the new and old code run side by side. This means that users can be arbitrarily directed to one of these versions. So you need to be sure that the new implementation is compatible with the previous one. In other words, the new application should read and handle data that the old version had access to. Both those located on disk, in the database or saved in the user’s browser session.
If the application requires session preservation, a load balancer that supports “sticky session” and “connection draining” can help. Additionally, it is recommended to implement session sharing in the application whenever possible, e.g. using a NoSQL database such as Datastore, this will allow you to separate the session from the application resources.
Benefits of rolling implementation:
- no downtime,
- lower implementation risk,
- easy restoration of the previous version – slow rollback.
Blue/green deployment pattern
This model assumes two identical implementations. The diagram marked in blue in the figure shows the current version of the application, while the green one is the new version. At the initial stage, only the first version is available and traffic is directed to it. In the meantime, we are implementing and testing the green version. When the tests are successful, traffic is redirected to the new version.
If you choose this deployment path, you can also keep the old version, leaving you with the option to roll back in the future. You can also remove it. Another option is to use the blue environment to deploy another version in the future. In this case, the areas marked in green will act as the current version, and the blue ones will become the new, tested and implemented solution.
Faster rollback
Similarly to the rolling pattern, we avoid downtime in the application. However, in case of problems and the need to recreate a previous version, rolleback is much faster. It comes down to the time needed to redirect traffic from the green environment to the blue environment. The use of environmental separation has another advantage – running the green implementation in parallel will not affect the resources serving the blue environment.
However, the choice of this variant is associated with the generation of higher operational costs, as it forces the maintenance of duplicate environments with identical infrastructure.
While switching between versions of the environment is not a problem in terms of duration, it is necessary to meet one additional condition – making sure that both versions can use the datastore database schema and its data. In this case, backward compatibility is necessary to seamlessly switch between versions.
Benefits of implementing blue-green:
- no downtime,
- easy and quick restoration of the previous version – instant rollback.
- separation of environments.
Seamlessly update your apps with a Google Cloud partner
On the way to increasing application performance, you may encounter a number of obstacles, dead ends and shortcuts that can ultimately increase your operational costs. To avoid this, it is worth using professional help from a Google Cloud partner, which will guide you through the entire update process. At FOTC, we have knowledge and experience supported by numerous certificates, such as: Cloud Engineer or Cloud Architect.
Contact us – we will help you choose the most effective solution
We can help you build and develop cloud products, effectively using Google Cloud resources and reducing costs as much as possible. We will talk about the characteristics of your application and choose the most optimal update pattern in order to minimize application downtime.
