Planning a DevOps Strategy

by Akshay Ranganath
1120

We’ve had a lot of interest from Akamai customers asking about the ability to be “DevOps friendly.” Until recently, we haven’t talked enough about how to integrate Akamai into your DevOps or CI/CD workflows. The pieces to the puzzle are all there, however.

If you haven’t seen Akamai for DevOps yet, check out our latest initiative to support customers DevOps Journey. There will be a number of features that will be released for Akamai for DevOps in the coming months, but key pieces, for example the Akamai CLI, just came out.

In our post on Akamai for DevOps Usecases, our developer evangelist, Davey Shafik, outlined some really good starting points for DevOps scenarios. However, getting the ball rolling can be difficult at first. This post gives an idea on of how our Professional Services team designed a DevOps solution for a customer that you can use as a template for your own initiative.

Customer Requirements

Let’s walk through the requirement and the thought process and requirements. The customer is a large retail business with the following setup:

  • Multiple configurations for Dev, QA and Production, causing a waste of effort.
  • Error-prone processes including manually copying and pasting.
  • A bottleneck for some development efforts with Akamai.

To mitigate this, they wanted Akamai to become more DevOps friendly. From their perspective, that meant:

  • An agile delivery model where multiple changes can co-exist.
  • The ability to easily add and test new features and business logic in fresh environments.
  • Easy migration to QA and Prod environments.

Our Proposed Solution

To help the customer with a solution, we agreed to build a new delivery model. In this model, we’d do the following:

  • Build and deliver a simplified master configuration.
    • Replace environment-specific hard-coded values with variables.
    • Extensively use Property Manager variables to make code flexible.
    • Refactor as much advanced code as possible.
    • Eliminate rules that are old.
  • Design a solution based on master config, GIT, and a build script.
  • Use the master config for all changes. Using the build script, the configuration can then be built for the correct environment.

Given this scenario, we’d build foundational scripts to pull the master config with Property Manager API (PAPI), run a build script to create the right config for different environments, and then push/activate with PAPI. It looked like this:

Now it looks great on paper, but you wouldn’t change all your release practices without testing it first. That’s just asking for trouble. We had to work on the foundational aspects for one configuration before expanding it to other configurations.

Step 1: Pick the Right Configuration

It sounds simple enough. However, the importance is to pick a config that is:

  • Relatively Complex: We needed a config that is relatively complex so that we can test the usage and limitations of PAPI. A configuration that is extremely simple may not show any benefit by automation.
  • Less risky: Basically, don’t pick your most important property to test.
  • Easy to Test: Although this sounds intuitive, it ties into the above point. If you pick a config that’s been on Akamai for a very long time, there may be rules with no documentation, and missing or tweaking them could cause issues. So stick to a config that is relatively new so that it can be tested for the functionality easily.

Step 2: Identify Rules that Vary by Environment

This basically involves enumerating the rules by looking at the primary config. Once identified, using the primary config as our reference, we built a document listing the rules that change from environment. For example, our list went like this:

Origin Settings, Origin DNS, Name Certificates, International Origins, Origin DNS, Name Certificates, etc….

Step 3: Build a Spreadsheet for Environment Values

Now that you know which rules vary by environment, build a spreadsheet documenting the values. This document will be your reference for coding the build scripts.

The content of the spreadsheet would something like this:

Property Dev QA Production
Origin DNS origin-dev.customer.com origin-qa.customer.com origin-prod.customer.com
CP Code CPCODE1 CPCODE2 CPCODE2

Step 4: Build a Master Configuration

The first concrete step is to build a master configuration. This config will have all the environment related values setup as a Property Manager variable. We’ll then build a configuration to use these values by environment.

Note: The master configuration could become HUGE. It will essentially have all the code necessary for three different configurations. For extremely complex setups, this could become a roadblock.

Step 5: DevOpsify

This step is where the magic happens. Using the build script, different versions can be created and activated to the right environment.

  • Pull the master config using PAPI.
  • Store the master config to a git repository.
  • Using the build script, create the appropriate version (Dev / QA / Prod).
  • Using PAPI, activate to Prod.

Conclusion

Our DevOps journey changed the way Professional Service delivers work, and helped map out good processes for DevOps. Our ultimate goal was to reduce the time spent on configuration changes and make the process faster, and we did.

But these are early days in DevOps, and it’s going to keep getting faster and easier. Akamai is committed to DevOps in order to make the internet awesome for developers.

Categories: DevOps Articles

Suggested Article