One of the primary objectives in moving to a DevOps culture is to increase the cadence of deployments to production, ideally moving much closer to a Continuous Delivery system – a DevOps practice of being so confident in the automated validation and deployment pipeline that any changes get pushed directly to production without any human intervention.
To achieve this type of speed of deployment several changes are involved:
- Trust in the validity of automation of the testing and deployment process
- Repeatability of the deployment process
- Reliable way of validating success of deployment
- Simple and reliable rollback process
There are several ways that DNS can be employed to deliver these objectives.
Traditionally, deployment of systems was done by installing new software over the top of the old software on the same hardware. Rollback was then completed (if necessary) by reinstalling the previous version or in worst case scenarios by restoring the entire server from a backup.
The issue with this approach is that over time, the state of the target machine will become less and less like that of the development and test machines. Development and test machines by their very nature are subject to more experimental and failed builds than production machines, all of which will leave artifacts such as updated system files or elements of the system not properly rolled back. This all leads to variants in behavior between what is seen in testing and in production.
What is preferable is that each release of the system is deployed onto a clean machine with a known base state. The infrastructure as code and automation defined above, combined with virtualization or cloud platforms make this a reality; with every new round of testing, a completely new test environment can be created and the previous one destroyed.
This pattern can also be applied to deployment. At deployment time a replacement environment is created alongside the existing environment. Traffic is then rerouted to use the new environment. If the system allows, this can be done gradually, allowing small amounts of traffic to use the new system while validation takes place. In the event of failure, traffic can just be redirected back to the old environment.
This process is referred to as blue/green deployment (or sometimes green/gray) to indicate that you have a live environment (green) and a production ready but offline (blue) environment.
There are several ways to manage the switch between the two platforms, but dynamic DNS is an excellent means as it is simple and requires no additional hardware within the environment.
After the new environment is created, the DNS records are switched to point to it instead of the old environment. Typically, this would be done as part of an automated process via the API provided by the DNS provider.
A reliable way to ensure that deployments are not introducing issues is to stage the rollout. This involves releasing the new version to a subset of users and monitoring those users to determine whether that release should be rolled out to the rest of the users (or to progressively larger groups of users).
Some companies use this method as a way of user testing new features to determine whether those features are popular with users. Known as A/B testing or multivariant testing, this is an increasingly popular way of determining whether or not features should be released.
There are network-based methods for managing a staged rollout of a system; for example, load balancers can be configured to route traffic to different systems.
However, DNS is a good solution to the problem as it removes the point of failure from within your network and allows for easier distribution across multiple data centers if required.
This can be managed in two ways. In the simplest example, your DNS provider could just be configured to send a set percentage of users to each system. For example, 10% could be sent to the new system, and the remainder of DNS queries will still resolve to the old system. Note that in this case it is important that your system be aware that individuals were previously on the new system and handle that appropriately.
More sophisticated DNS systems can handle this in slightly more elegant ways, such as segregating users by geographical area rather than at random.
Geographical region versus network topological region
When talking about resolving DNS by geographical region, it is actually based on internet network topology rather than geographical region. That is, it is based on the way that a connection is routed through the internet rather than its actual physical location. For simplicity though, let’s talk about routing traffic based on geographical location.
Splitting traffic in this way has several benefits:
- You can make a conscious decision about the users that you want to try out new features with, e.g., users who are less of a business risk or who have a particular relevance to the feature being rolled out.
- You can manage the support issues more proactively, having more awareness about which versions people are using if they contact you with issues.
- Multiple versions can be tested concurrently with different geographical regions.
The role DNS can play in helping you adopt a speedier deployment process is just one example of the impact this often overlooked protocol can have on your overall performance. For more checkout our ebook, “DevOps & DNS – Improving Web Application Performance at the DNS Layer.”