Decoupling Deployment from Release using Dynamic Routing and Feature Toggling
To learn more about selecting an API Gateway and testing, check out the other articles in this series, “Selecting an API Gateway for Continuous Delivery of Cloud Native Applications” and “Next-Level Testing with an API Gateway and Continuous Delivery”.
It is considered best practice within the continuous delivery community to decouple deployment from release. The term “deployment” refers to the act of deploying a change to application components or infrastructure, and the term “release” refers to the act of enabling or exposing a feature to end-users (with a corresponding business impact). An API gateway can help with this in primarily two ways: smart routing (a.k.a. “dynamic routing”), and feature flagging (a.k.a “feature toggling”).
What is Dynamic Routing?
Dynamic routing is the process of dynamically routing traffic based on certain properties — in the case of an API gateway; this could be a user identify, a (geolocated) IP address, or the device type making the request. Implementing dynamic routing can enable:
Blue/green releases, where traffic is switched from one (blue) environment to another (green).
Canary releases, where a small amount of traffic is routed to the newly “released” service. Canaries are a small amount of traffic that is routed to newly-released services. The canary release system increases availability for critical applications and helps prevent defects from going unnoticed long enough before they affect end users, which means more reliable website experiences throughout the entire ecosystem.
Incremental rollout, which is a logical extension to canary releasing, where all traffic is gradually routed to the new service over time. Moving forward with a phased approach can result in less risk and give you time to react if anything goes wrong. This is because it’s only the new service that will be gradually introduced over time, instead of having all traffic redirected at once like an initial launch would do. For example: If we were planning on launching two different apps next week but one requires more work than another then using incremental rollout could really help us avoid problems by releasing just 1/2 or 3rd onto each app depending what needs done first before proceeding fully into its own segmentation strategy.
The benefits of all these techniques are fully realized with an effective monitoring solution — particularly if this is integrated within the gateway — as any deviation in operational or business metrics can trigger the halt of a rollout, and potentially even trigger a rollback. Netflix, in combination with Google, have talked about their canarying tool “Kayenta”, which has been integrated with Spinnaker
What is Feature Flagging?
Feature flagging is the ability to “toggle” parts of your application on and off. Feature Flagging is a powerful way to enable and disable parts of your application with the click or tap. It’s great for testing new features, experiment on different versions without committing changes into production if they don’t work out as planned.
It also enables you to make backwards compatible updates by turning off old ones so users can continue using them while newer features are added over time.
How to implement Feature Flagging to a Gateway?
Feature flagging can be implemented by adding filters or “plugins” to a gateway that can modify request header metadata. This metadata can be used to determine which services to call and what data to transform with a gateway. And can also be inspected within an application or service further down in the call stack to provide fine-grained control of the exposed functionality.
Flickr and Etsy have talked extensively about their use of these techniques, and the ever-generous Netflix team have created some fantastic content about how they run experiments, A/B test and even canary test using this technique.
Watch for Coupling!
One word of caution I am keen to offer here relates to coupling. When working with flexible API Gateways like Zuul, which allow the dynamic injection of scripts at runtime to alter routing and request/response data transformation, it can be tempting to introduce business logic into the gateway — accidentally or otherwise. However, with great power comes great responsibility. Although this can be beneficial for (niche) use cases, the coupling and lack of cohesion introduced by spreading business logic between a service and gateway make the continuous delivery of features more challenging. simply because of the additional moving parts and coordination and orchestration required between them.
The first part of this series, “Selecting an API Gateway for Continuous Delivery of Cloud Native Applications” covers the important features you should consider when choosing an API Gateway. The second part of this series, “Next-Level Testing with an API Gateway and Continuous Delivery” discusses the best ways to learn how your service will perform under realistic use cases, load and failure scenarios.
If you would like to know more about how the open source Ambassador Edge Stack API gateway can help you with implementing these patterns (particularly with continuous delivery), then check out the docs or Join Ambassador Labs Community on Slack.
