Federal agencies are developing and releasing software and apps at a rapid speed. This haste comes at a price. Verizon reports that nearly 70% of the data breaches it investigated in 2019 were due to attackers targeting vulnerabilities in public-facing web applications. It also introduces compliance risk.

While there has been a steady increase in the adoption of DevOps in the federal government – 75% of CIOs report that their organizations are now adopting it – many public sector organizations struggle to adapt to the DevOps culture.

Challenges to Using DevOps in the Public Sector

Digital transformation, application modernization, faster service delivery – these terms are being thrown around so much that they’ve become so ubiquitous as to be meaningless.

What is digital transformation after all? For me, the best analogy is Blockbuster versus Netflix. Failing to anticipate the shift to on-demand and streaming entertainment, Blockbuster failed to futureproof its business model. It resisted digital transformation, and paid the price.

With pressure to better respond to evolving agency needs, do more with less, and all that jazz, government agencies are turning to modern tools and DevOps practices to help developers become more efficient in delivering innovative solutions.

Oh DevOps, DevOps.

You hear time and again how it’s the future of application development and deployment. You’re told you need to implement it and engrain its best practices across your organization.

But making a shift from the old way of doing things, however error-prone, slow, or disruptive it may be in comparison to the agility and utility that DevOps promises, is no easy task.

Open source application development and delivery tools provide compelling value for developers and often fill holes that commercial tools, with their relatively fixed function set, can’t fill. But a new report from Forrester, suggests that open source tools can’t do it all.

After surveying 150 U.S. application development and IT professionals, Forrester found that open source tools play an important role in the software delivery pipeline, they aren’t a silver bullet.

When looking to build a microservice, you may have come across two pieces of advice; start with a monolith, and don’t start with a monolith.  For a good number of us developers in the trenches, the point looks irrelevant because we already have a monolith, so one to-do completed and moving on.  Not so fast!  The discussion goes beyond the greenfield experience of where to start.  Instead, within the “don’t start with a monolith” advice

With the growing necessity for companies to digitally transform, a lot of emphasis has been given to the microservices architecture, with its improved scalability and distributed design.  While these facets may apply to some, adopting microservices is equally about the universal DevOps goals of improving lead times and reducing the batch size of releases, ultimately leading to more flexible and frequent production deployments of higher quality software.

Although still in its infancy in the public sector, making the shift to DevOps methodologies is starting to catch on with many government agencies, including the U.S. Citizenship and Immigration Services, the EPA, and Nuclear Regulatory Commission.

As you may know, with DevOps, IT tasks and application deployment that would normally take months or years, now take weeks.

But Rome wasn’t built in a day.

2016 is/was the year Gartner predicted that DevOps would go mainstream. But a big challenge for government IT operations is how teams can modernize software development while still operating their traditional apps and infrastructure. After all, according to federal CIO Tony Scott, the U.S. government spends 76% of its $88 billion IT budget on operating and maintaining legacy technologies – that’s three times what is spent on modern systems.