One of the stumbling blocks starting to show in the agile/DevOps world is that speed of delivery and developer choice are asserting themselves as the primary worthy goals.
I’m a developer. I have that “look what I did” attitude when I tackle a particularly tough problem and I love it when an environment lets me choose a toolset that helps me achieve my goals faster (or lets me play with tools I have been eyeing for a while). I want to solve problems quickly, and have no issue with stand-ups to show my progress.
http://www.flickr.com/photos/61056899@N06/
But we’ve lost sight of the whole longevity issue, and far too many of us have lost sight of the whole “necessary restrictions” thing, too, which is related. The security environment did not change just because your team went to DevOps with Agile, and what must be supported to keep your cool app up and running didn’t change—at least it didn’t change conceptually. And that’s where we start seeing issues.
Lori and I were talking this morning, and I came to the conclusion that Ops/DevOps teams would be warranted in saying, “Okay, you want that cool gizmo new thing that is totally outside our architecture, YOU support it.”
Think about it. Between Agile and “Developers are Kingmakers,” we have set different Dev teams using different environments, from languages to databases to deploy targets to even load-balancers. And while there is a lot of talk about “chuck it over the wall” being gone, the truth is that the responsible Devs will be responsible for code in production, but not the infrastructure that we’re allowing them to inflict upon the Ops/DevOps team. And all of this is done with “timely delivery” as a mantra.
The problem today is different for security. In security, it is seen by many in the DevOps crowd as inherently slowing down the process. And this, in our current fever dream of rapid delivery, is seen as inherently a problem. Time to step back and see where security can benefit from and add to DevOps. That movement is, thankfully, starting, but needs to be more prevalent. My blog about DB monitoring is an example of DevOps benefitting security, and increasingly the SecureOps movement is showing promise in integrating security with DevOps.
Do yourself a favor. Look around your IT org. Are there apps running that are 20 years old or older? If yes, speed is still important to business agility, but you have to acknowledge that every unique database/load-balancer/whatever that you introduce is potential technical debt. If you’re working on a core system replacement and have decades-old apps running in your world, chances are pretty good that 20 years from now, someone will be figuring out what you were doing.
Don’t make it harder than it has to be for future-you. Stick as close to standards as your development effort will allow. It’s been a long time since companies successfully enforced database standards, for example, but having a first choice means that support and training can focus on the first choice. And that 20 years from now, some poor new developer will be able to go “Oh, it’s another MariaDB app.” instead of “What the heck is SuperFastDBForMe, and why are these queries written in pig-latin?”
And don’t make it easier for hackers by demanding that security not slow down the process. Encourage them to move faster, but it’s not all about speed. In fact, both security and ops were never about speed; they were about thoroughness. The environment and the apps that run in it need to be as secure as is reasonable, and the production environment needs to be as stable as possible. DevOps tends to find itself at odds with both of these facts, sublimating them to the desire to be “agile.” Yes, automation helps with stability, and I’m a huge fan of that. It also helps with the knowledge crunch, but it is more of a shifting of tribal knowledge than an elimination. Someone, in the end, has to be able to modify tools to face the new reality, and that person needs much the same knowledge that they need to do it manually.
The goals and results of DevOps are great, but if you’re working for an enterprise that will have long-lived apps, just make certain you’re not sacrificing more than you’re gaining. Business agility matters, but so do both security and long-term technical debt.
Balance, as always, is the way forward. Strive for it early, or struggle for it later.
