By the time I had spent 20 years in infrastructure, I thought I knew how it all worked. Some new technology comes along and is introduced into your organization by an excitable and enthusiastic group that gets business or technical value out of it. Then it usually gets harder—to scale, maintain, or secure—so it gets handed over to the infrastructure team.
But then along came the cloud and DevOps, which changed the very concept of infrastructure. Instead of plugging tin together, or being the hands and eyes of the operation, we are now asked to build tools that are so clear and simple that an application team can use them without guidance. And we're expected to find a way to deliver the necessary infrastructure without exposing the system passwords we guard.
That's not who we thought we were. Fortunately, DevOps thinking is helping our teams find a way forward.
Everyone needs infrastructure
Sometimes the true value of a technology can only be realized by scaling, securing, and maintaining it. When that happens, much of it becomes "infrastructure" that gets handed over to the people who make sure that reliability, maintainability, and resilience just happen. My favorite definition of infrastructure is that it's the part of the built environment no one notices until it stops working.
When cloud and DevOps came along, the first half of the hype cycle looked about right. But then I started to pay closer attention. DevOps goes deeper than technology—and trying to address it just with tools is a path to failure. DevOps goes to the heart of what our teams are trying to achieve with technology, and talks openly about how we need a culture that supports our people, our teams, and our business. And that's a train I want to board.
But I'm an infrastructure guy. A colleague once told me that our job is to stop the developers from running with scissors. One of my early lessons as a database administrator came from a senior colleague who told me that our job is to start with a "no" response. The application team had to convince us that something should be allowed. Another associate, with rather a different perspective, introduced me to the term "cult of the database administrator."
[ Special Coverage: DevOps Enterprise Summit London 2019 ]
Who is 'ops'?
And, besides that, we are ops—right? We are the specialists who make sure stuff keeps running, and maybe tune applications. But we aren't coders, programmers, or developers; yes, of course we write code, but not "business applications." And our specialty means that we have the superuser passwords.
So, when I first heard the term DevOps, I assumed we were the "ops" part of the word.
To my astonishment I soon discovered that people in the business-facing lines were the ones on call for application failures; they were the ones that had to deal with stuff that we never saw. They, not the developers, were the ones who called us in the middle of the night. And they were the people who the devs thought were ops. The developers were simply the people we worked with during office hours on "projects."
That's when we dedicated time to building development environments, understanding applications, and helping architect and deliver high-performing and capable infrastructure. But that wasn't ops, to us, since it only happens during office hours. And it wasn't production, so it always got put aside when there were real operational issues.
As it turns out, our development colleagues get frustrated when they can't get their database change deployed in development for three days due to a production issue, with the result that a business delivery might get missed. Turns out that our developers don't look good when that happens, and they look for clever ways to reduce their dependency on infrastructure.
And then the folk on the infrastructure team get frustrated, because the first time they get to see something is when they must put it into production. They don't understand it, but they are still the only ones with the production passwords.
Infrastructure is still part of the system
And so, in reality, infrastructure supports both dev and ops. That sounds so obvious when you write it down. But it means that infrastructure teams aren't actually dev or ops in this view of the world, even though they are critical to DevOps. An existential crisis appears on the horizon.
The solution? Systems thinking. Infrastructure is part of the system. We need to provide the stuff that helps development capabilities to run at speed. Which is where the cloud comes in.
To an infrastructure person, the cloud simply looks like a set of infrastructure designs and interfaces that enable application teams to get the things they need without having to wait for an infrastructure person to do it. But the cloud is more than that. Developers assume that infrastructure teams have thought in advance about capacity, redundancy, availability, and performance. And that is a wonderful challenge for an infrastructure person to have.
How do we design the environments we want, rather than waiting to be asked? How do we build in capabilities so that our customers can get (at least most of) what they want without bothering us (and then getting annoyed when we are busy)?
The result is GUIs and APIs that are so clear and simple that an application team can use them without guidance. And that can deliver the necessary infrastructure without needing or exposing those critical passwords.
And the same thing applies to operating these environments. How can we design and build operational infrastructure that provides feedback? Can we ensure that logs, capacity information, performance data, and all the rest are available to both ourselves and our customers without the need to connect to production?
And again, how do we do this while avoiding the need to use critical credentials and, even better, reducing the likelihood that anyone can, through error or bad intent, mess with the production environment?
Solving for time, cost, and quality
There are some easy answers to these questions, particularly if you are part of an organization that was born in the cloud. But most companies weren’t. For such institutions, this is a transformational challenge—and one where you need to take a staged approach.
One angle is understanding how development works, recognizing that it only delivers value to the business when the new code is working in production—and that this can be as valuable as the continuing return on code written years ago. Giving developers governed access to tools (e.g., via APIs) that let them build their own development and testing environments saves time that you can then use to deliver better quality.
Reliability, resilience, and security remain our core values, and we can retain or improve our standing by adopting the DevOps concepts of systems thinking, feedback, and continuous learning.
Where can infrastructure pros have the most impact—cost, delivery time, or application quality and features? In my talk at DevOps Enterprise Summit: London, I will cover both the existential crisis of the infrastructure organization ("'NoOps,' anyone?") and what we are actually doing to get out of the way of application development while keeping ourselves relevant. Culture change that delivers cloud capabilities and APIs that enable DevOps—what's not to love? The conference runs June 25-27.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
