DevOps Introduction

For the longest time, I thought DevOps meant the developers were the ones who took over server maintenance from an operations team, be it a web admin or DBA. The only way for that to happen was to be up in the cloud. After all, the name says it all, DevOps, developers, and operations. And a lot of articles I have read about the cloud were written by developers. Typically they worked at small development shops or start-ups, so they had to wear the operations hat as well.

How wrong I was.

DevOps is one of those terms people love to throw around, but rarely do they know what it actually means. It reminds me a lot of the way people were throwing around XML back in the late 1990s/early 2000s.

I recently had the chance to attend a lunch and learn. During the presentation, they were able to sum up DevOps in a very simple definition.

DevOps is the answer to the question, "what do I have to change in my process to be able to and want to deploy to production 10 times a day with zero downtime?"

Let that sink in for a second.

Adopting DevOps does not mean firing all the operations people and letting the developers take over. That is insane. Operations people are critical to the success of any IT shop. They bring a wealth of knowledge and perspective most developers don't have.

Instead of that, Developers and Operations people will collaborate towards a common goal, such as being able to deployed to production throughout the day. Collaboration is the key. I'm going to use my experiences with working on the Octopus Deploy Workgroup at Farm Credit Services of America as an example. We have multiple servers behind a load balancer. We have automated all of our deployments using Octopus Deploy and Redgate tooling. All of the technology is there to be able to deploy to production during the day with zero downtime.

The Octopus Deploy Workgroup has two DBAs, three Web Admins, four developers, two lead developers and one enterprise architect. When we met to discuss what is necessary to take advantage of the technology we have purchased in order to get to production without any downtime the results were interesting. Each person had their own set of concerns that we need to make sure we addressed. Here are a few:

• The load balancer makes use of sticky sessions, any application that wants to be deployed during the day needs to be stateless
• Several servers host more than one application. We can't just drop the entire server out of the load balancer, we need to drop a specific application.
• After deploying to a server we need to have a suite of automated tests to ensure the deployment was successful
• Database changes need to be backward compatible with a previous version of the code. The database goes first then the code is rolled out. For example, if a new column is added to a table then it should be nullable so old code can still insert into that table without throwing an exception
• We need to run load tests to determine the maximum load we can put on a server. If we only have two servers for an application, can we take one out of a load balancer and still maintain the load.

Most of these concerns cannot be addressed by just a developer working alone or an operations person working alone. They need to collaborate to ensure whatever solution is adopted meets the needs of everyone.

DevOps is what my next series of blog posts is going to be about. That collaboration as well as changes made to application architecture to help support going to production multiple times a day with zero downtime. I'm excited to get started.