I’m not trying to come across as saying that a DevOps resource is some super-hero who will come in and save your day. In all honesty, they may come in and bring about some level of chaos as they begin to navigate your world. What I do think is that they will save your business a lot of lost productivity and provide a special set of skills that will help maintain a level of service that your users and customers deserve.
Before I dig in, let’s start by defining what is DevOps. I’ve had a few discussions on various social networks about the meaning of DevOps and I’m sure that some will continue to disagree with me, but much like everyone has a different definition of Development or Operations, everyone will have a different definition of DevOps. DevOps is the role that exists at the intersection of Development and Operations. This is the role that manages the code repository, the builds, the deployments and monitoring systems.
You probably are thinking that you have someone that does this. Chances are that it is more than one person. They probably sit on different teams. That’s where the inefficiencies are.
Look at the evolution of common processes and see how it gets to a place where this is needed.
A Brief History of Process
Once upon a time there was code. And it was good. It took months to gather requirements, create a design plan, write the code and then test it. After several months, it was ready. Then you schedule your release for some low activity time in the middle of the night. Your developers log into the production systems and deploy the code. After this, you went through it all over again deploying code only a handful of times per year.
Then some bad people did some bad stuff (see Enron). Suddenly, be it through legally mandated compliance, general policy or through a design of best practices, we began to change those deployment processes. Either developers would deploy code using special break-glass accounts or they would hand the code over to someone on another team (usually operations). This led to a few challenges. Now you had people deploying the code that had very little insight into the applications. They often didn’t really understand what it was they were doing. Additionally, if there are any issues, the common response is an immediate rollback which may not come with sufficient information to solve the problem before the next attempt.
Enter Agile
As time marches on, it becomes desirable to get releases out faster. It makes sense. Rather than large, monolithic deployments which may be problematic and don’t require too much upfront work, companies begin to adopt agile methodologies. Now, code is ready for deployment every iteration (1 to 3 weeks). Developers and operations teams are spending a good amount of time planning and executing releases.
This is where DevOps comes in. If done right, a good resource can develop and plan an automated release process. They can understand with deeper meaning than your operations team what is really going on in the code. On the flip side, they can understand the setup and configuration of your servers to optimize performance and understand the nuances of your network. With the right set of monitoring tools, they can look for issues that arise before they are reported. They can help you to understand the difference between a true error and an error being reported back to an end user because of a bad request.
DevOps is Part of Your Team
In my conversations in the past, someone suggested that DevOps could be a contractor who comes in and sets up automated builds and leaves. This person should be someone who is fully embedded with the development team and the operations team. With the constant changes in development and the ever-changing networks in an organization, it is more critical now than ever before to have someone who can navigate both worlds. As you move to the cloud, DevOps can work through the scripting of environments to ensure parity exists throughout all your application environments and assist in the process of scaling up as your business grows. There is often more work for a DevOps engineer than simply setting up a build and deploy process.
Determining the most appropriate monitoring tools and configuring them is almost a full-time job. Code changes and environments change, things must constantly be tweaked to enable a full view of what is really going on. Tests built into the environments can help monitor for deployed failures and instantiate rollbacks. The sky is the limit when it comes to the breadth and depth of work that a good DevOps engineer can do.
These same activities have always been considered “nice to haves” for development teams. These teams are forced to focus on building new features into the code rather than building the right environments for that code to live in. Operations is also incapable of doing this as they will be assigned any number of tasks that these typically under-staffed teams must perform. By having a dedicated DevOps resource, you now have someone who is supposed to do those things you used to consider “nice to have”.
Sharing the work
In his book, Scaling Up, Verne Harnish recounts a process where the CEO of a Texas based company (Lois Melbourne of Aquire) would collect the list of duties that employees didn’t like doing and would create a new job description for a new hire. In the same vein, a DevOps role is that person who does the duties that employees cannot do. These employees should remain more focused on Developing the product or building and maintain servers and networks. While DevOps is not as much a clean-up position as described above, it is certainly a role that fills a need.
Debunking the Myth
Several arguments can be made against DevOps. For one, they suggest that such a role first requires that Development and Operations work together. The obvious answer to this should be “Why aren’t they?”. If your organization has two departments that aren’t working together, then maybe you need to rethink the term “organization”. They also suggest that DevOps relies too heavily on a variety of tools. I believe that everyone should work with the best tools available for their job. You wouldn’t ask an accountant not to use a calculator (do they still use them?). You wouldn’t ask a programmer to write everything in notepad. It is important that you arm your people with what it takes to do their job. There must be a balance with the value of these tools.
Depending on the size of your organization, you may see DevOps as a person or a team of people. This must not be relegated though to a function shared among many people. It should also not be a secondary function of a developer or operations person. This role should be handled as a discrete role with a well-defined set of tasks to perform. At first, things will be manual. Over time, the right engineer will figure out how to automate these tasks. If they don’t, you don’t have the right engineer.
Remember that title where I promised that DevOps was a hero you didn’t realize you needed. Every member of your team is a hero saving your company every day. DevOps should just be another member of this Superhero team!