DevOps Defined

Ok, you're back. I'm confident one of the first questions you are going to be asking is, "Why are you writing another article to define 'devops', you already did that." Well, to clarify, I did not define devops, I described it. Now, I am going to actually give you what everyone in the industry has been in search of. An actual, real life definition for the craze 'devops'.

devops [dev-ops] Examples:

1. A team that exists within an organization to integrate with, and establish policies, procedures, and frameworks to unify and simplify the achievement of the organization's goals by promoting collaboration and continuous interaction with other teams within the organization.

2. An individual who contributes to the establishment of policies, procedures, and frameworks that promote collaboration and unification of multiple teams in an org chart.

There, you now have a working, real definition of devops.

How devops works

This is where it gets much more interesting. How does devops work in an organization? Or perhaps, we would do better asking, "How should devops work in an organization?"

Devops aims to form a foundation within an organization; a solid, robust foundation that crosses the boundaries of multiple teams. Unlike the days of silos, when companies wanted a network engineer that was strong at only networking, and a system administrator to be only focused on system administration, times have changed. Now, we exist in a technical society dominated and governed by devops; generalists that know and operate with experience across many silos. You want networking? Got it. You want system administration? Got it. You want security? Got it. If you are to call yourself a devops engineer, you need to be able to answer the call from many and multiple teams, all at once.

Why is this important? In order to increase the productivity and unity in which a company operates, you have to understand the needs of your userbase. Yes, that's right. Devops is service oriented. If you do not want to have to interact with lots of different people, find a different position. Collaboration is the prime directive for devops, without collaboration, you cannot fulfill your obligations to yourself or your company as a devops engineer.

So what does devops do? Devops works with each team across the technical presence of a company, in order to promote efficiency, communication, and policies that enhance the productivity of the teams. Take, as an example, a company that has no automated CI (continuous integration). Devops should be actively working with Dev (Software), and QA (Test) to determine what the needs are for testing, why it is not being done, and how it can be done. Then devops works to assist in implementing the solution, and finally, works with the teams further to establish the use and understanding of how the tools operate. Yes, devops is about control, workflow, adherence to guidelines.

How does devops work? Devops uses many tools from many realms to accomplish the core goals that it has. These tools can be automation frameworks such as ansible, puppet, or chef, monitoring tools such as shinken, sensu, or nagios (or others), or communication/notification tools like slack and pagerduty. All of these tools have a role in an organization's workflow, and as a devops engineer, it is your job to know which tool is right, and how to go about implementing it and training the team to use the tool effectively.

Using the above example of building a CI environment, the engineer may start by identifying what, if any build engine is in place. If there is not one, then it falls on the engineer to be familiar with one or more, and know the benefits and limitations of the tools they choose. Now they have to put that build tool in place, they need to configure it to operate with the projects that are to be built, tested, and deployed. It also needs to be monitored. They need to work with the team to establish the use of the tool, and improve the workflow. As you can see, you can either have a large number of people that can handle these tasks (and at a larger company, you may have dedicated teams), or you need someone that has the familiarity and skillset to cross each of these organizations to build it from varying stages of implementation.

Where do I fit on the ladder?

Where do you fit on the ladder as a devops engineer? How do you know what skills you are expected to have, and how far you have to go? As an example, a jr devops engineer may be learning the ropes of how to handle continuous integration, they may have interacted with the build tool in use, but they have not fully owned and controlled it. A sr devops engineer has probably worked with one or more build tools, and been in control of them, but may not have established actual workflows and procedures around how the tool should be used. A devops architect has interacted with multiple of the tools, has controlled them, as well as established workflows, policies, and procedures to integrate their usage into the company practices. Keep in mind that this is just one particular tool being discussed. At the jr level, you probably have basic skills with one or more of the tools. At the sr level, you have experience controlling multiple tools and working with them. At the architect level, you have had complete ownership from design, to implementation, maintenance, and use or not just one, but the overall toolset.

Keep in mind that there is no definitive way to know where you are on a ladder. You'll also note that I did not mention a mid level engineer's familiarity. This is not because there is no such thing as mid level, but rather because there is no definitive guide to defining the devops skillsets. A jr is like a 'squire' in the old trade school days. A mid level might be an apprentice. To continue the illustration, we would have sr at the journeyman level, and the architect is 'master'. It is based on how much overall experience you have in your trade (devops), and where you are in your career.

There, you now have a basic view of who devops is, and what devops does. I hope that this is useful and insightful, and maybe more companies will come to understand the critical role that devops should be playing in their own technical organization.



villains-lab forums