If you’re delivering software in a regulated space, and you’re using Kubernetes, you’ll know how problematic and complicated change management is.
If you’re delivering software in a regulated space, and you’re using Kubernetes, you’ll know how problematic and complicated change management is.

How Merkely automates Change Management for Kubernetes workloads

If you’re delivering software in a regulated space, and you’re using Kubernetes, you’ll know how problematic change management is. On one hand you have a highly dynamic container based system that’s constantly changing. On the other hand regulatory obligations mean you must have a controlled and documented way of managing all of the changes in those systems.

And that’s not all. Knowing exactly what’s running in production at any given time is difficult enough, but it’s only half the battle. You also have to know how it got there and whether it’s in compliance with your defined process.

In this article I’ll explain how Merkely can automate the change management needs for your Kubernetes workloads.

What’s in production?

The most important use case for auditors and development teams is to be able to give clear and reliable answers to what’s running in production.

You can get this information from several different sources

  • Using the kubectl command line
  • Navigating the cloud console
  • Digging through pipeline deployments

These methods require access permissions and technical understanding that might not cross team boundaries. They are also likely to be barriers to non-technical stakeholders and auditor/compliance functions. In addition, these systems make it nearly impossible to “rewind the clock” and view the historical state of production, which is essential for compliance.

Merkely app screenshot what’s running in production

Merkely helps teams answer this question in a way that is easy to set up with the rest of your DevOps tools. The Merkely client periodically sends the metadata of the workloads running in the cluster to the Merkley server. When Merkely receives this information, it is written to the append-only journal for that particular environment.

Once this is in place you have observability over your production workloads for debugging, troubleshooting, auditing, and security purposes. And Merkely stores the complete history, so you can now also look through the changes over time. What’s in production? Now? Last Thursday? On Christmas eve? What are the recent changes to production? The answers to these questions are now at the tips of your fingers.

merkely app prod environment screenshot

How did it get there?

You now have a full picture of how production is changing. But production is only the final part of the compliance story. For compliance purposes you also need to understand why systems change. You need to know that correct processes have been followed, with audit trails you can trust, across your entire software development landscape.

Basically, you want to track all of the changes that will have occurred to an artifact on its journey from initial commit to production. That’s a lot of metadata, but it’s what is required to keep a dynamic, container based system in compliance.

merkely app screenshot how did it get there

With Merkely, capturing all of this information is as simple as adding reporting commands in your DevOps pipeline. Again, Merkely stores all of this information in tamper-proof, append-only journals, giving your stakeholders confidence that all binary provenance, risk controls, and guardrails are in place.

Merkely makes it easy to:

  • Record binary provenance based on content addressable storage
  • Attest evidence of risk controls being performed
  • Create and record release approvals
  • Log deployments

Implementing Continuous Compliance

Ok, so now you have the complete change history and event logs for production. You also have all of the metadata for each artifact’s journey to production. That means you have the building blocks required to achieve Continuous Compliance.

Continuous Compliance helps you to detect:

  • Unknown or undocumented workloads in production
  • Unapproved deployments
  • Failed deployments

Merkely uses the information from the pipelines (what should be in production) and compares this with what is actually in production. This provides you with a real time continuous audit. If there is a mismatch in expectations, or if any policies are not met, Merkely will alert you to take action in real time.

merkely app screenshot is it verified

The Merkely vision

We are strong believers in the potential for DevOps Change Management to free regulated teams to do their best work. For us it means giving them the ability to deploy compliant software changes without the manual documentation, gatekeeping, and other delays that are usually found in these industries.

We hope this has shown you how Merkely’s solution for continuous compliance and change management works for Kubernetes. We also support many other types of runtime such as web servers, s3, lambda, ecs, fargate, and more. And if you have any questions about how Merkely can help you please get in touch.

Top Articles

How to do Continuous Delivery in your ITIL framework?

Continuous Compliance: A DevOps culture

We’re going to DevOpsDays Denmark 🎉

Published February 23, 2022 in
Mike Long
Mike Long

Subscribe to The Merkely Meteor Newsletter for all the latest on regulated DevOps, features, news and events

Merkely is committed to protecting and respecting your privacy. You can unsubscribe at any time by clicking the link in the footer of our emails. For information about our privacy practices, please visit our Privacy Policy.
Subscribe to the Merkely Meteor

More posts in technology

How to do Continuous Delivery in your ITIL framework?

Key takeaways ITIL change management framework doesn’t work for frequent software releases That’s a problem because regulated teams want continuous delivery By automating change management they can release software as standard changes Introduction There are quite a lot of articles out there on this topic, usually trying to score for SEO, that promise to show you how to do this without actually ever getting there. But it can be done and in this piece I will explain how.

Continuous Compliance: A DevOps culture

Imagine your developers are the world’s fastest relay team 🏃 When it comes to build, test, and qualify they get round the running track faster than anyone else. Unfortunately for them the finishing line is hidden somewhere outside the stadium. Welcome to regulated DevOps How did they get to be running this impossible race? Well, better tools and working practices have meant a dramatic shift from annual software releases to a world where teams have the ability to deploy multiple times every day.

Why ITIL Change Management doesn’t work for DevOps teams

Are you trying to do DevOps under regulation? If so, you’ll know the pain of change management. In this article we’ll look at how delivering software with DevOps is incompatible with old school ways of managing change with ITIL and how you can automate your change management process with a DevOps approach. As regulated industries speed up their DevOps processes they find that managing software releases with ITIL tickets and change meetings just doesn’t scale.

Subscribe to the Merkely Meteor newsletter for all the latest on regulated DevOps, how to’s, features, news and events

Merkely is committed to protecting and respecting your privacy. You can unsubscribe at any time by clicking the link in the footer of our emails. For information about our privacy practices, please visit our Privacy Policy.
Subscribe to the Merkely Meteor