Header background

Re-imagining your DevOps tools to build a next generation delivery platform

Many organizations that have integrated their software development and operations into DevOps practices struggle with efficiency because they’re juggling disparate DevOps tools, or their tools aren’t meeting their needs.

At Perform 2021, Dynatrace product manager Michael Winkler sat down with Atlassian’s DevOps evangelist, Ian Buchanan, to talk about how you can achieve speed, stability, and scale in your DevOps toolchain as you optimize your practices on the path to self-service.

The status quo of the DevOps toolchain

Before reworking your DevOps approach, it’s important to address why transformation is necessary.

Winkler described how many teams lose touch with their DevOps toolchains, “Organizations frequently select DevOps tools based on a pure technology-led approach without taking provided value into account (think: where do we have the biggest bottlenecks and organizational constraints),” he said. “Additionally, many tools have a standalone purpose, but teams attempt to use them for other use cases, leading to these tools being stretched beyond their capability. The piecemeal approach many organizations take when working quickly creates functional gaps and complexity.”

DevOps pipeline
Each part of the deployment pipeline interacts with the others, so it’s important to evaluate each phase to avoid tool sprawl.

To assess how DevOps tools impact your deployment pipeline, it’s worth looking at each phase of the pipeline, like in the example above. Each part of the interacts with the others, often in unpredictable ways. Because of this, skipping ahead or trying a big bang tool adoption for the whole pipeline is a sure path to overcomplicated tool sprawl, and the results are often slower or worse releases.

If you attempt to generalize for every stage, you can’t customize for the unique constraints that each environment brings.

Re-imagining your DevOps toolchain on the journey to self-service

Buchanan urges teams to consider where time is spent. “It’s important to factor in not only how long you are spending in staging, testing, and production, but also how long you’re spending between phases,” he said. “This tends to be where the most time is lost.”

Rather than focusing on tooling in each stage itself, look at tooling in the handoff between stages. How do the approaches you use allow your teams to work more collaboratively and reduce friction? Where could you benefit from automation and self-service?

Stages in the DevOps journey
When it comes to reimagining your DevOps toolchain to build a next-generation delivery pipeline, it’s important to identify where on your journey your organization is now.

Many organizations are somewhere in the first three stages. One of the first steps in the journey toward DevOps is tackling change management and being able to move from normal change to standard change.

In a lot of organizations, normal change is named that because it’s the most common kind of change. But standard change is the kind of change you can put on rails, make automatic, and become repeatable – the kind of change that actually reduces risk and improves speed.

How to approach transforming your DevOps processes

Winkler shared how Dynatrace chose to approach this challenge:

1. Speed

Here at Dynatrace, we started off with a big focus on automation and speeding up delivery. A goal we identified very early on was targeting one hour code to production. In 2011, we only had a few releases a year, but by 2015 we were targeting 25 releases a year. With two-week sprints, and 25 releases, you need to automate to achieve that speed. In this approach, we think of infrastructure as code, with the philosophy that the Ops team should think like the Dev team.

2. Stability

The next wave focused on stability and a NoOps approach. Our goal was to have 93% fewer impacting issues, and to achieve this, we needed automated operations. We also had to take an approach to see everything as code, encouraging Dev to start to think like Ops as well. This helped us to build more resilient systems and increase automation on top of those systems.

3. Scaling out

The third wave was scaling out, which was done through Autonomous Cloud Enablement (ACE; our implementation of SRE), a paradigm we follow where we actually allow more than 800 engineers to work autonomously. This allows us to scale NoOps, scale our processes and tools, and really provide autonomy to our engineers.

The value Dynatrace delivers through these three DevOps transformation waves is about customer value, delivered fast and at scale. In addition, it means we eventually omit the distinction between DevOps, agile, and product teams, and move toward an end-to-end customer-value focused, product centric value stream. This value stream requires an approach of “continuous improvement.”

DevOps loop
Adopting DevOps tools and practices helps you develop a “continuous everything” mindset

As you begin to adopt DevOps tools and embrace new practices, you’ll see your teams get into a habit of continuous improvement in every space. You have continuous integration, continuous delivery, continuous deployment – you’ll find yourself attaching the word “continuous” to everything, because you’re going to be doing each one of these things on a daily basis. The magic of DevOps is the regularity and cadence of these practices.

Transforming your DevOps organization can be a daunting task. But by taking stock of where you stand, developing a culture of standard change, and approaching new practices in waves, this effort provides demonstrable value to your organization.

To learn more about how to make your DevOps practices more efficient, you can learn about our DevOps platform and watch the full session below.