DevOps, Continuous Delivery & Database Lifecycle Management
Culture and Organization

Developers and operations (IT) have always had conflicting priorities. A typical developer has the objective of giving additional features and functionality to the customer and maintaining a reliable code base as quickly as possible. “Success”, to a developer, means keeping the business customer happy. The only way to do this is to give them what they need as soon as possible. In an Agile environment, this requires frequent changes. IT has traditionally hated change: This is the crux of the Dev vs. Ops feud.

To IT, change is what creates server-downtime: Change is what makes a pager vibrate itself off an Ops guy’s nightstand at 2AM in the morning: Change is what those developer guys want to do constantly, and therefore it is the developers that are the problem. Change is bad! But in reality, change is…inevitable and necessary. There’s got to be a better way to manage change. The answer is DevOps.

What if you’re on the Ops side of the DevOps coin? You may have heard about DevOps and assume that the push seems to come mostly from those pesky developers. “What are those guys up to now?” you ask suspiciously. As an IT pro, you may have lots of questions about this thing called DevOps. Let’s set aside the rivalry for now and answer four questions that you might have been too shy to ask.

• Am I supposed to write code now?
• Are developers going to have control over my servers?
• Am I going to be automated out of a job?
• What new tool am I going to have to learn now?

Question #1: Am I supposed to write code now?

Yes. Before you go jump off a bridge, let me clarify: You will be writing code but not developing software applications. There’s a difference. Developers create software applications or software “solutions”. Developers write code to create software that helps the business. In the DevOps world, IT pros write code to deploy the software faster and more efficiently. IT pros write code that deploys more servers at a higher rate. They write code that’s run on servers to ensure they are all in a predefined configuration state and stay that way. They write code to do whatever it takes to optimize the software-delivery pipeline. You’re not writing code to create the application, but you’re writing code to support it.

Software developers have long known that software is dynamic. Software can be changed with a simple text-file modification and controlled via source control. Source control allows a developer better control of changes, an easy-to-reach history of changes or, if things go south, a simple method to revert any changes made, at any time, at the flip of a switch. In addition, software provides built-in documentation. Want to see what a feature does? Just read the code. There’s less need to create entire documentation binders to show to other developers what software does.

A traditional IT pro, on the other hand, is more familiar with a physical world where work can be picked up and held: Bringing up data-centers, racking new servers and running network cable. IT pros are used to installing software with wizards and being the user of the tools that software developers create. Defining a physical server as “dynamic” is seeing how fast the IT pro can shut off, move, rerack and turn it back on as quickly as possible. That’s about as “dynamic” as their physical world gets.

Change history? To an IT pro, he relies on the manual entries by other diligent IT pros into a change management system that everyone should be using but doesn’t. He might get by with a text file on the desktop of each server but that relies on his co-workers being able to remember to update it and to write something half-way understandable. “Rebooted server” doesn’t count.

Don’t even get an IT pro started on the subject of documentation. Every IT pro agrees that it’s necessary but avoids it like the plague. No one’s got time to do that, right?

All of these typical IT pro problems can be helped by moving traditional infrastructure management methodologies to an infrastructure as code way of working. You may be asking “Infrastructure as code? We still need some physical things you know?” Yes, I’m aware of this but that’s not what the term is referring to. “Infrastructure as code” is a term that refers to writing code (gasp!) to manage your infrastructure; not replace it. It’s the act of writing code that sends instructions to your servers to do things. No more popping in the CD and installing Windows, or manually creating virtual machines one at a time. With “infrastructure as code”, you simply write some code that does those things for you and then key-in the number of iterations you want the code to run and you’re done! One server or a hundred, it doesn’t matter.

This is the sort of code you’ll be writing.

Question #2: Are developers going to have control over my servers?

Yes and no. DevOps is about expediting the software deployment life cycle (continuous delivery). It’s about cutting out the manual processes which consume too much time and lead to mistakes. In a perfect world, developers could write the software, hit a magic button to deploy to a test environment then, when happy, hit another magic button and the code would be live in production.

Thankfully for IT pros, you are the magic button in the DevOps world. Developers are good at writing software. They are not necessarily good at deploying that software and ensuring that software is running on the proper hardware in the right configuration. No one knows it all. However, to optimize continuous delivery, developers need a way – a pre-designed method – to get code from test to QA to production without any barriers. This not only expedites the software deployment life cycle but also frees up the IT pro to concentrate on more pressing issues such as writing code!

In this sense, developers will have some control over what goes on your servers, but the amount of control that they have is defined by you. To be a good DevOps citizen, you need to release your draconian grip of control over the production servers and be more reasonable. Developers will be allowed acceptable control over your servers to do whatever it takes to deploy their code. It is up to you to properly plan and control that access so that it does not affect other areas of the infrastructure.

Question #3: Am I going to be automated out of a job?

Automation certainly has the downside of removing the need for the more routine jobs.. The robots are taking all of our manufacturing jobs and soon the semi-truck driver won’t be needed because the big rigs will all be driving themselves. The issue of automation leading to job loss and been around for a long time. However, it isn’t as cut-and-dried as it seems. There are strict limits on what automation is capable of. After all, airliners fly themselves nowadays rather better than a pilot can, but you still need pilot and co-pilot for those occasions that are beyond automation.

Regardless of your opinion, there is an undeniable productivity gain from automation. Automation leads to error-free operation, reduced time and less labor. because of this, a core principle of DevOps is automation. Does that mean that, in the future, it will only be those creating the software who are left standing? No. IT pros will not be the IT pro of today but that doesn’t mean that the IT pro will be extinct as the Dodo. It will simply mean that the IT pro will need to evolve into a DevOps world.

If you’re an IT pro in a Windows shop, have you ever written a PowerShell script before? If not, you’ll need to get to work on evolving your skills. If you’re in a Linux shop, have you ever written a line of bash, Ruby or Python? No? Then you’re at risk of being extinct. Have you ever heard of the term “configuration management” before? Am I sounding like a broken record? You get the point. Refer back to question #1. If you don’t know how to code and to manage your infrastructure with this code you’re at risk. The engine for automation is code. In the future, you’re either going to be the designer, the architect or the mechanic for that engine. Don’t try to be the driver. We’ve got plenty of robots that can do that now.

Question #4: What new tool am I going to have to learn now?

Another important, yet less stressed principle of DevOps is tools. If the software delivery process can be thought of as being like a conveyor belt with stations along the route, do you think that such a belt could be maintained without tools? Things break, software can’t be written in notepad and I’m not about to begin manually copying scripts from my build server to production servers all day. The conveyor belt must be continually maintained and tools are a necessity.

I know that IT pros of yesteryear don’t like change and I’m sure you’re mumbling under your breath “..but we’ve already got tools that I know”. You don’t to leave all your tools at home to be replaced with new, shiny DevOps tools but you are going to be required to add a few to your toolbelt.

The most important tool in a DevOps engineer’s toolbelt is a good configuration management tool. Remember the term “infrastructure as code”? Configuration management is the tool to implement this. Configuration management products like Chef, Puppet and PowerShell Desired State Configuration (DSC) provide a framework that now allow an IT pro to declaratively state “I want this server to be this way. Make it so!”. All of these tools take the command and it just magically happens. Granted, it is the tool administrator that’s providing the magic fairy dust but ultimately, configuration management tools deliver the instructions to the servers and “make it so”.

“These tools look like they have some sort of GUI. Does that mean I can just point-and-click my way to configuration management?”, you may ask. Nice try! What makes these tools so useful is code and it’s up to you to write that code to tell them what to do. There might be some recipes, modules or resources (whatever the tool calls them) that assist you in your configuration tasks, but they aren’t just “set it and forget it” tools. They each require you to write code (there’s that word again) in order to configure them to assist in your own DevOps environment.

As an IT pro myself, I know how tempting it is to focus your mental energy on a new tool. It’s shiny and does cool things. Don’t get solely focused on the tools. DevOps is so much more than a tool. To be successful at DevOps, focus more on the cultural aspects and really just getting along with the developers!

Final Wrap Up

Change is inevitable. As the old say goes, “change is the only constant”. If I were to sum up DevOps in one word it would be “change”; changes in culture, people and processes in order to promote continuous delivery of rich and reliable software to business customers. DevOps is not about ‘us vs. them’ anymore. It’s about working together towards a common goal. It’s about bringing down the silos in your organization and coming together for the business.

Embrace change and the DevOps movement. Evolve. Don’t let yourself go the way of the Dodo bird.

DevOps, Continuous Delivery & Database Lifecycle Management
Go to the Simple Talk library to find more articles, or visit www.red-gate.com/solutions for more information on the benefits of extending DevOps practices to SQL Server databases.