We in the DevOps world spend an inordinate amount of time talking about tools and roles—and there are always new tools and modifications of roles to talk about.
Do you know what we don’t discuss as an industry? The day-to-day grind of being in DevOps. Oh, you can go to forums like Reddit and have those discussions with other practitioners, but pundits don’t discuss what it’s like to actually do the work. I secretly suspect this is because most of us pundits no longer develop code in general, let alone have a working DevOps environment. I certainly don’t code as much as I used to, and I develop more than many of my peers in punditry. For the record, we do have a working DevOps environment (two, but one almost never gets spun up) at my company, but I’ll be nice and won’t get sidetracked by talking about it here.
We’ve talked about it tangentially, but I wanted to be direct with you all. The vast majority of your organizations do not need to iterate non-stop. And the mentality that you cannot iterate too much is simply false. While the guard gates and German Shepherds that protected production from rogue developers in the past were overreactions, there should be a happy medium. Every time change is introduced in production, there is some amount of risk. And we have a ton of tools to limit that risk these days—feature flags to turn new functionality on/off, auto-run testing before the move to production, etc.—but there is still measurable risk. And “we can just roll it back” only works in small, unsegmented projects. Once you get into nested dependencies (microservices are a great example), then versioning starts to make rollbacks an issue. Knowing the interconnected relationships between what is being changed is a big deal. So it is not as simple as the ::shrug:: “Just rebuild and deploy without your changes,” crowd would have you believe.
And to a great extent, that is why this pundit doesn’t come out and blather about iteration speeds—the decision to iterate once every six months or every time Bob checks in code is very much an organizational/application one. How fast can the organization handle a full iteration, and how often does the application require it? The answer is rarely the insane number that vendors like to throw out to show you how great they are. There are a whole lot of organization/application combinations whose rate of change is slow enough that they could honestly schedule full-on iterations and plan updates around vulnerability patches in the underlying composite pieces. The majority only need to iterate over months. Very (and I stress very) few need to iterate even daily, let alone more than a hundred times a day. And they are indeed special snowflakes with super-tweaked environments.
It is kind of stunning to me that a portion of the rise of Agile and DevOps was to free up IT time because we were overloaded. And then once that was done, we decided to crank up the rate of change so that IT was … overloaded. A release takes DevOps time, DevOps time and security time. It takes resources to build, test and deploy. Don’t overdo it.
Build when you need to. Deploy when it is a benefit to customers. Keep rocking it. We’re out here using your apps, or your apps are grinding behind the scenes, keeping the business running. Either way, you know better than anyone what your app and your org need. Don’t follow the “10 billion deploys a day!” crowd; push for what works. And you are the SME in that department.
