From DevOps to the cloud there’s a seismic shift in how government organizations work with IT, yet, that shift is perennially thwarted by a lack of operational agility. In fact a staggering 87% of federal IT managers said they can’t develop and deploy new systems as fast as the mission requires, citing delays from operational, policy, and security requirements. That’s a problem.

But if the commercial world is being successful at IT innovation and responding to market and customer demands, how can government IT catch up and get their work done as fast as the mission dictates?

A common theme undercuts many of these challenges. If agencies are to accomplish either DevOps or cloud or both, then automation is an absolute must.

What is IT Automation?

Think of automation as the Holy Grail of complete end-to-end application lifecycle management – i.e. the ability to do something once and then run it anywhere.

In a fully-automated and agile organization, where you actually deploy your workloads (bare metal, virtualized servers or the cloud) is really less important than how you actually define those workloads and work with them in your environment. What automation enables you to do is to have a much more cloud-ready posture and also a posture that allows for the rapid digestion and integration of new technologies,” explained Justin Nemmers, director of public sector with Ansible, a DLT vendor partner and provider of simple, agentless approach to IT automation during a recent webinar.

Where does DevOps Fit into This?

To quote Wikipedia, DevOps is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other IT professionals. Essentially, it helps agencies more efficiently manage the application development, deployment and maintenance process.

The thing is with DevOps is that it’s traditionally a forward-looking approach, as Nemmers explains: “Many organizations look to implement DevOps in new green field environments but rarely look to apply it in their existing environment. But there’s a significant advantage to implementing DevOps and more agile methodologies using your existing legacy environment – that’s where most of your budget, time and effort are concentrated.”

But DevOps in Legacy is Hard

Applying DevOps in traditional environments has its challenge. Entrenched methodologies and existing investments both present impediments. Reuse is also difficult. “When you step through a traditional IT management and development process, the reuse of all the components isn’t one of the things that you thought of. As a result it’s hard to take the build process for one environment and leverage it in another,” said Nemmers.

DevOps also requires you to span multiple teams. “People don’t like change. So how can you incentivize and promote the adoption of new technologies that might very well make people uncomfortable with how they need to do things?

Ultimately, it comes down to communications, says Nemmers. “Your ability to leverage communications, can help with all these challenges.”

DevOps Needs Automation

This is where IT automation comes into play. IT automation can streamline communications across teams, and aid in collaboration and the reuse of people, processes, and (often) technology.

Organizations have a massive amount of information and skills wrapped around how they’ve been doing things, so finding a way to automate those pieces and make them available to other teams for consumption is a great way to start down this path,” explained Nemmers. “Enabling reuse will also make organizations a lot faster based on the fact that development no longer needs to spin their wheels waiting for resources. They can just click a button and get access to a production-level resource immediately that meets all the requirements that the infrastructure team needs to step forward.”

When you automate this process it becomes very easy to take that and deploy it across several instances including AWS, bare metal hardware or a virtualized server. As mentioned above, it’s less important where these applications are deployed than is your ability to automate huge components of that process.

With automation comes repeatability. Whatever process you’ve laid out can be met end-to-end every time and when it’s not the reasons why will be very clear – making troubleshooting, deployment and literally everything in the stack easier.

Bringing Everyone Back to the Same Language

To return to the communications benefit of IT automation, Nemmers had this to say:

Organizations need a way to bring everyone back to the same language. Ansible is the only automation engine that can automate the entire application lifecycle and continuous delivery pipeline, but it’s also the only tool that allows your entire IT organization, regardless of their responsibilities, to speak in way that is human readable but also machine readable.”

Ansible does this by allowing everyone to maintain a set of playbooks and roles around their own view of the world but simultaneously share those descriptions and definitions across multiple organizations. So as dev test and QA undertake the deployment process, they are actually writing playbooks that define how the application is deployed. When that application is delivered to operations and management teams they also have playbooks that allow them to test application deployment in that environment without breaking anything – with the click of a button.

Once deployed, teams can continue to verify and validate the deployment to ensure the application still meets the specifications defined by the development team.

ansible-playbook

Essentially, everyone is on the same page and everyone can describe to everyone else what their view of the world looks like.

Even if that’s the only thing that you do with Ansible, you’ll be amazed at the rapidity in which you are able to do the same thing that once took forever in your environment,” said Nemmers.