Live Demo
Blog   >   DevSecOps   >   How Threat Stack Does DevOps — Series Overview

How Threat Stack Does DevOps — Series Overview

Pete Cheslock, Threat Stack’s Senior Director of Operations, has just published a four-part blog series that gives deep insights into his experience “doing DevOps” at a variety of companies — in particular, his highly successful experience building DevOps practices into the fabric of Threat Stack virtually from day one.

We encourage you to read the entire series: It’s loaded with great accounts of what works and doesn’t work in real-life environments  — there’s nothing academic about Pete’s approach — and also offers up lots of practical advice you can draw on if you’re trying to figure out the best way to implement DevOps in your organization. But before you dive in, we thought we’d offer up a reader’s digest version to get you going.

For the full posts, follow the links below:

Part I: Best Practices in the Wild

Pete starts out explaining that the term “DevOps” is often misused, and points out that “many companies want to reap the benefits of DevOps without making changes to their organization.” He warns, however, that DevOps is more than just a term to bandy about, it’s more than just tools, and, by the way, there is no magic DevOps bullet!

By the end of this post, it’s clear that “DevOps Lite” doesn’t exist, and if you want to reap the significant rewards of DevOps, you need to make a serious commitment to understanding and managing the complexity of cloud environments, distributed systems, open source and home-built applications — and engineering them all for uptime and availability for customers.

In Pete’s words: “DevOps is a cultural and professional movement. It’s is a way for everyone in the engineering organization — developers and ops pros alike — to work towards a shared goal. At its core, it exists to empower teams to meet the growing demands of a business. At Threat Stack, it has been key to our success from day one. We use the principles of DevOps to rapidly turn ideas into reality while maintaining both quality and security.”

In the rest of the series, Pete outlines the three underpinnings of successful DevOps:

  • Engineering for Rapid Change
  • Measuring and Optimizing Systems Health
  • Empowering Engineers to become accountable for the systems they build

Part II: Engineering for Rapid Change

In a nutshell, you can’t say that you are successfully “doing DevOps” at your organization unless you are able to deploy code rapidly, securely, and automatically. That’s why engineering for rapid change is an excellent place to start when it comes to making DevOps a reality at your organization.

If you want to stay ahead of your competitors and your customers’ needs, you must change, grow, and scale your technology. The difference between a healthy business and a failing one is often how well they each adapt to change. There is always, inherently, some risk that comes with making changes. DevOps is a way to gain assurance and reduce risk by building in collaboration along the way.

Part III: Measuring and Optimizing System Health

If you don’t have a way to define, collect, and act on metrics, you’re flying blind. You have no ways of quantifying how your systems are performing and no way to make ongoing improvements. So it’s critical to start baking application and infrastructure metrics into your engineering organization as early as possible, using appropriate tools to gather, display, and share results.

Part IV: Making Engineers Accountable

If you don’t give your engineers responsibility for making decisions that ensure the health and security of their code, you’re not empowering them to make a full commitment to its quality. And you’re not taking advantage of a major opportunity to create a level of responsibility and teamwork among all the members of your team and to share the belief that everyone is working together to achieve the same goals.

Pete addresses the issue directly: “If your goal is to keep engineers out of production because ‘they’ll break stuff,’ recognize that you are likely running their code blind anyway. It would be much better to teach them how to take ownership of the health and security of their code.”

Giving responsibility doesn’t have to increase risk: “When we give our engineers access to production, we don’t give them a blank check to do whatever they want. But we do empower them to make decisions that ensure the health and security of their code. At Threat Stack, we know that giving engineers access to the systems required for this can be done safely.”

Final Words . . .

We’ve just skimmed the surface of the content Pete delivers in his DevOps blog series. Again, we encourage you to read all four parts to get the full benefit of Pete’s years of working, experimenting, and improving DevOps practices in the trenches. Hopefully, his story will guide — and maybe even inspire — you to commit to DevOps, and to do it right at your organization.

There’s Also a Webinar!


In an upcoming webinar, Pete will be discussing what DevOps really means, why it’s critical for secure business growth, and how you can “do DevOps” effectively at your organization. Tune in to hear his no-nonsense advice and real-world experiences on implementing and embedding DevOps best practices at rapidly scaling organizations.


  • Live Tuesday, March 27 at 1:00 p.m. EST