Edge Redirector Cloudlet Gets Faster

Written by Maksym Novoseltsev – Senior Software Engineer, and Jeffrey Costa – Senior Product Manager, Web Performance

Cloudlets Policy Manager often takes a long time to load, which is a by-product of its original design where every policy activation is an individual file. These files must be moved around the network, and as you might imagine, transferring thousands of files in a multi-tenant network can take a very long time. Add a synchronous API to this problem, and we quickly get into a situation where the Policy Manager UI can freeze until a back-end transfer operation times out.

This is the problem we set out to solve by creating a brand-new activation method for cloudlets. The first cloudlet to receive this new superpower is Edge Redirector, but other cloudlets will follow in succession as we move further into 2021. To better understand this change, it’s useful to take a step back and understand how the current (now “legacy”) method of policy activation works. 

Current policies require a two-way binding relationship with properties. This means that a policy needs to know about the relevant properties, while the property needs to know about policies. So each time you activate a policy, you activate it for only a specific set of properties. If you decide to reuse a policy in new property, that policy needs to be activated again. If you activate a policy for the first time, you need to add your property manually using the “Add Properties” field in the activation window. 

Property information is critical for the policy activation process as well. This information is very heavy to fetch, so this also slows down activations. Finally, the need to push the same number of files as the number of referenced properties slows down activation time. For example, if the same policy is used in 10 properties, we push 10 identical files over the network to edge servers. This incurs a large amount of overhead as more resources are used during activation.

This operation has now been replaced by something we call “Shared policy,” which breaks the need for a policy to know about the relevant properties during activation. This “single binding” means that only the property needs to know about the exact policy; the policy itself is shared across your Akamai account. Any property may begin using an active policy without additional actions. 

For the activation process, this means that we no longer require any property information in the activation process, so activations have become much faster. Of course, this also means that we push one file to the edge server (instead of many), irrespective of the number of properties that use the policy, which also improves activation time. In fact, the more properties that are referenced by a policy, the faster activation time becomes. For example, if we have a policy with more than 100 referenced properties, only a single configuration file is needed.

New API

In addition to these policy changes, we have also introduced a new API (v3) purpose-built to be used with Shared policy. This API is asynchronous, meaning that a request does not need to wait for a response before continuing. A sample of the resources available in the API is shown in the screen capture below:

 

This version is much more DevOps friendly. For example, note the new “Get an activation’s status” resource. Each activation request now returns an activation ID, which can be used to track activation status. There is also a dedicated endpoint, which may be used to query for activation status. This approach allows easy integration into your monitoring toolset. In contrast, the older v2 API does not have a means to check activation status — only a resource to list activation history.

Additionally, activation history is now more durable over time. In v2 of the API, activation history is reported per property and is mutable (changeable). So once a policy is deactivated on a property, all history of the activations for the given property is gone. If you wanted to understand if activation is complete in v2, you had to obtain all statuses for each referenced property historically. We understand this was suboptimal, and in v3 this capability was improved so that activation status is now a dedicated and immutable resource with single status.

Another important item is that the v3 API uses the same match rules format as the v2 API. In other words, match rules that you currently use in the v2 API are fully compatible with the v3 API. If you have any external tool to combine or build rules, you can continue using it without interruption. You simply create a new Shared policy using the existing match rules. To do this, retrieve the legacy policy version, extract match rules (in JSON format), and use it to create a new Shared policy.

There are some limitations as we roll out this new functionality. Most of these are temporary, but it’s worth calling them out:

1. There is not currently a way to get Property Manager properties where Shared policies are referenced. We are working on this, and it will be added ASAP.

2. Edge Redirector reports (unused rules and policy cost reports) are not yet available. We are working to enable this in Q1 2021.

3. Match rules resources are not yet available. 

Shared policy and the asynchronous API are not changes you see, but ones you can feel both in the responsiveness of the policy UI itself and the corresponding administrative API. These changes should also make it easier to use the new API with your own software to make cloudlet usage even more seamless. Look for more cloudlets to gain this functionality in the future!

*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Jeffrey Costa. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/vdmuGXGYb-4/edge-redirector-cloudlet-gets-faster.html