Let’s talk about DevOps.

Not just the trendy term you hear thrown around, but the real deal: its history, how it’s changed, and my perspective on where we are now.

Remembering the Early Days

In the early days, the focus was largely on breaking down silos between development and operations teams. The goal was to increase delivery velocity, improve reliability, and foster shared ownership.

The standard operating procedure up to this point was that devs would create something, hand over a really poorly documented runbook (if we got any documentation at all) on how to install it, and then expected the pile of duct tape that ran in the dev environment to magically work in production. Typically on a Friday afternoon with no heads up. I managed massive server farms that worked this way, requiring equally massive heroics from the ops team to get a service up and running (or limping along).

It sucked for everyone, especially the customer.

We saw the rise of tools that helped with these problems, like Git for version control, Jenkins for continuous integration, Docker for containerization, and tools like Puppet and Ansible for configuration management. Monitoring solutions like Nagios were around to keep an eye on things. It was about automating manual tasks and getting teams to talk to each other, maybe even over 🍕 pizza. Automation was a must-have skill, along with process knowledge and soft skills like collaboration.

But if you think DevOps is just about automating a few things, you’re missing the bigger picture.

It’s evolved into a seriously sophisticated discipline, and understanding that evolution is key.

Before DevOps, There Was Pizza

📖 Story time! In 2011, I took on a role as a network operations manager for a small group of IT professionals at a small startup that was rapidly growing. This is the same team I wrote about in A Story About Dale Furbur, a Really Good Dude.

The startup company that hired me had pretty typical issues for that period of time – a rapidly growing client base, massive hiring internally, and a dev team that physically sat in an entirely different part of the building in isolation from my team. The dev environment was an old, piece of crap server sitting under someone’s desk. Release code was painful, slow, and extremely silo filled.

Testing? Haha! No, that’s what production was for. 😉

Devs want to move fast and release code that is used by clients. It’s their dopamine hit. And I just wanted servers and storage arrays that weren’t always falling over into death spirals. But how does one make that desire a reality?

My first step was simple: get everyone talking. It’s hard to fix things when you can’t feel the pain, and I wanted both sides to better understand the pain of one another.

But how do you get two teams that have some bad blood between them to talk? The answer: pizza.

I found that our local pizza shop, Sarpino’s Pizza, offered deluxe pizza coupons that easily feed 2 people for cheap with unlimited coupon usage. I sent an email to the developers and operators with a sign up sheet – find a buddy, pick a pizza and toppings, then drop by my office with a few bucks and I’d order the pies for a Friday lunch hangout. Who could say no to a hot, delicious, high quality pizza for like 4 bucks?

The first pizza hangout drew over a dozen participants from both teams. People who worked in the same building but never met each other or knew each other’s names were finally in the same spot together sharing a meal.

There’s something special about having a meal together – it scratches at what makes us HUMAN.

And it was fun! 🙂

We swapped stories and realized how similar our situations were and how much we wanted to see our startup grow and prosper. Over time, the Friday Pizzas became legendary throughout the dev and operations teams, and we ended up taking over a large part of the cafeteria.

To this day, I am still friends with several of those folks from over 14 years ago.

Now that we actually knew each other and started TALKING, which is the “Culture” in CALMS, things started to rapidly change. When problems arose, we’d huddle together as one team, educate each other on the situation, and brainstorm ideas. My team learned all about environments, release processes, version control, and how the code worked. And because of that, we could rapidly MAKE EVERYTHING BETTER.

Now days we call much of that “DevOps.”

At the time, it just felt like common sense.

It All Changed with Cloud-Native Architectures

But fast forward to around 2019, and things really started to shift.

What began as improving collaboration and basic pipelines transformed into something demanding much deeper technical expertise. The biggest driver? The dramatic rise in system complexity, largely fueled by the widespread adoption of cloud-native architectures.

We moved from monolithic applications running on premises to distributed, microservice based applications in the cloud.

Technologies like containers and Kubernetes went from emerging trends to core components. This brought awesome benefits like increased scalability and resilience, but also significant complexity in managing these distributed systems.

The Onion Deepens

This is where the “deeper layers” of modern DevOps come in. It’s not just about basic CI/CD anymore. Infrastructure as Code (IaC) became table stakes, automation maturity went beyond simple pipelines, and security shifted left with DevSecOps. We moved from just monitoring infrastructure to needing end to end observability. And crucially, folks in DevOps needed to speak the language of software development.

Today’s DevOps professional has a wide range of responsibilities. They’re designing and building CI/CD pipelines, implementing and managing IaC, handling containerization and orchestration, integrating security, managing observability, automating operations, and managing cloud infrastructure. This requires domain expertise that is both wide and deep across areas like application and platform architecture, networking, branching strategies, building test environments, CI/CD pipelines, container architecture, tool building, and even cost controls.

I started talking about this upcoming shift in 2014 with my Stop Being a Minesweeper presentation while in the UK. I later experienced this shift first hand as a Delivery Director at Slalom, much of it discussed in my 2024 Forging a New Path to Equitable Justice – Platform Engineering for State Government presentation at both PlatformCon and DevOpsDays.

If you’re still living in the pre-2019 world, it’s time to pop your head up and stop ranting on your soap box about DevOps being a culture shift. Sure, you’re not wrong, but that time is behind us.

Summary

Ultimately, DevOps has evolved from a cultural movement aimed at breaking down silos into a technically sophisticated discipline. Like it or not, it’s essential for navigating the complexities of modern, cloud native software delivery.

What began as a cultural and procedural movement to dismantle the walls between Development and Operations … has evolved into a technically sophisticated discipline essential for managing the complexities of modern, cloud-native software delivery.

DevOps isn’t dead. But it has evolved.

You should, too.

(I’ve specifically omitted discussing AI in this post because there’s already enough slop on the Internet about it)

✌️& 💙