Note: This is the third in a series of three posts on the five stages of a DevOps evolution. If you’re new to the series, check out the first two posts, Building a Strong DevOps Foundation and Accelerate and Scale DevOps.
When you think of DevOps, automation is likely one of the first things that comes to mind — and for good reason. DevOps cannot function without automation. But, as our 2018 State of DevOps Report makes clear, undertaking widespread automation too early in a DevOps evolution can impede progress at later stages.
Stages 1-3 in a DevOps evolution — defined in the report and in earlier installments of this series — help establish clear standards and cooperation across multiple teams, laying the groundwork to scale automation.
Stage 4: Automate Infrastructure Delivery
In the early stages of a DevOps evolution, automation tends to be limited to the processes of individual teams, as in the case of operations teams adopting configuration management. As these teams become more efficient and demonstrate success, they serve as a proof point, encouraging other groups to seek ways of replicating their results.
In Stage 4, the objective driving infrastructure automation is greater agility for the business as a whole, and the early wins of isolated teams start to expand across the organization. We’ll discuss the automation of three key areas: system configurations, provisioning, and security policy configuration.
Automate System Configurations
Automating system configurations and keeping them in version control provides control over your infrastructure layer and enables you to achieve agility with the applications and systems running on top of it.
While you may eventually strive to automate all change, we recommend starting with items that you run into most frequently across the greatest swath of infrastructure components — such as logging or monitoring configuration for all systems. This will have a big impact in terms of time saved, freeing up time to work on more complex automations.
No matter how small you start, the gains at this stage include speed, consistency, documented behavior, and portability.
When system configurations and provisioning are both automated, you have the basis of a self-service infrastructure. This shifts the role of operations from order-takers to owners and operators of a service-providing organization.
Provisioning can be the automatic creation of a resource of nearly any type. It most commonly refers to OS instances, network connectivity, storage, and accounts, but can also include hooks into pager systems, DNS, CDN, load balancers, databases, and more.
As with system configurations, there’s no need to tackle everything at once; prioritize the most frequently requested items to get some early wins in the form of consistency and time savings, then move on to less common requests.
In the early stages of this process, provisioning could be done with a framework or even a set of shared scripts and utilities stored in version control. The goal is for the team to level up and perform the provisioning in an automated way.
Automate Security Policy Configuration
In addition to enforcing internal security policy, organizations are often required to demonstrate compliance to external groups, be it an audit committee or Sarbanes-Oxley. The best way to adhere to security policy is to know whether you’re compliant, and to be able to fix systems when you’re non-compliant — automation can help do both.
There’s an evolutionary cycle for automating security policy, and it often starts with a single team member writing a scanner for a specific policy. From there, she might write a corrector or enforcing script, and then the script might generate a report that can be archived or shared among security teams or auditing staff. As automation matures, security policy should be placed into infrastructure configuration management to consistently enforce the correct policies.
Stage 5: Provide Self-Service Capabilities
In the fifth and final stage of a DevOps evolution, successful collaboration accelerates across functional boundaries, multiplying benefits to the business in a few significant ways:
- Application architecture begins to evolve towards working with and supporting cloud migration, container adoption, and proliferating microservices.
- Security policy automation becomes the baseline for measuring security and compliance throughout a department, or even the entire organization.
- Automated provisioning advances to provisioning of whole environments for developers, testers, and other technical staff.
Providing self-service capabilities depends upon every DevOps practice we’ve discussed up to this point, from cross-team collaboration to version control to automation to reusable deployment patterns.
Automate Incident Responses
Manually responding to critical incidents, such as intrusions or malware, consumes time and engineering resources. Perhaps most importantly, it often leads to slower response times and the potential to overlook affected machines or systems. Automating incident response enables faster remediation by reducing handoffs, and ensures that remediation processes are consistently applied.
Given the critical nature of response management, you may wonder why it doesn’t come into play until Stage 5. The reason is that significant organizational and process barriers often make incident response difficult to automate. If a response team must file a ticket to get others to validate firewall rule changes, or service owners must sign off on changes, or team members aren’t empowered to push final changes to production, automation isn’t feasible. The practices that impede fast feedback and action must be removed or revised.
When you get to a point where incident response can be automated, focus on the processes and systems that let you identify issues and those you deploy when responding — like adding a malicious IP to all firewalls across your infrastructure; collecting data for later forensics; or isolating infected machines. As at other stages, you’ll realize the greatest gains if you start by tackling a problem that crosses functional boundaries.
Self-Service Resource Availability
Empowering teams to execute their work from end-to-end has many positive implications: it provides an added sense of ownership, reduces frustration caused by waiting on other teams or process approvals, and makes it easier to standardize configurations. Not surprisingly, our data shows that the most successful teams report a higher proportion of self-service systems.
For any item you’re looking to deliver via self-service, map out your existing manual process along with required approval workflows and look for optimizations. A common blocker for organizations is to focus on optimizing self-service platforms for manual use, without considering how they might fit into an automated pipeline. Bear this in mind as you work toward widespread self-service.
The five stages outlined in the 2018 State of DevOps Report provide a template for DevOps success. Teams that implement the practices defined at each stage report higher performance and better business outcomes, but the truth is, the path will undoubtedly look a bit different for each organization. In turn, there is no uniform measure of success.
The four pillars of the CAMS model — culture, automation, measurement, and sharing — are a useful benchmark for any company. Our data shows that highly evolved organizations:
- Have a DevOps culture that spans multiple departments.
- Have automated more services for broad use.
- Automate more measurement for business objectives.
- Share patterns and best practices broadly across their organizations.
Continually evaluating progress in these areas will help identify achievements and opportunities for improvement.
When all is said and done, there are many ways to approach a DevOps initiative, but with the right approach, you can achieve and scale success faster.
Learn more about the five stages of a DevOps evolution in the 2018 State of DevOps Report