DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. DevOps and CI/CD
  4. Change Management for Containerized Applications

Change Management for Containerized Applications

Containerized applications introduce automation to the build process, but that doesn't mean that change management can be skipped as a result.

Jim Bugwadia user avatar by
Jim Bugwadia
CORE ·
Jan. 05, 17 · Opinion
Like (5)
Save
Tweet
Share
8.76K Views

Join the DZone community and get the full member experience.

Join For Free

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 to 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. they 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 that 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. as an example, let's see how nirmata enables all of this.

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 three 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

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

change management policies in nirmata

this is possible, as nirmata treats environments 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 be 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.

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 users, as well as system activities.

audit trail in nirmata

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.


you can explore these features, and all else nirmata has to offer, for free at: https://try.nirmata.io


application Continuous Integration/Deployment microservice Container Delivery (commerce)

Published at DZone with permission of Jim Bugwadia, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Using QuestDB to Collect Infrastructure Metrics
  • PostgreSQL: Bulk Loading Data With Node.js and Sequelize
  • How To Use Terraform to Provision an AWS EC2 Instance
  • What Java Version Are You Running? Let’s Take a Look Under the Hood of the JDK!

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: