Change is inevitable. In fact, if you’re practicing Agile and DevOps, of all the “continuous” states that you aspire to, there’s one you can count on, and that’s continuous change. Your team is continuously changing the infrastructure to deliver value to your customers in smaller, more frequent iterations. And the cloud enables rapid changes, in fact, anyone with an API call can provision resources and make changes to those resources. The problem is, if you don’t implement a proper change management process, your costs can get out of control and managing compliance will become a nightmare.
Change management process can provide rigor and discipline to assess risk and review nonfunctional requirements for each change. Typical thinking says process means slowing down. But not at all. With cloud, you can have a change management process, with visibility and control of each infrastructure change, without compromising delivery speed.
In this blog post, I’ll cover five actions you can take now to improve your change management process on AWS.
Cloud platforms offer APIs to provision and manage resources, making it easier to automate the application delivery process. It’s no surprise that in this automation-friendly environment, automation is the key to streamlining the change management process. For fans of The DevOps Handbook, you’ll recognize that the authors recommend auto-approving all routine and low-risk changes. The more you can automate the approval process for standard changes, the more visibility you get into other changes that actually require approval. Otherwise, everything gets lost in the noise.
DevOps and Agile cultures focus on the customer, and everything we do should be about adding customer value. Infrastructure changes that can’t be auto-approved should be tracked back to a user story (in JIRA, or whatever ticketing system you use). Putting a process in place to track each infrastructure change to a user story codifies the discipline to think and act in the context of value-add to the customer. What’s more, organizations that don’t have similar processes struggle with related issues, like developers provisioning resources and then forgetting to shut them down, which adds cost. Like that leaky faucet that keeps the water meter running.
AWS Service Catalog is among the most useful and underutilized AWS services, in my opinion. It allows users to consume services without needing to know the complexity of provisioning those services. Leveraging the service catalog can significantly improve your change management process. Just think about it. Since IT builds these services templates following company guidelines, they should comply with company policies already. So your process can auto-approve resources provisioned from the service catalog.
It’s not possible to have all services offered as part of the service catalog. That’s why it’s essential to establish strong policies, and enforce them with automation. Good examples of this include sending alerts or triggering (AWS) Lambda if a user launches instances without tags, or disables inactive keys when they haven’t been used for more than a week. The goal is to empower people to continue to go fast while enabling them to make changes that adhere to established policies.
Surprise, surprise, your DevOps engineers spend much of their time communicating via modern collaboration tools like Slack or HipChat. You can leverage these tools to provide visibility to change management. What we’ve seen work rather well is to produce automation feedback right in Slack. For example, you can send output like “these instances are getting stopped because of missing tags.” Since the information is provided in the context of chat, engineers readily collaborate and discuss any required changes. The integration and context is valuable and part of what’s driving a significant push for ChatOps, which can bring an improved culture of collaboration and visibility.
I hope these thoughts are useful. You can start executing immediately.
At my consultancy, nClouds, we’ve done hundreds of AWS implementations and needed a modern change management tool for the cloud. We built nOps to make change management effortless for AWS environments. It addresses key use cases including change requests, compliance and cost management, and security. Its key features support the five suggestions I just laid out in this blog. What’s more, nOps lets you easily manage changes regardless of the workflow that your team is using (AWS CloudFormation, HashiCorp Terraform, Boto, etc.). And, it lets you add workflows that include AWS Service Catalog, allowing you to trigger approval processes based on business requirements.
The team at nClouds and our clients have been using nOps in complex production environments for years. We’re now making it available more broadly. It’s easy to sign up for a 30-day, free trial. Try it out. I’d love to hear about your experience with nOps, and how it matches your change management requirements.
How to deploy a Kubernetes cluster on AWS with Terraform & kops
2019-08-14 16:53:17How to move code from DEV/UAT to PROD fast using AWS CodePipeline and AWS CodeBuild
2019-07-26 17:18:08How to Select and Migrate to the Right AWS Elastic Load Balancing (ELB) Solution
2019-03-13 15:04:08