bridging the gap between development and operations

It is increasingly common to find the word DevOps being bandied around in office corridors, but what does it actually mean for your typical System Administrator?

Certainly in the past I’ve ignored DevOps mainly because of the word Dev and its association with programming. I just didn’t want to be a programmer. I’ve typically seen it as a separate role which fits in between sys admins and devs, but more recently I have seen that this is actually where System Administration is heading.

Most organisations have teams split between a project support function and a  production function. This allows projects and development work to be separated from support so that appropriate priority and focus can be given to each activity. With the move towards “automation, automation, automation…” across IT in general, sys admins are having to look closely at the manual work they do and how this can be automated and repeated across multiple systems.

As an example, a large global education domain customer I’ve worked with utilises Red Hat Satellite features such as Kickstart and Snippets to automate the installation of virtual machines in combination with Cobbler to streamline the build process. Using these technologies reduces the duplication of scripting by parametrising and re-using functions for different configurations. This is a first step on the way down the DevOps path.

Many other technologies exist to continue the journey. Again, the large education domain client has begun introducing Red Hat Openshift as a method for reducing the time it takes to spin up environments by offering an on-demand service for developers to deploy to. This avoids having to go through the usual process of provisioning systems at the virtualisation layer and typically being held up by the many steps along the way before a fully functional virtual server is ready and available for use.

This isn’t to say that provisioning is dead, not by a long shot, Openshift offers a quick and relatively simple method for giving developers what they want. Beyond provisioning there is configuration management where ‘Infrastructure as Code’ begins its life. Puppet and Chef are the new tools for sys admins and bridging the gap between development and operations as both developers and sys admins start understanding the opposite sides of the DevOps role.

It puts sys admins in a very good position as the coding practices in which they develop in turn allows them better visibility of the development environment and the associated tools that go along with it. Tools such as Git, Jenkins, Cucumber, Nexus and Artifactory. This all helps to improve communication between developers and sys admins and therefore has benefits in efficiency and the resolution of issues.

Developers can also write their own infrastructure code, giving developers the ability to work on projects without loading sys admins with unnecessary tasks. This all becomes a collaboration activity between Dev and Ops. Those tools, Puppet/Chef, allow the enforcement of configurations across multiple systems, ensuring the on-going maintenance is automated as much as possible. Where teams are split between Projects and Support, cross training of these new technologies has to take place in order for all the sys admins to understand the new methods being used.

In the end, when you combine provisioning technologies such as Red Hat Satellite/Cobbler and configuration management tools such as Puppet/Chef mixed with Git, Jenkins and Cucumber your infrastructure can be automated from build to deployment to on-going support and developed using a continuous integration cycle.

Sys Admins have the ability to understand both the code used in the automation and the commands to best implement them. I for one am looking forward to the challenge posed by DevOps.