Get Fine-Tuned Control of Your Akamai Configurations
This blog post will go over how you can migrate from advanced metadata to custom behaviors so you can directly manage and edit your configurations without going through Akamai professional services.
Akamai Edge servers are smart reverse proxies located at the edge of the Internet that you can leverage to deliver fast and high-quality content to your end-users. Two of the key benefits of using edge servers are:
Higher quality content thanks to various network optimizations like SureRoute, or advanced protocol optimizations
Faster content delivery thanks to low network latency and server-side content caching
Running edge computing functions closer to end-users can considerably improve the performance of your applications and reduce the load (and associated costs) of your origin infrastructure.
You can configure edge computing functions via three different technologies:
EdgeWorkers: pre-packaged JavaScript functions that are executed on Edge Servers
Edge Side Includes (ESI): a markup language similar to Apache Server Side Includes which allows you to assemble dynamic content at the Edge
Edge Metadata: a proprietary XML language that allows running pre-defined logic at the Edge. Note that you can also create Edge Metadata logic using JSON via the Akamai Property Manager API
You can enable most of these edge computing functions using Property Manager Behaviors (either via Control Center or via the Property Manager API).
The Property Manager API (and the Property Manager CLI package) allows you to manage Akamai properties as code using JSON instead of XML.
However “advanced metadata” can only be edited by Akamai professional services, therefore it is recommended to migrate “advanced metadata” code to JSON or custom behaviors in order to regain full control of the configuration.
Why migrate advanced metadata to custom behaviors?
While Advanced metadata is sometimes required to unlock advanced functionality, it can pose a management challenge because advanced metadata can only be added or edited by Akamai employees. For example, if you need to apply that samed advanced functionality to another property, then you would need to contact Akamai professional services to do that for you. The recommended solution is to migrate the “advanced” code to “custom” code, a one-time process that will help you regain control of your configurations that have “advanced” logic.
Advanced metadata can appear in a configuration in two different flavors:
Advanced Behaviors: snippets of advanced metadata XML code that are inserted within the rules of the configuration (see picture 1)
Advanced Override: a block of advanced metadata XML that is located at the very end of the configuration (see picture 2)
Advanced behaviors can be migrated to custom behaviors while advanced override would migrate to a custom override:
The migration from “advanced” to “custom” is a one-time process described below that needs to be done by an Akamai specialist within professional services and consists of “converting” the XML code into a format that is available to Akamai users.
How to migrate to custom behaviors and custom overrides
The following steps describe the prerequisites for migrating from Advanced metadata to custom metadata and how to contact an Akamai representative to complete the migration.
- Convert advanced behaviors to custom behaviors.
Open the property that contains the advanced metadata in Property Manager, and scroll down until you locate the “Advanced” behavior containing the code you want to migrate, and click the icon with a “+” to create a custom behavior. - Convert Advanced override to custom override
Navigate to the “Advanced Override” behavior which is on the left side of the screen. If it is present, it will always be the last rule. Click the wheel icon in order to create a custom override behavior. - Referencing custom behaviors and overrides
Once these behaviors have been created, they can be referenced. You can find all of your custom behaviors via the “Manage custom behaviors and overrides” button.The custom behavior id (highlighted below in green) can be used as reference in configurations through code.
Use APIs to migrate to custom behaviors and custom overrides
The UI is not the only method of doing this. We can also retrieve the behavior using APIs. Here is an example of a call made using HTTPie.
root@akamaidev:/$ http --print b --auth-type edgegrid --auth papi-ps: GET :/papi/v1/custom-behaviors
{
"accountId": "act_1-6JHGX",
"customBehaviors": {
"items": [
{
"approvedByUser": "jsikkela",
"behaviorId": "cbe_73905306",
"description": "AWS authentication v4",
"name": "AWS_Auth_v4",
"sharingLevel": "ACCOUNT",
"status": "ACTIVE",
"updatedByUser": "jsikkela",
"updatedDate": "2017-11-08T17:33:58Z",
….
{
"approvedByUser": "pmedrano@akamai.com",
"behaviorId": "cbe_194816106",
"description": "DNS freshness settings",
"name": "DNS freshness settings",
"sharingLevel": "ACCOUNT",
"status": "ACTIVE",
"updatedByUser": "rramnath",
"updatedDate": "2020-07-16T22:22:24Z",
"xml": "<network:dns.positive-min-ttl>2s</network:dns.positive-min-ttl>"
},
...
To get more details about the behavior, you can enter the following:
root@akamaidev:/$ http --print b --auth-type edgegrid --auth papi-ps: GET :/papi/v1/custom-behaviors/cbe_194816106
{
"accountId": "act_1-6JHGX",
"customBehaviors": {
"items": [
{
"approvedByUser": "pmedrano@akamai.com",
"behaviorId": "cbe_194816106",
"name": "DNS freshness settings",
"sharingLevel": "ACCOUNT",
"status": "ACTIVE",
"updatedByUser": "rramnath",
"updatedDate": "2020-07-16T22:22:24Z",
"xml": "<network:dns.positive-min-ttl>2s</network:dns.positive-min-ttl>"
}
]
}
}
The Property Manager configuration will look like this:
If you were to examine the JSON, you’d notice that it now references this behavior id instead of the XML.
This JSON fragment can be the starting point to update configs as necessary. The workflow would be to delete the advanced behaviors and then replace them with a custom behavior.
Updating custom behavior
Let's say that 6 months down the road, there are some changes required and we end up creating an updated behavior. We can manage this by code by replacing the custom behavior id (cbe_xxxx) in the JSON and pushing the changes live.
You might also like
Here are great resources you can read to learn more:
API Docs: Property Manager APIs
API Docs: Custom behaviors and overrides
Blog Post: 20 Years of Edge Computing
About the authors
Rajiv Ramnath is an Enterprise Architect at Akamai with 10 years of industry experience. Rajiv works with Akamai's largest web, media and gaming customers on some of the most complex and advanced integrations. He also provides technical consulting and training for Akamai customers. Previously, he used to work on low-level kernel development. In his spare time, he likes to read fiction. | |
Javier Garza is a developer evangelist at Akamai Technologies where he helps the largest companies on the internet run fast and secure apps by leveraging web performance, security, and DevOps best practices. Javier has written many articles on HTTP/2 and web performance, and is the co-author of the O’Reilly Book, Learning HTTP/2. In 2018, Javier spoke at more than 20 developer-related events around the world, including well-known conferences like Velocity, AWS Re:Invent, and PerfMatters. His life’s motto is: share what you learn, and learn what you don’t. In his free time he enjoys challenging workouts and volunteering for non-profits that support children and education. |