Feature Toggle and Dark Release with Akamai

by Manuel Alvarez
259

Feature toggle is a technique that allows you to release functionality or modify system behavior without changing application code. This allows you to do “dark releases” where nobody, or only a select group of users, can access the new functionality in a production environment.

There are a number of reasons you’d want to do a dark release with Akamai instead of going live with the rest of your code:

  • Reduce risk: a dark release allows you test in a production environment without affecting customers.
  • Easy to implement: feature toggles are not always easy to implement. Akamai front-faces all your traffic and gives you the ability to match on almost anything from the incoming HTTP requests to client characteristics (device, location, etc.). Thus, you can define complex and unique matches without changing your code or infrastructure.
  • Integrability: Akamai APIs allow you to control the toggle from your CI/CD tool.
  • Control: Akamai’s roles and user permissions control who has access to modify configurations. You can limit or open configuration changes grants to fit your organization needs.
  • Visibility: new functionality is always launched with high hopes… and a nagging worry that something won’t work as expected. You can add a new Content Provider (CP) Code under the same match as your feature, which will help you track traffic and find problems as they arise.
  • Alerts: By adding a new CP Code you can set up origin alerts that will notify you of errors, such as time outs or error responses reaching a defined threshold.

Feature flags are common in CI/CD schemes where features are constantly deployed but not necessarily “released” in production. There are a few different ways to leverage your CDN for feature toggle, which I’ll outline here for you.

Using New URL Paths or APIs

If the feature you’re releasing lives in a new URL path, the best option is launch a hidden page. I recently blogged about launching a hidden page using Visitor Prioritization (VP) or API Prioritization, and you can get details in that post on Black Friday Readiness. But the gist of it is that since VP changes are instantaneous, you can hide the URL path until you are ready to release it. VP lets you control how many users have access to the feature, and you have several options on what response to serve in the meantime. For example, you could redirect them to the home page or API catalog.

Another advantage of this approach is that VP has built-in features that allow you to split traffic by user location data, percentage, cookie, query strings, filename, path, IP/CIDR, and even protocol. Furthermore, VP’s API commands allow you to integrate with your release pipeline.

Visitor Prioritization is a great tool, and we charge a monthly fee for it. If you need a free solution, there are still other ways to toggle functionality and accomplish dark releases, which I’ll go into next.

Using Embedded Features

If you can’t match on URL patterns, the next best option is to identify new features in the metadata, because in many cases a new feature also requires metadata changes. For example, migration to a new CMS or technology stack most likely requires an update of the origin settings in your configuration.

My recommendation is to define a variable with a default value of FALSE and wrap the new behavior(s) inside a variable match. You can then turn this variable ON for testers or other stakeholders (using a secret cookie or IP ACL) and start doing regression, capacity, and feature capabilities test in a production environment.

You can use this technique to create multiple toggles. To release a dark feature, simply push a new version of the configuration with the variable set to TRUE.

Automating with PAPI

Logging into the Luna portal to manually change a variable might work for some organizations, but you’re better off doing this in code. After all, a key principle of DevOps is to make your organization more agile and simplify processes, and removing manual processes is certainly part of that. In this section I’ll explain how you can automate this process using the Property Manager API (PAPI).

First you’ll need to get your configuration.json file. Use the following, but replace with your information:

Edit configuration.json appropriately. The snippet of JSON that defines/update variables is the following:

Now you can make a request to update the configuration version:

Hitting a Planned Release Time

If you have a planned release time, you can add a time match to automatically release it. In this example I’ll use PAPI again to add this behavior.

The snippet of JSON you’ll need looks like the one below. In this case I am enabling Brotli and setting a TTL of 15 seconds.

Designing with Akamai in Mind

I hope this helps you think about your release strategy and how Akamai fits into a bigger picture of DevOps. Picturing how this might look further down the road, a mature design pattern could be to release new features under a new endpoint (URL) and use Akamai to proxy the old, SEO-friendly path to the new feature path. Using variables, as described above, you could then control who get access to the new features, and when.

Categories: DevOps How To

Suggested Article