Devops in Federal Government a High Level Approach

Mon Jun 09, 2014 · 669 words

Disclaimer: This is a personal article. The opinions expressed here represent my own and not those of my employer.

DevOps is one of the biggest trends in the IT space, especially within the cloud world; many organizations that have DevOps in place have already started to see the benefits. However, just like with Agile, Federal Agencies see the benefits, understand the ‘awesomeness’ and want it, but don’t know how to do it and most attempts have not hit the mark. That being said, there is a strong opportunity for Federal agencies to move up the ladder of innovation as they start to embrace the public cloud just as NASA started doing in 2012 and more innovative approaches to IT.

What it isn’t

DevOps should never become another silo in an organization, it should bridge together development teams with operations teams under common missions and methodologies. If you are thinking of creating a DevOps team…stop; it should never be that some of your developers and some of your ops are ‘being devops’, nor should it just be the mass hiring of people who can develop and do IT operations. Just like with Agile, DevOps should make existing teams (the whole team) more efficient.

DevOps is not a one-month, one-quarter, or even a one-year process for Government agencies; it is an ongoing, transformational process that takes time. Agencies are not startups and inherently not as nimble, but that does not mean they can’t change and innovate; what Government needs is guidance and proper evangelism.

Lastly, it is not Agile, and it is not Continuous Integration/Deployment. These components fuel and build toward DevOps, and are great performance boosters individually, but alone do not constitute DevOps.

So what is it…really?

It is a philosophy. As quoted brilliantly in this blog:

“Devops means giving a sh** about your job enough to not pass the buck. Devops means giving a sh** about your job enough to want to learn all the parts and not just your little world.

Developers need to understand infrastructure. Operations people need to understand code. People need to f****ing work with each other and not just occupy space next to each other.”

True DevOps necessitates a real culture change to reap real benefits, and if Government agencies want real innovation, they’ll embrace it. It isn’t likely that every agency will change culturally. In fact, very few will…ever.


Bad Employees. It’s no secret that in Government it is very difficult to remove bad employees no matter what the definition of ‘bad’. That being said, an agency might find itself where some or most of their ‘legacy’ developers/operations staff don’t care for Agile, CI/CD and certainly not DevOps. One of the bandaids to this problem has been to outsource development and operations work to contractors. Has it worked? Not always.

Fear. Why do agencies institute Change Control Boards that oversee all changes to production environments? The real answer is fear. DevOps can serve as a relief of that fear in the long-term. Why? When it becomes faster to rebuild your entire application and its infrastructure from scratch than to debug a problem, then you will see agencies start embrace the Facebook ‘move fast and break fast’ method of developing applications.

Tradition. “It’s not for us” “It would require too much work” Running of the Bulls: Just Because You've Always Done It That Way Doesn't Mean It's Incredibly Stupid The picture should say enough. If you lead an agency and you really love the phrase “If it’s not broken, don’t fix it” then DevOps is not for you, nor will it ever be for you, and your history will eventually get overwritten by someone who embraces Continuous Innovation. No sugarcoat.

What to do? Tear down the silos of ops and devs, physically/organizationally place them together then migrate a single application, develop it under Agile methodologies, develop its CI/CD architecture…and repeat.

The end goal is fast development, fast deployments, and fast feedback. As an agency your efficiency will blossom, the cost of making mistake will spiral downward, and your tech staff will function as a family and not as segmented tribes.

Back · About · Blog · Projects · Contact · Home