Does CMDB Still Matter In The Cloud?

The Old Days

CMDB, Change Management and ITIL Configuration Management are terms that many of us associate with bygone era of IT that existed before cloud when gray haired Cobol-people decided what got rolled out during once-a-week maintenance window.

Rapid Fire

I could tell you that we are now living in a new age of cloud computing where volume and frequency of configuration changes is so much denser that old pipeline for managing changes simply will not scale but instead let me share some Cloudaware change management statics with you.

Below is an average enterprise AWS deployment of approximately 40 AWS Accounts and 3,000 EC2 Compute Instances. This deployment experiences about 50,000 destructive AWS events per day!

Approximately 200 AWS destructive configuration changes are marked by Cloudaware as highly sensitive. These include VPC Peering Acceptance requests, new IAM Admins, S3 Bucket policy changes and Security Group modifications that impact large number of EC2 and RDS Instances.

Now imagine every single one of those changes having to go through the traditional pre-emptive change management process but let’s not throw out the baby with the bath water. Who throws out babies anyways?

<Rant>

I do demos at Cloudaware quite often and to this day once in a while I get someone who is interesting in having EVERY change to their AWS or Azure or GCE environment go through traditional ITIL Change Management process. Yes you have to wait for 3 days for you change to get approved so you can then provision something in your cloud in 2 seconds.

OK. FINE!

Let’s get rid of the old archaic configuration management processes. Completely. BS be gone. What then? Here is another anonymous customer story. This is a bit larger but a typical enterprise deployment.

73 AWS Accounts and almost 6,000 EC2 Instances. Not shown on the screenshot are 29,353 security group rules they have. Number of change requests for these 30K firewall rules is ZERO. There is simply no way to trace back why most firewall policies are there. When there is no accountability and no way to trace back the configurations changes, eventually the whole cloud environment becomes unmaintainable, insecure and over complicated

Solution is Very Simple. Seriously.

• Changing the timing of the approvals
• Let the algorithms decide what should require an approval

Not All Changes Are Equal

At Cloudaware we like this concept of agile change management. Agile Change Management stands on several philosophical statements. If you agree with these statements, there is a high probability you will like agile change management especially in AWS, Azure and GCE environments.

1. You hire intelligent people whom you trust
2. Even accountable employees make mistakes
3. You value agility, productivity and self-sufficiency
4. You adopted cloud because you agree with #2
5. You realize that overtime configuration complexity increases

Here are sample changes for which we do not need to kick off approval processes:

• New instances under certain $ value or instance type
• Creating of new EBS Volume or Elastic Load Balancer
• Creation of Read-Only IAM User
• New Security Group Rule to a trusted internal IP Address

Conversely, here are examples of cloud configuration changes for which we should kick off an approval:

• Accepting VPC Peering Connections (Whoa)
• Connecting SAML Identity Provider to AWS Account (gasping…)
• Adding 20,000 IOPS to DynamoDB table (that’s going to cost like 1 small SUV/month)

The Shpeel

1. Cloudaware lets you create approval workflows specifically for types of changes that are important to your organization.
2. You can see approval status next to AWS, Azure and GCE objects for which you have turned on approval process. This allows you to differentiate between 3 things. (Approved Changes, Reject Changes, Unreviewed Changes). Since Cloudaware speaks Azure as fluently as it speaks AWS. Let’s use Azure example for a change.

To cloud provider every change you made is a valid change because it has been made by someone with valid credentials. But in Cloudaware we create a new layer of Configuration Items (CIs) where you have approved CIs, rejected CIs and unreviewed CIs.

We can then track who, when and why approved the change.

Using Cloudaware workflows we can define exactly under which conditions a configuration items should be submitted for an approval and what the ITIL approval process is.

Cloudaware is shipped with about 50 default approval processes for critical changes in AWS, Azure and GCE. Customers can customize those approvals or create entirely new approval processes against any object in CMDB.

Using Cloudaware CMDB and Change Management, customer can keep up with rapid flow of changes in their cloud environments without compromising reliability, security and transparency in cloud management.

Find out more about Cloudaware here.