Unless you’ve been living in a bomb shelter for the last five years, it’s impossible to avoid hearing about the struggle IT organizations have with supporting DevOps initiatives. Those of us on infrastructure or information security teams are already under pressure to implement and streamline processes to improve efficiency in the midst of budget cuts and downsizing. Now we’re being asked to accommodate the seemingly unrealistic schedules of Agile developers. It often feels as though we’re working with two-year olds in the midst of an epic “continuous deployment” temper tantrum.
Those of us who have some tenure in IT remember the bad old days. Sleeping under cubicle desks while performing off-hours maintenance or trudging back to the office at 3:00 AM because someone made a change that took down the network. It was the Wild, Wild West and organizations started implementing change management procedures to keep the business happy. But then a shift occurred. While we were busy trying to improve the way we manage change, many organizations became risk-averse. They have meetings about meetings and it seems as though their IT staff spends more time talking about work than actually doing any. The stage was set for a DevOps revolution.
Does Agile have value outside of a few eCommerce companies or is it simply confirmation bias for technology chaos? Only time will tell, but organizations hungry for innovation drool when they hear Etsy pushes 50 deploys per day. You heard that right, per DAY. While DevOps organizations seems to be moving at warp speed, others stumble trying to implement that many changes in a month. What’s the secret? How do companies like Facebook, Google and Amazon stay nimble while maintaining some semblance of order and security?
Don’t be fooled by snazzy lingo like “sprints” and “stories,” DevOps still relies on process. But the requirements of Agile development demand rapid change. The main question infrastructure teams ask is how to support this environment safely. And how do security teams manage risk and compliance without an army of analysts to keep up?
The only way to achieve DevOps speed while minimizing risk is through a two-pronged approach: automation and self-service. Standards are useful, but being able to instantly spin up a system, application or container based on those standards will better meet the needs of your developers. When you manually build servers and install applications, then ask security to assess them, you’ve wasted precious time with process “gates.” Approach everything as code, something to be modularized then automated. Google and Facebook don’t perform manual code reviews, they use frameworks with pre-approved libraries built on standards. This eliminates the need for frequent manual code reviews.
Moreover, implementation times are shorter when teams can fend for themselves. It’s critical to deploy tools that allow developers to be self-sufficient. Start to think like a programmer, because, as Marc Andreessen pointed out, “Software is eating the world.” Most hypervisors have excellent orchestration capabilities and every self-respecting public cloud has various APIs that will allow you to implement your own deployment scripts or integrate with existing help desk applications. By spending time up-front to develop automated processes and creating self-service front-ends, you can actually maintain control over what your developers are able to do, while keeping them working.
Embracing DevOps doesn’t have to mean kicking security controls to the curb. But it will require security staff with skillsets closer to that of a developer, those who can think beyond a checkbox and provide solutions, not roadblocks.