Resiliency through Cloud-Native Patterns

Application resiliency can be measured by how durable and recovery prone a service or application is. There are different paradigms for analyzing and implementing resiliency in applications, including infrastructure and software design patterns. For the purposes of this chapter, we’ll be examining software patterns that leverage cloud-first architectural patterns to bolster application resiliency.

While we can review the architectural patterns using the Azure architecture center as well as various sources for software resiliency, we’re going to be looking at a library that’s fairly prevalent, especially in cloud-first development circles. This library is called Polly. Polly is a library that allows us to implement several different types of policies in either a synchronous or asynchronous manner to address specific issues or to combat known problems with cloud service transiency, as well as advanced error handling techniques, such as the circuit breaker pattern.

To familiarize ourselves with Polly, let’s look at a simple example of how we can implement both a circuit breaker policy and a retry policy. Retry policies are one of the most common ways to establish resiliency because we can determine what actions to take after the retry count has been exceeded.

Patterns using Polly

As well as the retry and circuit breaker patterns, there are several other patterns that we can implement using Polly. These include the following:

• Bulkhead isolation: This pattern purposely restricts the number of resources available to a caller, as well as the number of requests that can be processed.

• Cache: This policy forces the method being executed to pull from the cache first. If the value doesn’t exist, it fetches it from the data store and puts it into the cache.

• Timeout: This guarantees a maximum time to wait. For example, a timeout policy set with a limit of five seconds will fail if the operation takes longer than five seconds.

• Fallback: This provides a way to return an alternative value for a method when the method call fails.

• Rate limit: Sometimes seen as throttling, this limits the frequency of consecutive requests from a caller by limiting the maximum threshold.

• PolicyWrap: This is a lightweight wrapper that allows us to combine multiple policies into one and execute them as a group.

It’s possible to group multiple policy implementations together using the PolicyWrap object. For example, we could group retry and fallback policies together to help a method retry its execution and return a default message upon failure. The fallback policy is somewhat like the circuit breaker in that an alternative message or function can be used to communicate success or failure. They differ, however, in that fallback policies could be executed many times and not halt traffic to a particular method call, whereas circuit breakers will halt traffic for a set period.

For the purposes of our example, we’re going to be using a simple example to make sure that we’re assigning a retry policy to a specific block of code. Once we’ve successfully added that code and tested it, we’ll move on to implementing a similar strategy in the sample application itself.

Note: We provide a coding playground with the required code changes later in this lesson.

You’re encouraged to follow along these instructions on your own machine:

1. To get started, we create a new project in Visual Studio. We can use a console app template, a web API or REST API template, or any other template of our choosing. We right-click on the project and select the “Manage Packages” option from the context menu. We’ll be installing Polly from NuGet.

2. Next, we’ll add a new class to the project that we’ve just created to house the logic we want to execute for the service. We can call this class anything we like; however, for this example, we name it ServiceBusinessLogic.

3. In the new class we’ve just created, let’s add a private variable of the AsyncPolicy type to hold a reference to our retry policy. In the class constructor, we can instantiate the AsyncPolicy object as follows: