EIP – Detour

Post by: syed hussain in All Application Design Patterns Integration Design Patterns

Summary

Now, what is this “Detour” pattern all about? It’s essentially a rerouting exercise, not unlike the way you’d avoid a construction zone on your daily commute. In Azure terms, it’s about rerouting, intercepting, and transforming message flows across systems, generally used when you need to change behaviour without disturbing the underpinnings of your infrastructure. Handy, right?

Let’s unpack this integration pattern.

What’s the detour? And why do we need one?

In cloud architecture, everything is about integration. Applications don’t live in silos. They talk to each other constantly, across APIs, message brokers, or even raw HTTP connections. But what happens when you need to change one of these components without affecting the whole ecosystem? Do you tear it down and start again? Of course not. That’s where the Detour pattern steps in. Think of it as a way to temporarily redirect traffic (data) to an alternate route, giving you time to upgrade or modify your application without taking everything down.

In Azure, this sort of clever redirection often takes place using a combination of services like Azure API Management, Logic Apps, and Service Bus, providing flexible routing mechanisms.

Let’s walk through the steps of how a detour might be designed and implemented in Azure, shall we?

The fundamentals of the Detour pattern

At its heart, the Detour pattern is a circuit breaker for cloud-native architecture, but without the abruptness of failure. Rather than cutting something off, it reroutes. It might be used to redirect traffic temporarily to another service, maybe for testing purposes (an alternate API version, for example), or during a migration, ensuring no requests are lost in the shuffle.

For instance, let’s say you’re working with an API gateway that manages traffic to your various services. There’s an issue in one microservice, but you need it fixed without halting the entire production line. Detour would enable you to send requests to a substitute service or mock service temporarily, allowing you to deal with the issue without the entire system feeling the strain.

How? The usual suspects in the Azure lineup are the ones you’d lean on—API Management, Service Bus, Logic Apps, or even Event Grid, which handles routing at the event level.

Azure API Management – the frontman of detours

API Management is often the key to unlocking a proper detour. Imagine it’s the gatekeeper standing between the public and your system’s internal APIs. By implementing the detour pattern within Azure API Management, you have the ability to intercept incoming requests, redirect them to an alternative API or service, and perhaps even inject additional steps into the flow.

Let’s say an endpoint is overwhelmed, or a feature within it is outdated. Rather than allowing your service to be pummeled by requests, API Management lets you reroute the flow, saving you the nightmare of users experiencing downtime. Meanwhile, you work your magic behind the scenes, patching things up.

This pattern allows for graceful handling of issues like throttling, where rerouting part of the traffic to a mock endpoint buys you time. Alternatively, if a new service is undergoing a gradual rollout, the detour pattern lets you integrate the change without affecting the whole system.

In short: Azure API Management is the big redirection button, the lollipop lady stopping traffic while you rebuild part of the road. If you configure it properly with policies and rules, you can effectively insert and remove detours dynamically.

Logic Apps – weaving the detour

Where API Management does the bulk of the rerouting heavy lifting, Azure Logic Apps might be employed to handle the more complex orchestration tasks. You can think of Logic Apps as the back-end logistics manager, responsible for taking requests and distributing them to the right place.

So when you detour traffic, say, to a new version of your API, Logic Apps can sit in the middle and orchestrate which version gets called, managing the routing logic more intricately.

For example, Logic Apps could:

  • Route based on request metadata (headers, body content)
  • Apply transformations before passing data to the detour destination
  • Trigger the detour based on thresholds (e.g., too many failed requests)

By setting these parameters, Logic Apps becomes part of the detour orchestration, allowing for more refined control over how and when traffic gets rerouted. It’s this level of orchestration that makes the detour pattern not just about redirection, but also about providing agility.

Real-world scenarios where detours make a difference

Azure’s a vast ecosystem with no shortage of options for implementing this pattern, but the magic is in how this theory hits the real world. Consider these examples:

Version management – Introducing new versions

A classic detour use case is introducing new API versions. Instead of risking full-frontal deployment, why not integrate the detour pattern? In Azure API Management, you’d have the detour logic detect request versions. New requests get routed to your shiny new API, while others can take the old road until they catch up. The service continues without the users even noticing something changed, apart from that slight new feature they didn’t know they needed.

Service degradation

Say one of your microservices goes on a long lunch break (meaning: it’s down), the Detour pattern lets you direct traffic to either a backup or a cached version while repairs are in progress. In Azure, you might use Event Grid to trigger failover logic that starts rerouting messages in real-time, keeping the rest of your services humming along.

Feature toggles in production – Sneaky, sneaky updates

Here’s a fun one—let’s say you’re deploying a new feature, but you don’t want to announce it with brass bands just yet. Instead, you introduce it quietly, routing a percentage of your users to the new feature (testing without the fireworks).

This is called a Canary release. By applying the Detour pattern in Azure, you can use API Management to split your traffic based on user segments, directing a handful of them to the new feature while the rest stay blissfully unaware. This gives you the best of both worlds—gathering feedback and performance data while keeping the peace.

Benefits of Azure’s Detour pattern

Now, Azure is very much the perfect playground for this integration pattern. It’s got all the toys. But what does that mean for us in terms of practical benefits? Well:

  • No downtime: You can update, fix, or swap services in real-time without disturbing your users.
  • Flexible routing: Through Azure’s API Management and Logic Apps, you can set up dynamic routing that shifts on demand.
  • Easy testing: You can test new versions or features in a controlled manner without putting your whole system at risk.
  • Scalability: Whether you’re routing 100 or 10,000 requests, the cloud-based nature of Azure’s services ensures that it scales smoothly.

But like all things in cloud architecture, it comes at a price. It requires careful planning. If your detour setup has flaws—think of missing policies or improper traffic management—then you might find yourself in more of a detour than you intended.

APIM Detour Implementation

Right, let’s talk specifics—how do you implement the Detour pattern using Azure API Management (APIM)? Think of APIM as the savvy traffic cop standing at the busy intersection of your services, rerouting data flows with a confident wave of the hand. This pattern comes into play when you need to gracefully redirect traffic while making backend changes, updating APIs, or handling service failures.

Here’s a step-by-step on how to pull this off:

1. Set up Azure API Management instance

If you haven’t already done so, you’ll first need an Azure API Management instance up and running. It acts as a gateway to all your services, so requests flow through it first before hitting your actual back-end APIs.

  • In the Azure Portal, search for API Management and create a new instance.
  • Configure it by linking to the APIs you plan to manage or detour.

2. Create the APIs and define backends

Once your API Management instance is live, it’s time to define your backend APIs—the ones you’ll be redirecting traffic to or from.

  • Go to the APIs section in the APIM instance.
  • Add your API (or APIs) that need to be managed. This will be your primary API endpoint.
  • Define any alternative API versions that you might want to reroute traffic to during the detour.

For instance, if you have a legacy API (v1) and a new version (v2), both need to be registered as separate APIs within APIM.

3. Implement Policies for the Detour

Policies are where the magic happens. In Azure API Management, policies allow you to transform requests and responses, set up conditions for routing, and much more. This is the core of the Detour pattern—using policies to reroute traffic temporarily.

  • Navigate to the Design tab of your API.
  • Under Inbound Processing, you can insert custom policies. These policies control how requests are handled before they reach the backend.

Key policies for detour:

Redirect or rewrite URL policy: Use the rewrite-uri or set-backend-service policy to redirect traffic to another API or service.

<inbound> <base /> <set-backend-service base-url="https://new-api-version.com" /> </inbound>

This snippet reroutes all incoming requests to the new API version without changing the client’s original request.

Conditional Detour Policy: If you only want to detour a specific subset of requests (e.g., based on the user agent, geography, or query parameters), you can add conditions using the choose policy.

<inbound> <choose> <when condition="@(context.Request.Headers.GetValueOrDefault('User-Agent') == 'test-client')"> <set-backend-service base-url="https://new-api-version.com" /> </when> <otherwise> <set-backend-service base-url="https://original-api.com" /> </otherwise> </choose> </inbound>

Here, only users with the ‘test-client’ User-Agent will be detoured to the new API version, while others will continue to the original API.

Fault handling (mock response): If the destination API or service is down, you can provide a mock response instead of leaving users hanging.

<inbound> <base /> <retry condition="@(context.Response.StatusCode == 500)" count="3" interval="2s"/> <set-backend-service base-url="https://mock-service.com" /> </inbound>

This retry logic attempts to call the original service three times, and if it still fails, it reroutes to a mock service.

4. Testing the Detour in Azure API Management

Once you’ve set up the detour logic, you need to test it. APIM provides a built-in test console:

  • Navigate to the Test tab within your API.
  • Make a request through the APIM gateway, ensuring it triggers the detour policies you’ve created.
  • Check that the redirection is happening as expected by inspecting logs, response times, and the traffic flow.

5. Gradual Rollouts with Detour

Another common use of the detour pattern is for gradually rolling out new versions of an API, also known as a Canary deployment. This is especially useful when testing new features in production with a limited audience.

You can implement this in APIM using a percentage-based routing policy:

<inbound>
  <base />
  <choose>
    <when condition="@(context.Request.Headers.GetValueOrDefault('x-canary') == 'true')">
      <set-backend-service base-url="https://new-api-version.com" />
    </when>
    <otherwise>
      <set-backend-service base-url="https://original-api.com" />
    </otherwise>
  </choose>
</inbound>

Alternatively, if you want to gradually migrate a percentage of your traffic (say, 10%), you can use a simple random value condition:

<inbound>
  <choose>
    <when condition="@(new Random().Next(100) < 10)">
      <set-backend-service base-url="https://new-api-version.com" />
    </when>
    <otherwise>
      <set-backend-service base-url="https://original-api.com" />
    </otherwise>
  </choose>
</inbound>

This sends 10% of the traffic to the new API, giving you control over gradual rollouts and letting you collect real-world data before switching over entirely.

6. Monitoring and Logging

No detour implementation is complete without proper logging and monitoring. In Azure API Management, you can configure logging at various stages of the request lifecycle to capture information on how the detour is performing.

  • Use Azure Application Insights for tracking request and response data, errors, and performance metrics.
  • Set up Alerts to notify you if traffic spikes, or if detoured routes are failing, so you can intervene before things spiral.

7. Remove the Detour

Once your API or service is stable, and you no longer need the detour, removing it is as simple as changing or deleting the policies you implemented. The process is reversible, which means you can adapt quickly to new scenarios or challenges without needing to reconfigure your whole infrastructure.

Wrapping it up

Implementing the Detour pattern with Azure API Management is like performing controlled roadworks in the middle of traffic—everything keeps flowing smoothly, but you’re making adjustments and improvements on the fly. The flexibility of APIM policies lets you handle version management, failovers, and gradual rollouts without disrupting the rest of your infrastructure.

Tags:
29 Jun 2024
0