DevOps has been with us long enough now that there is a lot of legacy DevOps stuff running in all of the places I have eyes into. Ignoring items that are not actually working; those pieces that pose a serious security threat because they house vulnerabilities that have been fixed—there is a lot of “It just works,” piping in place and even a bit of “We’ve always done it that way.”

Considering DevOps is still often pushed as “the inevitable new hotness” by marketers, I find this interesting; the fact that DevOps is now the de facto standard across enterprises is a topic for another day. I want to talk about the stuff running quietly, relieving you of the need or desire to think about it while focusing on issues that do need you to think about them.

But that type of thing is exactly what created the need for DevOps in the first place. DevOps came in like a wrecking ball and forced you to look at the unnecessary steps that had built up around the items in the organization/culture/infrastructure, often around these very “This is just how we do it,” or “That ain’t broke, let’s look at this other thing, instead,” attitudes.

At Ingrained Tech, we have scripts that run our backups to the cloud. They are part of a fully automated process; we designed them to make sure our system of what gets backed up and when highly adaptable. The system runs like a champ every night unless we tell it not to.

Our cloud storage provider has come a long way since we first used their API to get the data up there and wrote those scripts. In fact, customers like us are the reason the provider keeps backward compatibility with those APIs. Which means it is time for us to revisit, use the newest APIs and see which of the many, many new features we want to take advantage of. “Good enough” is just that. The system isn’t broken—we get viable backups out of it (which we needed not too many months ago, so we know we get good backups), but we’re not getting maximum value out of it; we had to do a bit of hoop-jumping to get the data set back up the way we wanted.

Our simple backup routines are nothing compared to similar “good enough” arrangements I’ve seen in larger companies. “Good enough” arrangements that are creating larger and larger speed bumps that sometimes resemble the exact environment that made the huge gains of early DevOps implementations inevitable.

Take a look at your infrastructure and toolchains with a critical eye. Look for low-hanging fruit, and knock out some of the baggage that has built up. Schedule some process renewal days, where a team member or two specifically looks at everything in the environment with a critical eye, and see what they propose.

And keep rocking it. Speed bumps or not, you’re making the apps and infrastructure that keeps the entire company running. Remember that, and keep a smile on your face while you’re solving recurring problems.