Two of the hottest buzzwords in IT right now are “DevOps” and “containers.” Yet as popular as they are, the terms still vary in meaning and can set unclear expectations.
In fact, a lot of different meanings come to mind, for the very few who even know what DevOps is. We often think of things moving faster, continuous integration and developers quickly deploying to production. However, as we learned in GovLoop’s recent online training at the Government Innovator’s Virtual Tech Day, DevOps is more than just achieving technical results. It’s about improving the culture and business operations of an organization.
Simmons Lough, Software Architect at the U.S. Patent and Trademark Office (USPTO), and Chuck Svoboda, OpenShift Practice Lead at Red Hat Public Sector, offered clarification as to what DevOps really is, how to innovate with DevOps and containers and how government agencies can leverage best practices in applying DevOps.
To set the record straight, it’s important to clarify the definitions of DevOps and containers. DevOps is a software development method that stresses communication, collaboration, continuous feedback, experimentation and integration between software developers and IT professionals.
Containers isolate your applications from wherever they’re being run. That way, developers only install what’s needed to run the application and nothing more. Developers can also develop directly in a container, as it gives a separate network and storage space without the additional burden of building and running a virtual machine.
But just developing applications and services in containers is not enough to achieve more than technical results. You also need something to manage those containers.
Take the Kubernetes container manager, for example. Kubernetes (commonly referred to as “k8s”) is an open source container cluster manager originally designed by Google and donated to the Cloud Native Computing Foundation. It aims to provide a platform for automating deployment, scaling, and operations of application containers across clusters of hosts.
The DevOps Cake
One easier way to think about DevOps and containers is to picture a wedding cake, as Svoboda suggested. The top layers are more about your organization’s business results while the larger bottom layers are technical details. It would be stacked accordingly:
- Platform on top
- Management in the middle
- Container at the bottom
“Specifically, you would have something like OpenShift on top, Kubernetes as the containment manager of the project in the middle and your particular container at the bottom,” Svoboda said.
Platforms like OpenShift are helpful because they are built both for traditional and cloud-native applications. Additionally, solutions like OpenShift develop, build and manage applications in containers, without having to focus on building the containers themselves. Accoding to Svoboda, “Red Hat OpenShift is enterprise grade Kubernetes and a whole lot more.”
In addition to layering your DevOps cake correctly, Svoboda emphasized the importance of automation. “Foundation still matters and you need good virtualization and a good software platform. The only you can do DevOps is if those details are automated and taken care of for you.
DevOps in USPTO
To put it into perspective for other agencies, Lough explained how USPTO is using DevOps to achieve their desired technical and business results.
“We think of ourselves as a business and DevOps is a way to drive that business value,” Lough said.
To process about $3 billion annually in fees, USPTO applies DevOps through their Fee-Processing Next Generation (FPNG) initiative. FPNG is a top-to-bottom redesign of the USPTO’s fee collection processing and refund system. The Office of Finance is currently researching ways to streamline trademark fee-payment processes, including accepting and recording fees, administering deposit accounts, issuing refunds of fee payments and interfacing with applicants on financial matters. The vision of the FPNG effort is to streamline and standardize the fee-collection and refund process, while minimizing manual handling and data entry.
It may sound nearly impossible for other agencies to streamline their development and operations given the realities of bureaucratic environments, but Lough was encouraging. “We didn’t go from 0 to 100 miles per hour overnight,” he said. “The reason we were able to get to the first stage is that most of the technology was ubiquitous. For other agencies, the plumbing and technologies are already there. It’s just using those effectively.”
To help with compliance requirements – a concern for many government agencies – Lough added, “If we can do DevOps, anyone can. Additionally, our type of automated pipeline allows us to be on the offense with compliance and projects rather than defense.”
What You Need for DevOps
Both Lough and Svoboda agreed that, when agencies are ready to consider DevOps, they should be sure that their platforms have the following critical features:
- Self-service provisioning: Developers can quickly and easily create applications on demand directly from the tools they use most, while giving operations full control over the entire environment.
- User interfaces: Developers have direct access to a rich set of tools, a multi-device web console and an integrated development environment.
- Scalability: Applications running on the platform can easily scale to hundreds of instances in a matter of seconds.
- Collaboration: Users can easily pull different resources directly from the platform itself to maintain project and initiative schedules.
The most important consideration for government agencies is to start out with what they’re comfortable with. DevOps and containers are not going anywhere for now, so there’s still plenty of time for governments to learn more about integrating these innovative strategies to help achieve desired technical and business results.