6 components of an automation (DevOps) governance model

Automated provisioning and application release automation enable new software or features to move from development into production in minutes, not days or weeks, in what the report calls an ‘Enterprise DevOps’ approach.

Embracing DevOps principles and culture is key to keeping pace with cloud-native competitors. That’s why one of the concluding recommendations in The Automation Advantage report is to build the governance model, processes, and culture for DevOps. So, what should your governance model look like? What are the key considerations for ensuring that your move to greater automation and a DevOps culture truly deliver on the promise of agility, scalability and speed?

The governance model should be structured around the following six components:

1. Automating for Compliance by Design

I initially placed this as the final component but, in hindsight, recognize its importance as the underpinning requirement for our governance model. The respondents to The Automation Advantage survey, around which the report is built, cite security concerns as both a challenge and a driver of automation. But, as Capgemini’s Cloud and Cybersecurity Group Leader Franck Greverie writes, “Using a security-as-code (SaC) and infrastructure-as-code (IaC) architecture to automate security processes ensures that they will be high quality and virtually risk-free.” I agree with this and it’s what ‘automating for compliance by design’ is all about.

Nobody wants their testers and developers to go onto a cloud platform, only to find it can be hacked. Instead, building an automated security architecture designed around your organization’s individual risk profile is a key piece of governance. This ‘by design’ element is important because it recognizes that every organization has its own unique approach to automation, DevOps and cloud. For example, the secure reference architecture for a bank will be built on a different risk profile than, say, a retailer.

With your architecture agreed on, the next step is to enforce compliance. A modular design is an ideal candidate for compliance automation. Every project (test, automation, DevOps, etc.) must adhere to the defined reference architecture, using the security blueprints included in a prescribed catalog of services.

2. Automated Insights

With your DevOps strategy agreed on and a structured reference architecture in place, you will then want to be clear on just how much of your cloud resources you are using. This requires a different approach to how you’ve managed (and billed for) consumption in an on-premises data center (DC). Previously, with an on-premises DC, you’re likely to have allocated costs (electricity, services, etc.) on a department-by-department basis according to their pre-defined individual usage. You will have had a fixed perimeter of hardware, which made it easier to budget as well as bill. Cloud, on the other hand, changes the game, with more sharing of resources and a ‘build as you need’ approach. You do not know in advance what capacity/resources your developers and testers will use, so you need a mechanism to measure and control usage within your governance model.

Deploying a dashboard and reporting tool that plugs into the consumption metrics of your cloud provider is a good way to capture accurate insights into your cloud usage. Typically, a Cloud Management Platform (CMP) portal will provide consumption dashboarding, trend analytics and optimization scenarios enabling you to see what you are consuming and whether certain components can be reduced if they’re not needed.

3. Continuous Monitoring

Continuous monitoring is the proactive approach of identifying risk and compliance issues by accurately tracking and monitoring system activity, along with monitoring of the applications’ health. Most, if not all, cloud providers include several services and native capabilities that can facilitate continuous monitoring and logging solutions in the cloud. The logged data can be monitored by several third-party tools, such as Splunk, Alert Logic, or CloudCheckr.

Then, at an application level, how do you proactively monitor to ensure that you know in advance that an issue is going to arise round the corner? How do you monitor performance? Is there a network bandwidth constraint that needs dealing with?

Your governance model should include tools and processes for answering questions such as these and resolving any issues, both now and in the future. Preferably, they should bake in automated resolutions that are standardized, depending on the type of issues that arise.

4. Automated Provisioning – based on Cloud Design Principles

The Automation Advantage report looks at the gains to be made from applying automation to IT processes, including infrastructure provisioning. It compares the Fast Movers (the top 20% of organizations at the most advanced stage of automation maturity) with the Followers (the least mature) and finds that Fast Movers have automated 3.2 times the number of infrastructure provisioning processes. Automation speeds up the infrastructure provisioning process. Fast Movers report the ability to provision a raw virtual machine in half the time that Followers can, and mid-size, multi-tier applications infrastructure even faster.

The governance model concerning provisioning should incorporate the right guidelines, ready-made templates, and automated provisioning scripts based on cloud-design principles. This will ensure that developers and testers can avoid over or under provisioning. Automated provisioning, using a cloud management portal, either home grown or a third-party tool from the market, offers a low touch approach to creating the right DevOps environment.

5. Integrated Continuous Integration/Continuous Delivery (CI/CD)

Automated provisioning (see above) is, of course, directly linked with CI/CD, which should be built into your governance model. Full integration of CI/CD through the use of scripts and templates in your DevOps practices reduces the time to deploy new code. CI/CD tools typically required encompass source code repository, automated build tools, unit test, provisioning, configuration, and deployment through an integrated audited workflow.

So why are such tools important? For multiple reasons, including:

-       They offer standardization in the environments that are created repeatedly through automated provisioning and templates. This takes away the risk of manual errors during creation.

-       They offer predictability in terms of the workflow required in the DevOps cycle, integrating all steps that are needed in a workflow.

-       They speed up the process, replacing manual intervention which can slow down (or halt) the DevOps process.

-       And, above all, every step can be logged, audited and approved in the workflow process and made visible through dashboards, thereby bringing in transparency to the entire CI/CD process.

6. Enhancing the Cloud Ops Governance Team

Last, but not the least, is the bolstering of the Cloud Ops team with enhanced roles and responsibilities. The aim here is to create new roles and run strong change management within the teams, both at a skills level and in ways of working.

Centralized cloud governance will typically encompass responsibilities of account provisioning, establishment of connectivity and networking, security auditing, hosting of shared services, billing and cost management. This helps the organization control the cloud resources and workloads, as well as keeping a tight hold on the security parameters.

 

These six components are my personal perspective on what a DevOps governance model should comprise of. The Automation Advantage report offers further insight into different aspects of governance, culture and technology on the journey to greater automation.

More tips can be found in the NEW research report: ‘The Automation Advantage’

 

About the Author