Maintaining and updating WebRTC applications is complex, involving frequent updates to libraries and infrastructure components to keep them secure and efficient. Canary releases provide a strategic way to handle these updates with minimal risk. By deploying changes to a small group of users initially, developers can monitor the new version’s performance and address any issues before a full rollout. 

In this post, we describe how canary releases are particularly beneficial for updating WebRTC applications, why using Amazon Route 53 is an effective tool for this, how to implement it, and important considerations to keep in mind during the process.

The Challenges of Maintaining WebRTC Applications

The process of building and launching any software product is complex, and WebRTC applications are no exception. Once the application is live and users start engaging with it, a new challenge arises: keeping it maintained and up to date.

As application usage grows, the need to evolve becomes evident, whether through adding new features or fixing previously unidentified issues. 

• Third-party libraries become outdated, leading to a lack of new functionalities and the emergence of security vulnerabilities. 
• Infrastructure components like operating systems and dependencies constantly change, requiring regular updates and maintenance to ensure the application’s stability and security.

Therefore, it’s critically important that companies allocate resources to keep both the applications and their components up to date. Unlike the initial development phase, updates now need to be implemented in a way that doesn’t disrupt the user experience. It’s crucial to monitor the application closely after such updates to ensure that these changes do not negatively impact users.

Enter The Canary Release

A “canary release” deployment strategy involves gradually rolling out a new software version to a small subset of users before deploying it across the entire system. This method mitigates the risks associated with full-scale releases by initially exposing only a limited segment of the user base to potential issues, while the rest continue with the previous well-working version.

There are different approaches for selecting which users get the new version first, such as using a random sample, targeting internal employees, or selecting based on specific user demographics. 

If the initial rollout is successful, it is progressively expanded to more users, allowing for close monitoring and quick rollback if problems arise. This controlled and reversible approach to updating software is particularly beneficial for legacy systems and large-scale distributed environments.

Canary releases also help in collecting performance metrics and assessing the system’s impact in real-time without creating a separate testing environment​.

Implementing Canary Release Using Amazon Route53

Amazon Route 53 makes implementing a canary release very straightforward by allowing you to assign weighted policies to DNS records. For example, you can start by routing 90% of your application traffic to the stable version while directing 10% to the new version. As you confirm that the new version performs well, you can gradually increase its traffic share until all users are transitioned to the updated version. 

Let’s see how to do this through an example.

Prerequisites

• An Amazon Route53 Hosted Zone that manages your application’s DNS records.
• Deployed application versions (primary and canary).

Creating Weighted Policies

Let’s assume that your application is available at app.example.com and that DNS records are managed in the example.com Hosted Zone. The primary, or current version runs in an EC2 instance with IP address 1.2.3.4, and the canary one is available in a different instance with IP address 4.3.2.1.

Next, all you need to do is to create the DNS records in the Hosted Zone using a weighted routing policy as follows:

• Record name: the application subdomain, i.e. app.example.com
• Record type: the type of record. Since we’re pointing to IP addresses, we choose an A record.
• Value: The IP address of each EC2 instance.
• Routing policy: We select “Weighted”.
• Weight: The priority of this record. This will be used in conjunction with the values of the other records to decide the proportion of users that will be routed to it.
• Record ID: an identifier for the record.

For this example, we need two records: one for primary and another one for canary version. Each record will point to the corresponding IP address of the application server and include a weight and a unique record identifier. The key element here is the weight setting, which determines the distribution of traffic between the two versions, as shown below.

Important Considerations for Canary Releases in WebRTC Apps 

When implementing any canary release, it’s crucial to remember that both the current and new versions of the application will run concurrently, with users accessing them simultaneously. To ensure a seamless experience, both versions must share the same application state and dependencies.

For WebRTC applications, this involves storing crucial data, such as session information, signaling, and ICE candidates, outside the application’s runtime environment. AWS services like Relational Database Service (RDS) or Amazon ElastiCache can provide the necessary storage solutions, enabling both versions of the application to access and update shared states consistently.

For features that require file access, such as attachments and file sharing, ensure that these files are available to every instance of the application. Using AWS services like S3 (Simple Storage Service) and Elastic File System (EFS) can facilitate this. These services allow you to store files centrally, making them accessible to both the primary and canary versions.

Lastly, it’s essential to manage changes in a way that maintains backward compatibility. For example, if the canary version introduces a new codec or functionality not present in the primary version, you should implement a fallback mechanism. This ensures that users routed to the primary version can still interact with those using the canary version without issues.

Each of these considerations is critical to ensuring that the introduction of new features or updates does not disrupt the user experience and that the system remains robust and reliable during the canary release process.

Minimize the Risk and Maximize the Stability of your Deployments

Implementing canary releases with Amazon Route 53 allows you to update your WebRTC applications smoothly and with reduced risk. By incrementally rolling out changes and closely monitoring their impact, you can maintain high availability and performance while introducing new features. This approach ensures your application remains robust and responsive, delivering a consistent and reliable experience for all users.

Looking to streamline updates using canary release, or enhance your real-time communication application overall? At WebRTC.ventures, we specialize in building robust WebRTC solutions. Our team of experts can help you manage updates effectively and ensure top-notch performance. Contact us today to elevate your project and deliver an outstanding user experience. Let’s make it live!