Every day, DevOps engineers face the challenging task of keeping their environments highly available. Availability becomes an even bigger challenge with large, complex infrastructures. Worse, it is often the case that the larger and more complex the infrastructure, the more likely it is to host mission-critical applications and other resources that demand 100% uptime.
Beyond everyday troubleshooting, a major obstacle to high availability is the continual need to make changes to the production environment, such as security updates, bug fixes, and the release of new functionality and features. When it comes time to put changes into production, minimizing downtime is both extremely important and, more often than not, very difficult.
It is always easiest to test changes on an environment that is close to production as possible. A common approach is to create a new, similar test environment. However, even with the closest possible replication, there may be small, yet critical, differences from the production environment. These small differences often lead to larger, unanticipated problems when the changes are pushed into production, which can ultimately lead to downtime, server rollbacks, and a restart of the whole process.
However, if you include anycast as part of your network infrastructure, you can dramatically reduce testing time and eliminate many “surprise” issues after code is put into production. With anycast, one more or clusters of servers can “sit” behind one IP address, announced upstream from your internal networks.
After updating BGP to remove one or more servers, users will be seamlessly rerouted to the available servers. Then, you can pull code into and run tests against the servers that are no longer being announced – eliminating the need to create a separate test environment. By testing on a production environment that is simply not being announced, the results from tests run against the environment will be much more accurate.
When the tests are complete, and the environment is ready to put back online, you can use BGP announcements to follow any deployment model that works for your business.
You can also use BGP announcements to facilitate a blue-green deployment. In this approach, you first stop announcing the cluster you have designated as blue, and deploy and test your changes to that environment. When the process is complete, you simply re-announce the blue cluster and stop announcing the green-designated cluster. When the green cluster is finished with testing and updating, you update the BGP announcement a final time so all servers become available for incoming traffic.
Using anycast in this way can help meet an often elusive goal for DevOps engineers: testing on an environment that is as similar to production as possible. By being able to selectively take clusters offline via an upstream BGP announcement, you can pull code and run tests against the actual production environment without any effects to the live service. Because this is done at the network level, your application-level services don’t have to handle keeping the environment available during upgrades and maintenance. Additionally, you can use anycast to streamline both canary and blue-green deployments, as well as any other custom deployment that works best for your business.
To learn more about our anycast technology, we invite you to contact a Solution Specialist today by filling out our contact form or by calling 1.800.419.COLO (2656).