The History of Canaries in the Cloud

Since there have been computer networks – which is to say, since the debut of ARPANET in
1969 – there have been network reliability problems. Finding those problems before they impact
end-users has long been a priority of any organization seeking to deliver an excellent user
experience and make good on service level agreements (SLAs).

One of the simplest and most effective ways to do that is to leverage what’s known as canary
applications. By providing a fast and easy means of testing whether applications are able to
connect and exchange data as expected, canary apps help teams detect potential points of
failure rapidly, no matter how complex the network architecture they are working with happens
to be.

Keep reading for a look at what canary apps are, why they are important in the history of
networking and the cloud, and how they’re poised to grow even more crucial as network and
cloud architectures increase in complexity.

What Are Canary Applications?

Canary applications are simple apps that service providers and their customers can use to
simulate production workloads. The goal of canary applications is to test whether key
functionality works as required within a production environment. However, because canary
applications aren’t actually production apps, they are simpler to deploy, and if they crash, they
don’t bring the whole production environment down with them.

With canary applications, teams can easily validate whether applications process requests in
the time period required by an SLA, for example, or whether changes to a network’s
configuration cause a slowdown in traffic flows.

In case it’s not obvious, canary applications are so-named because they are like canaries in a
coal mine: just as miners in years past relied on canaries as an early warning system against
toxic gasses that could build up underground, modern businesses can leverage canary apps to
alert them quickly to problems. In turn, businesses can react by fixing the problems before they
escalate and create serious disruptions.

How Do Canary Apps Work?

To deploy a canary app, you first create a simple application using a language like Python or
Java that performs the key functionality you want to test. Then, you package and run the app.
Once it’s running, you watch and wait, checking whether the app does the things it is supposed
to do.

For example, if you want to test whether your app can send and receive traffic on a certain port,
you could toss together a Python script that sends packets on that port, and then package it
inside a container. From there, you’d deploy the container into your production environment.
Using network monitoring tools and/or data logged by the app, you can confirm that packets are
properly sent and received on the appropriate port.

This is a simplistic example. A real canary app might do more than just send a few packets; it
would allow you to validate that all key aspects of application functionality – deployment,
opening up a connection, sending and receiving traffic, closing a connection, and then repeating
as necessary – work properly.

Canary Apps vs. Canary Deployments

Importantly, canary applications are different from canary deployments, although both concepts
are related.

A canary deployment is a type of software release strategy in which some users receive access
to the production version of a new application release before others. The idea behind canary
deployments is that the users who get early access function as canaries; if they experience
problems, developers and IT engineers can fix them before rolling out the new release to all
users.

In contrast, a canary application isn’t a production application (although it runs in the same
environment as production apps) and it’s not directly exposed to end-users. Instead, the
purpose of a canary app is to give IT operations teams the ability to discover potential problems
by detecting issues with the canary app instead of production apps. If some part of the canary
app fails, it’s likely that equivalent functionality in the actual production app will also fail, so
engineers will know that they need to investigate and fix the issue before it impacts real end-
users.

Thus, while canary apps and canary deployments are both effective ways of catching problems
before they impact a large set of users, canary apps allow you to find and fix issues before
you’ve deployed an app to any users. In contrast, problems detected via a canary deployment
will impact some end-users – those who receive the canary release – even though not all of
your users will be affected.

Canary Apps in the Past, Present, and Future of the Cloud

The ability to validate whether applications and network connections work as expected is
valuable in any type of environment that involves a computer network. For that reason, as noted
above, service providers have long turned to canary apps to test networking configurations.

But with the advent of cloud computing, canary apps became even more valuable. In the cloud,
networking configurations tend to be more complex; it’s common to have many software-defined
virtual networks running on top of a physical network. In addition, your ability to monitor the
network directly may be limited in a cloud computing environment because you can’t access
physical network infrastructure. You can only test and monitor network behavior using
whichever tools and data sources your cloud provider supports.

In that context, canary apps are a great way of testing whether a cloud network works properly.
They don’t require any special monitoring tools, IAM configurations, or cloud services; all you
need in order to use a canary app is a simple app and a cloud environment to deploy it in.

In the future, canary apps are likely to become even more important because cloud networks
will grow even more complex. As more and more workloads shift into distributed, cloud-native
environments, organizations end up with yet more software-defined and overlay networks.
Canary apps offer a simple way of testing whether the network works as required in a cloud-
native environment: instead of sifting through reams of network logs and trying to puzzle out
how the network configuration actually works, you can simply deploy a canary app and see what
happens to check whether connections can open and packets can move as needed.

Conclusion

Cloud networks are complex, and they’re only going to get more complex as technologies
evolve. That’s why canary applications will remain a key resource for teams that need to verify
that network configurations support their workloads. Canary apps aren’t the only way to test and
monitor a cloud network, but they are arguably the simplest – and that feature makes them all
the more valuable in a world where taming complexity is often the top priority of developers and
IT teams.

 Chris Tozzi has worked as a Linux systems administrator and freelance writer with more than ten years of experience covering the tech industry, especially open source, DevOps, cloud native and security. He also teaches courses on the history and culture of technology at a major university in upstate New York.