Every business wants to grow, move faster, and perform better for its customers. At Dynatrace we thought that moving to a DevOps culture was the next logical step to do this – as it would allow us to quickly release more new features to our customers.
We made this move while the company was going through a period of growth, which meant the DevOps culture needed to scale too. To make this happen, we needed additional resources to scale at the same pace. However, we quickly learned that it wasn’t actually a DevOps culture we needed to create. Instead, it was a NoOps one.
[ Want advice on culture? Read: How to scale company culture: 5 tips for IT leaders ]
DevOps vs. NoOps
The term DevOps is commonly used, but what does this mean? In simple terms – your development and operations teams are working together closely and the two groups must communicate and collaborate with one another to bring something into production. When your company or customers (or both) are growing and you want to move quickly, there’s little to no time for communication and collaboration. And that's one way the DevOps model can keep you from moving as fast as you'd like.
Other difficulties can arise when you’re building a DevOps culture, while also growing fast:
- Operations teams that are not very deep into development won’t have a full understanding of what the code they’re deploying is supposed to do. This is okay when you’re releasing code less frequently, say twice a year, but it doesn’t work when you move to two-week release cycles.
- DevOps is also a difficult culture to breed as you grow because staffing excellent operations talent isn’t easy, even if you have the budget to do it. For us, it just wasn’t feasible to build a 50-person ops team consisting of top talent. Even if we could, they’d be easily frustrated because top talent wants to move quickly – they don’t want the roadblock of always having to confer with another team.
Therefore, while once a very effective method, the pace of technology and customer requirements today mean businesses require a method that is much quicker and seamless – for us, that’s NoOps.
A NoOps environment quite literally means no operations. NoOps is when an IT environment becomes so automated from the underlying infrastructure – through technologies including artificial intelligence (AI) and machine learning – that there’s no need for a dedicated team to manage software in-house.
At Dynatrace, we made this work by heavily investing in automation to play the roles of deploying, monitoring, and improving software. We no longer have a team that’s dedicated to protecting the development team from doing things wrong in production; instead, we have self-diagnostics and self-healing that does this automatically.
Building a culture of NoOps
We didn’t shift from a DevOps culture to a NoOps culture overnight. It took many years, and we learned several lessons along the way. Here’s how we got there.
1. Shift quality to the left
Quality, typically, only counts once it’s in production because it impacts customers. We wanted to duplicate that in the development stage to ensure that what the team was deploying each day remained at the same quality as our in-production software, also known as “shifting left.”
To do this, we implemented a rule: You must make whatever code you are testing work in our internal development environment, which mirrors our production environment. If you can’t make it work there, don’t bring it to us.
Our development teams started adding self-diagnostic and self-healing strategies into their own code and defined how monitoring and alerting should look like.
2. Expect and embrace pain
The mandate to work inside the one development environment was difficult for the team to adjust to at first. Over the first few weeks of implementing the new method, some of our developers said it wasn’t working and wanted something different – or what they already knew. But knowing the benefit this method could bring, Dynatrace pushed on. The discomfort was necessary to get to where the developers are today – operating a NoOps model.
3. Shift right
In a DevOps culture, you have a team, typically the Ops team, that is defining how production monitoring, alerting, etc., work. Staging and development environments are typically monitored differently by developers themselves. With the NoOps culture in mind, we wanted to shift the full monitoring responsibility to the development teams, so that testing could happen in production, also known as “shifting right.”
This was important for a few reasons:
- Our main consumers must be developers as they are pushing changes to production very often. A separated team could not keep up with these such frequent changes.
- Second, our consumers must have very detailed knowledge of the code and be able to find problems quicker than an Ops team. The Ops team might find an issue after it’s already impacted a customer, but a developer might notice an incorrect log line or a small failure rate increase before it gets too high.
- This shift from left to the right, as explained above, also helped to change the company culture because we're proud to own their component through to production.
4. Incorporate the right tooling
Developers need automation in order to make changes quickly when they spot an issue. It’s not practical to wait an hour to deploy a new code change, and it certainly isn’t practical to wait weeks until the next release.
Automation tools enable teams to push out changes with a safety net and no manual touches. And as they no longer have another team to confer with, this expedites the process even more.
5. Obtain management buy-in
Having management on board was essential throughout the process. When it was painful for developers, we needed management to support them and understand that features may be delayed. We also needed management support in understanding that while customers might not see direct value in investing in self-diagnostic and self-healing features, they were still important from a business perspective because they would ensure that applications are highly available.
Why NoOps is worth the effort
Moving to a NoOps model isn’t easy; it can be painful, but it’s important for everyone to understand why you’re doing it and the benefits you’ll gain. At Dynatrace, it’s removed roadblocks and enabled us to move faster, grow quicker, and ensure we’re serving our customers the best way we can.
While a DevOps culture may seem like a natural progression for organizations looking to move faster, if you’re going to make the effort to move in that direction, I encourage you to look closer at NoOps. It has helped us move faster than we ever thought possible.
[ How can automation free up more staff time for innovation? Get the free Ebook: Managing IT with Automation. ]
Comments
This was a great read for me, thank you for sharing.