Agile Cloud Institute

Multi-Application Deployments with the Agile Cloud Manager

Ongoing application-level deployments can be performed with the Agile Cloud Manager, regardless of whether or not the application-level deployments are part of the type of enterprise-level deployments discussed above.

The diagram entitled “Application-Level Deployments Using The Agile Cloud Manager” illustrates the scope of application-level deployments using the Agile Cloud Manager.

Applications can be modeled as Service Types that might have some dependencies in an optional shared Foundation. Therefore, the scope of an application deployment is limited to one Service Type and possibly one Foundation. Your allocation-level deployment pipelines might also operate on individual instances of a service type depending on how you structure your systems.

Nothing needs to be changed in the Agile Cloud Manager system configuration files to deploy upgrades to applications because application-level elements of an appliance are limited to one or more configuration-as-code scripts that do things like:

• Installing the application into specific compute units
• Altering the structure of a database
• Or making other narrowly-scoped changes using a configuration-as-code script

To deploy an upgraded application using the Agile Cloud Manager, you therefore only need to change the artifacts that get pulled in by specific pre-existing configuration-as-code scripts related to the application within the system configuration.

The relevant configuration-as-code scripts for an application deployment will be isolated to a specific Service Type and Foundation within the system configuration.

In addition, you might optionally publish a new version of the application-level configuration-as-code script and you might publish new values for some of the key/value pairs in the config.yaml which allows many teams to reuse the system templates.

The next diagram is entitled “Application-Level Deployment Examples Using The Agile Cloud Manager” and illustrates two examples of possible ways you could design application-level deployments, including Blue/Green Deployments and Canary Deployments.

These examples are intended to be starting points from which you can design your own pipelines. There are many possible ways to design allocation-level deployment pipelines to be compatible with the Agile Cloud Manager.

Each of the two starting point examples is also described in the following paragraphs.

For Blue/Green Deployments, your pipeline might include the following steps:

1. Place the new artifacts for the application upgrade in the locations that will enable the artifacts to be found.
2. Create a cloned version of the appliance that contains the application by running the acm appliance on command.
3. Run automated tests.
4. Make a small change in your DNS provider to point traffic to the new clone of the appliance and away from the old version.
5. Destroy the old version by running acm appliance off on the old version only.

If you choose canary deployments, your pipeline might include:

1. Place the new artifacts for the application upgrade in the locations that will enable the artifacts to be found.
2. Run the acm foundation on command to update the Foundation of the relevant system to build a new image containing the new version of your app.
3. Put the new image into a few compute instances. You could do this in many ways.
   1. One approach is to rely on the cloud provider’s UI for the scale set or autoscaling group to manage canary deployments.
   2. Another approach is to have separate service instances for different scale sets of the same app in the same service type and then change to the new image in only one of the scale sets to start.
      1. You could increase the number of instances in a scale set during the canary deployment to accommodate creation of instances with the new version of your app during the canary deployment.
      2. The command acm serviceInstance on can increase or decrease the number of compute instances within a scale set if you send in different numbers as a parameter for the number of compute instances when the serviceInstance has already been created. Note that acm serviceInstance on simply updates an existing serviceInstance according to whatever rules are defined by the underlying basic building block.
      3. In diagram 12 above, we put the first acm serviceInstance on command before the new images are created by acm foundation on to make sure that the old image is used in the scale set before the canary deployment. Then we put the second acm serviceInstance on command at the end of the pipeline to bring the number of instances back to the normal level. The extra instances provide a margin of error in case the deployment identifies bugs in the application requiring rollback. Note that the number of instances might be expressed as a ratio relative to traffic because your scaling group might be configured to adapt the number of instances to the level of traffic.
4. Configure the UI in your router or load balancer to send a small percentage of users to the new version of your app.
   1. “Sticky sessions” must be configured in your router in order for this to work.
   2. Sticky sessions mean that the router will send each user to the same backend compute instances every time that user makes requests during a given user session.
   3. Sticky sessions are essential during canary deployments because different users get different versions of the app during the canary deployment, until the canary deployment has been completed.
5. Monitor how the new version is performing using the router or load balancer’s interface.
6. If the new app is performing well, then you gradually increase the percentage of users who receive the new version of your app.
7. If everything continues to work properly, you continue to increase the percentage of users until 100% of the users are receiving the new version of your app.
8. If you encounter a problem during the deployment, then use the router or load balancer’s UI to rollback all the instances to the previous version of the application.

Many other ways of performing application-level deployments using the Agile Cloud Manager are also possible.

The key point here is to design a process that is easy to recreate in any cloud or on-prem or at any edge.

back to Site Home
back to Architecture section Home