Accelerate and Scale DevOps

Source- cio.com

Software teams have to be fast, especially when it comes to adapting to change. As for performance expectations from the market and the business increase, DevOps has arisen as a prescription for improvement. However, teams need to know not just what success looks like but how to achieve it.

A survey of more than 3,000 technology professionals, the 2018 State of DevOps Report, co-authored by Puppet and Splunk, defines DevOps as an evolution comprised of five stages. Our data indicate that these practices correlate to DevOps success, as measured by the CAMS model.

The Five Stages of a DevOps Evolution

1. Normalize the technology stack
2. Standardize and reduce variability
3. Expand DevOps practices
4. Automate infrastructure delivery
5. Provide self-service capabilities

In this post, we’ll provide an overview of stages 1-3, exploring how to accelerate and expand your DevOps initiative. Get more information on all five stages in the 2018 State of DevOps Report.

Stage 1: Normalize the Technology Stack

Automation is often believed to be the starting point for DevOps. And while it’s true that automation underlies any successful DevOps initiative, it requires a lot of preparation. The simpler your tools and systems are, the easier they will be to automate down the road.

Normalizing your organization’s tech stack — adopting a standard set of tools and reducing redundant technologies — makes management easier and enables future automation efforts. Normalization is achieved through two key components: adopting version control and standardizing operating systems.

Prioritizing Version Control

Adopting version control is the first step to implementing continuous integration. When application development teams adopt version control, they’re able to produce deployable code more frequently. This is great for devs but puts added pressure on ops teams to deploy quickly while maintaining system stability and security. This tension is often a key driver for DevOps.

As development gets more distributed, teams have a greater need for version control and put both application code and app configuration files into their version control system. At some point, configuration data is separated from code to ensure that sensitive information is protected. This builds the foundation for automated deployment, allowing you to track who made what changes, and to roll back changes if necessary.

Standardizing Operating Systems

In a pre-DevOps environment, it’s common to find applications deployed across a variety of operating systems. Each one-off installation can place a heavy burden on an IT team and increases the risk and impact of maintenance efforts, especially emergency maintenance. Reducing the number of outliers and unique OSes that need to be monitored and managed simplifies the process of automation and helps create a shared pool of knowledge around a common tech stack.

Building on a standard set of technology is a contributor to success at multiple stages of the DevOps evolution. Start small by addressing technologies within a single team, and gradually expand to those that require cross-team buy-in. Use proven technologies and reliable processes for what goes into production, and define clear guidelines for adding any new technology at a later date.

Stage 2: Standardize and Reduce Variability

By the time you reach Stage 2, your organization should have:

• Begun standardizing on a set of technologies
• Separated application configurations from data and placed them in version control
• Adopted a consistent process for infrastructure testing and sharing source code

The theme of standardization continues in Stage 2, and it’s here that the reuse of technologies and patterns becomes important. The practices that define this stage — building on a standard set of technology and deploying on a single, standard operating system — allow teams to achieve more repeatable outcomes with less variance.

Build on a Standard Set of Technology

As enterprises grow, complexity increases. Teams must manage new applications, services, and technology stacks in addition to legacy applications and systems. All of this oversight forces teams to be reactive and leaves little time for innovation.

Standardizing patterns and components means teams no longer need to continually re-learn how different technologies operate, scale, fail, recover, and upgrade. Start by choosing foundational elements to normalize on, such as testing workflows, build and shipping patterns, with a focus on improving and optimizing processes that impact multiple applications.

Reduce Operating System Variability

As we discussed in Stage 1, adopting a single, standard operating system or a small set of OSes enables teams to move faster by saving time on patching, tuning, upgrading, and troubleshooting. Unfortunately, OS standardization isn’t always straightforward. Software applications with long lifecycles may not be compatible with newer operating systems, or specific patches may not work for a particular application.

As you’re getting started, remember that less is more; even if it’s not feasible to use a single OS, two is better than five. Within the operating systems you do run, reduce variability by normalizing compute resources. This will make troubleshooting and maintenance easier.

Stage 3: Expand DevOps Practices

Standardizing your tech stack and prioritizing version control enable collaboration between Dev and Ops. When these teams share tools, applications, and services — as well as knowledge — they can work better together. When you get to Stage 3, it’s time to expand these early pockets of success across the organization.

Stage 3 is defined by two key practices:

• Individuals can do work without manual approval from outside the team.
• Deployment patterns for building apps and services are reused.

Reduce Bureaucracy

When the authority to make decisions is removed from the people who have the relevant information and are doing the actual work, productivity, and efficiency suffer. The authors of “Accelerate: The Science of Lean Software and DevOps” studied software teams and concluded that “teams that required approval by an external body achieved lower performance.” Our 2018 State of DevOps survey reinforces this finding.

While it’s unrealistic — and irresponsible — to completely eliminate change oversight, a DevOps transformation is a good time to revisit existing approval processes. Ask yourself: Are delays and wait times justified, or are they part of a bureaucratic legacy workflow? Identify the unnecessary bottlenecks and experiment with ways to eliminate them.

For example, you might consider giving your operations team the power to approve specific types of changes that are relatively low-impact. This not only saves time and increases agility, but helps build trust and provides team members with a sense of ownership – two essential parts of a DevOps practice.

Reuse Deployment Patterns

If each team within your organization creates its own deployment patterns, agility is limited, and it’s harder for developers and infrastructure engineers to move between teams. Developing reusable deployment patterns — however simple or complex — helps eliminate silos, documentation, and hand-holding.

When running several types of applications and systems, some deployment patterns may be applied universally, while others, such as n-tier web apps or cloud-native services, are specific to certain families of applications. The more broadly patterns can be applied, the greater the benefits. An optimization applied to a deployment job or pipeline is immediately applied to all the applications that use it.

Heading to Automation and Self-Serve

The 2018 State of DevOps Report is designed to guide you through the stages of a DevOps evolution, but every organization is different. We’ve found that some organizations take on Stage 3 before Stage 2, while others carry them out simultaneously. However, our research shows that both steps are essential in order to achieve success in Stage 4: automating infrastructure delivery.

To learn more about succeeding in Stage 4 and beyond, stay tuned for our next post, or download the 2018 State of DevOps Report for more information on each stage, plus the key findings and methodology behind the report.