Software delivery has changed significantly over last ten or so years. These days, software needs to be delivered frequently, without service interruption, with zero downtime and no impact on end users.
Mike Kevis illustrated this process very nicely in his article on the evolution of software engineering practices over a time.
Continuous Deployment Example
Let’s look at an example of a typical release and see how a site goes from a version 1.0 to 1.1.
In the following image, users are visiting the current version 1.0 of the website. We are about to release version 1.1, but not until we ensure that everything works fine. Therefore we keep v1.0 running in the first environment and deploy v1.1 to the second environment. The initial scenario looks like this.
Although v1.1 is already deployed to the second set of servers, no traffic is directed to it yet. Ideally, only a small percentage of users should be routed to the new version in order to validate that everything works fine – this is called Canary Testing.
There are several such iterations resulting in more and more users being routed to the new version v1.1. At the end of the day traffic to version v1.0 should disappear and only the new version v1.1 should be served to end users.
Of course, if something goes wrong along the way, it should be possible to rollback and shift the traffic back to the previous version.
The good news is that Akamai can easily support this continuous deployment process meeting all mentioned criteria.
Phased Releases with Akamai
The Phased Release Cloudlet allows for fast and efficient implementations of continuous delivery, through an automated process that leverages Akamai’s OPEN APIs.
To showcase some of the features of Phased Release cloudlet and illustrate sample deployment workflow, we created a demo which allows for a very granular phased deployment of a new release of the website.
The new release can be activated for selected countries only, as well as only to specified devices (mobile, tablets, desktops). By releasing to a small percentage of users in those countries, you get fast deployments and rollbacks.
The UI consist of three sections:
- Deployment progress graph
Worldmap is where you define the country and release assignments. The colors represent releases, and on this may ReleaseA is the v1.0 site and and ReleaseB is the v1.1. This allows you to serve different releases to different regions of the world, and to have full control of the entire process.
You can also set the percentage of each device type that will be served the new release.
Graphs on the bottom of the screen shows how many requests are hitting each release and how versions are distributed across device types. It’s updated every second, providing instant feedback on deployment progress.
One of the biggest advantages of this solution is that it doesn’t require executing sophisticated commands, everything is being done instantaneously and an operator gets immediate visual feedback and sees the progress.
This example uses a NASA-like control panel that was built for specific requirements and implements a certain workflow. But an important point here is that you can integrate 3rd party software with Akamai’s OPEN APIs to create tools to automate most of your CI tasks and custom workflows.
The solution here was presented at the Akamai Edge Conference 2016 in San Francisco. Click the link to watch a recorded session showing the demo in action.