“Change” (CC BY 2.0) by krossbow, on Flickr

Change Management is an IT Service Management (ITSM) process for managing updates to business critical systems. With containerized applications it’s now possible to enable fully automated continuous delivery pipelines. So, how does change management fit in? Let’s take a look at what happens to change management in a container-native world.

Is Change Management needed?

The goal of ITSM change management is to minimize risk for mission-critical systems. In a traditional environment, this goal is accomplished by following a set of well documented, reviewed, and verified processes for making changes. The change management processes are approved by a change advisory board. Changes are restricted to certain fixed time periods with low user activity, called “change windows”. System administration teams prepare for the worst, including downtime and have contingency plans in place to revert changes before the change window closes.  

The goal of continuous delivery is to empower developers to confidently deliver updates and changes to production systems, whenever needed. At first, it may sound like continuous delivery is the polar opposite of change management.  But if you look closer, successful continuous delivery environments have modernized change management processes built-in!  Let’s examine how.

Container-native change management

Containers enable immutable images. This means that once a container image is built, the same container image can be run on a developer laptop, a test environment, or even in production. Since images are ‘baked’ at build time, changes to production systems can be  minimized to replacing one validated and tested image with another valid and tested image. By leveraging immutable images, the system can move from one consistent state to another much like transactions in a database system.

Although containers can be used for traditional applications (find out how here),  they are ideal for microservices-style applications where an application is composed of several services and each service is elastic, resilient, composable, minimal, and complete (source: Microservices: Five Architectural Constraints).

With a microservices-style applications changes are applied to smaller units. As each service is independently versioned (to satisfy the completeness constraint) – a microservice becomes the unit of change. This lower granularity leads to smaller changes, makes the overall system more resilient, and also making it easier to roll-out, or roll-back, changes.

With microservices and containers, you can now move beyond blue-green deployments to canary launches. A “canary launch” is a practice where a new version of a service is introduced whilst prior versions are still running. Using an application aware load-balancer, like Nirmata’s Service Gateway or NetlixOSS’s Zuul, some user traffic can then be directed to the new version.

So, with containers we get immutable images, and with microservices we get smaller units of change. Applying microservices and container together, system changes can now be small and fast. This helps reduce risk. With the right management tools, for automated deployment, monitoring, and remediation, it’s now possible to start automating the change delivery for container images.

But managing immutable images is not enough. In addition to image changes, there are other kinds of changes that can occur and need to be managed. These include changes to application configuration (e.g. environment variables, memory settings, etc.), and changes to infrastructure components. A good cloud-native application management system must manage all of these. Let’s see how Nirmata enables all of this.

What Nirmata enables

Managing Container Image Changes

Nirmata is designed to easily integrate with build tools like Jenkins, and image registries like JFrog Artifactory, AWS ECR and DockerHub. Leveraging these integrations, Nirmata can automatically watch for image changes. When an image change is detected, Nirmata checks each running application environment, and propagates changes based on configured policies.

Using Nirmata, you can easily model your delivery pipeline as a set of policies. An important abstraction in Nirmata is an “Environment Type”, which you can use to represent each phase in your continuous delivery pipeline.  

An environment type acts as a policy that defines what images each environment can accept, and if images can be promoted from that environment to the next phase in the pipeline. In the example below, we have a simple pipeline consisting of 3 environment types. The accept tag defines what images are allowed in environments of that type, and the promote tag defines how images are tagged when they are ready for the next phase.

Deployment pipelines in Nirmata

Managing Service Configuration Changes

In addition to image changes, service configurations also change over time. It is essential that these changes be managed in the same way – with proper governance and control. In Nirmata, you can specify how service configuration changes are handled for each environment type, or can change this for an environment instance.

Change Management Policies in Nirmata

This is possible as Nirmata treats environment as long-lived branches of the application blueprint. When a new environment is created, it inherits policies from the environment type and the application blueprint and a separate copy of service configuration data is automatically created for each environment. Hence if a service restarts, the same configuration can always applied even if changes are made to the application.

When a change is made to an application blueprint, Nirmata will check each running environment. Based on the environment’s policy settings, Nirmata can alert the user or automatically apply the change. If the service configuration update action is set to “notify” Nirmata will inform the user about the changes, and the user can review and apply them. Otherwise, if this field is set to “update” Nirmata will automatically perform a rolling upgrade on the service, when changes are available.

And all of this seamlessly works with granular environment level access controls (see – Access Controls for Containerized Applications).

Service Networking – Managing Infrastructure Changes

In addition to image and service configuration changes, container-native applications also need to handle infrastructure changes. For example, a service instance may be deployed on a new host and can get a new IP address and port.

Nirmata provides powerful service networking features which decouple the application from underlying infrastructure changes. This features include a DNS filter and TCP proxy, as well as a Service Gateway to manage ingress traffic flows.

Audit Trail

In addition to managing different types of changes, a container-native application management solution must provide a built in audit trail. Nirmata provides complete details on user, as well as system activities.

Audit Trail in Nirmata

Summary

Change management is an important process that needs to be implemented for business critical systems. With application containers, it’s now possible to gain agility, dramatically shorten the time required to apply changes, and automate delivery, to production systems.  However, automation does not eliminate the need for change management.

As enterprises start adopting containers for business critical systems, it is important to make sure their application management solutions are designed to enable business agility while providing proper governance and controls.

Some of the key considerations are:

• Managing and promoting container images
• Managing service configuration changes
• Managing infrastructure changes
• Audit trail across user and system activity

With Nirmata, change management is not eliminated but also made agile. Nirmata’s advanced application management features enable container-native change management processes with  enterprise-grade visibility and control for containerized applications. You can trial these powerful features for free at: https://try.nirmata.io