Production Docker, automated workflows, open source projects and microservices are just some of the ways that Booz Allen is helping the General Services Administration (GSA) modernize its IT operations. And frankly, after talking to Nirmal Mehta, the lead architect on its recent project, I became a little embarrassed for you DevOps-born startups.
In my circle of friends, the frustration and sarcasm used to describe government processes is a common pastime. And it’s totally fair. Even without being an insider, you can still easily approximate the magnitude of wasted money due to bad business processes and dated IT operations.
But things are turning around. Beyond the early negative press, the issues with healthcare.gov made very clear that the gap between large enterprise and government IT and the modern development shop is massive. And even more recently, the use of private sector hackers to unlock phones, and the continued efforts to recruit from and partner with Silicon Valley show that the government needs the best and the brightest technical help.
One government institution, the GSA, took the modernization challenge head-on. It selected Booz Allen Hamilton to lead the charge and build a new development platform—one that will ensure dev projects deliver results faster, at higher quality and are more systematic.
The GSA is an arm of the government responsible for managing the contracts and processes for vendors that wish to do work with the government. If you have sold to the government in any fashion, you are familiar with it. The administration oversees more than $1 trillion in transactions and more than 300,000 vendors and contractors. To manage the processes across a wide range of categories, it requires many web and mobile applications, with new ones coming on board every year.
Before working with Booz, GSA’s IT ops were about what you would expect—big, slow and risky. New projects took months to get started, with solutions that could take more than a year to complete, and they were ultimately subject to dreadfully low sub-30 percent success rates. (Watch this video and pay attention from the 8:30 point on).
The GSA came to a point where it fully recognized the hard cost of this way of operating, and the indirect cost of maintenance, tech support and unhappy customers on both the vendor and government-consumer sides. It knew something had to change.
Booz’s solution was not 100 percent unique, but its implementation was above and beyond. The firm decided to build a unified platform as a service (PaaS) that served as a portal for all new development projects. In some organizations, this is called “shared services.” But with Booz’s platform, it went beyond just application components.
The users of the solution would be development teams who were awarded projects. Once awarded, they would access the platform and create a service that consisted of applications and microservices. They would be given immediate access to a private repo via GitHub Enterprise, which would also include Docker Compose files.
Then, the teams were off and running. As soon as they made their first commit, the system—already wired up and driven by Jenkins—would pull, run tests and deploy containers to dedicated nodes in a continuous integration (CI) environment, run on FedRAMP-compliant AWS regions. Then the instances were automatically given IPs, where the development team could begin testing.
In addition to a prebaked development and deployment system, the platform provided the development team an entire DevOps stack, giving them “the entire application and lifecycle environment to build their application,” explains Mehta. That included everything from identity management and infrastructure-as-code to business intelligence (BI) and even release automation, so that after the applications were deployed, the teams had what they needed to run updates, measure and learn.
The idea is that a development team with this platform only needs to think about the logic of the application, not process. And now, at the organizational level, there is oversight, continuity and reliability—something which the GSA had never seen before. After the changes, instead of dealing with long contracts and RFP processes, the CTO could approve bids and get development up and running in days, and create solutions in months, not years.
Mehta’s team was responsible for architecting the system, putting it all together and vetting the “marketplace” of tools made available to developers. By doing so, people were able to make sure the proper security considerations were—and are—made, and that the tool configurations, Chef scripts and Docker images stay consistent.
The whole thing was built based on a set of principles. Cloud-first, secure foundation and, to my surprise, open standards and open source. The U.S. government, which fought cloud and open source for so long, is now one of its biggest champions. “I think 2015 was a huge tipping point in gov open source adoption. I think we have hit an inflection point for sure, and I’ve realized that DevOps really implies open source,” Mehta says.
If this is too hard to believe, just check out Booz Allen’s Jellyfish project (which has become part of the ManageIQ project), and this open source policy document in the GSA’s own public 18F repo, which encourages entities to use open source technologies it has developed.
This does not mean the GSA won’t spend money—that is not the driver of open source tools. The driver is cross-pollination, giving back and building better code through standards. Where warranted, such as with wanting full Jenkins support via CloudBees, the GSA will invest in technology. Jenkins is the heart of the system, and basically the home of all of the platform’s workflows and automation. Having the backing of CloudBees is important. Plus, CloudBees is a GSA vendor. It also has become one of Docker’s early customers. I can’t imagine the love it gets from those kids.
Often when I do these case studies, the solutions are too new to validate long-term success. But the platform has been up for six months now, with several development teams and beta applications deployed, which means the system works! The path to prod is still manual and belongs to a separate team, but there are goals to automate that as well.
A government agency is finally more focused on results than process. (If you have ever been through the RFP process, you know what I mean.) “The government is realizing that it is not sufficient to give the modern user, who expects technology that works [to stay with] legacy applications,” Mehta says. The platform also allows the GSA to have smaller contracts, and in theory, smaller and better development teams who don’t have to worry about development operations overhead.
When I asked Mehta if his project is the norm or just a fluke, he said “more and more companies are asking us about DevOps, not just cloud migration. We know that if they just do a cloud migration, they are going to create more problems faster.” He believes that even if DevOps is not explicitly stated, federal and local governments do care about modern IT ops—if not because they want to, but because they have to.
So, can you say you have a fully automated full-stack container-driven platform that spans multiple applications and multiple development teams? Chances are no, but you could, and you should. Mehta and team have proven that even the government can have a Ferrari of a development environment and stay on the cutting edge.
To learn more about Mehta’s project, watch his session at DockerCon2015 here. And check out this presentation from Navin Vembar.
