Career makeover: From ops to devops

Get in on the devops revolution by freeing yourself from mundane server tasks and tapping your inner coder

1 2 Page 2
Page 2 of 2

Get in touch with your inner infrastructure coder

But the truth is, ops work today goes well beyond simple scripts. In fact, because IT has invested so much into building virtualized infrastructures and the cloud, infrastructure itself is becoming code.

Think of how you deploy and manage servers today. Perhaps you've set up a few scripts to automate some of the processes, but the scripts themselves have to be kicked off by a human. If so, you're taking much longer to complete your work than you should, and you’re likely fixing numerous mistakes that could have been prevented. In other words, you may be scripting, but you haven’t fully embraced your inner infrastructure coder.

Because of this, it's time to move away from "server thinking" and instead take up a more "services thinking" mind-set, the kind most developers employ when working on their projects. The capability to build, configure, and destroy servers via code is one matter. Evolving an abstraction layer to think more about workloads and services than servers is the key to becoming an infrastructure coder, not an infrastructure administrator. The server is not a unique entity but rather a source of power for a software service. We don't have time to focus our energy on a single server now. It’s all about the bigger picture of servers as services you can control with code.

Rebuild your infrastructure as code

Defining your infrastructure -- compute, storage, and network -- as code is becoming an important concept for admins in managing IT resources today.

At its most basic, “infrastructure as code” means treating your infrastructure as software. The code isn't written for execution on servers; it’s written to build servers. Think of it as taking code down a layer of the stack, from the traditional software perspective. Instead of a software developer adding a new feature to a Web page, a new feature in infrastructure code could be the ability to provision servers in the cloud rather than on premises or perhaps to bring up new virtual machines automatically based on traffic level. It's about defining the state of each of these components and using a tool to ensure it stays that way.

For example, traditionally, requests for new servers have required the filing of a helpdesk ticket, which ops then interprets to try to gauge where to build the new virtual machine and on what storage, a process that means the server request is fulfilled within a number of days, if not a few weeks. Instead, imagine having a self-service portal where customers and co-workers can put in requests, and their virtual machines are provisioned automatically based on a prebuilt schema. This is possible with infrastructure as code.

Infrastructure as code allows you to define what any given infrastructure component should look like. From there, all the logic on how to provision that component is already built. As such, developers and business users can simply build their own VMs. You've defined all the criteria for the VMs ahead of time, and it's simply a matter of coding a manifest of instructions for performing the build.

Savor source control

Software developers use source control to manage changes. Source control through services such as Git, CVS, Mercurial, Team Foundation Server, and so on allow whole teams of developers to work on a codebase at the same time. Developers check in their code on a periodic basis, and source control keeps track of changes, giving developers the ability to merge changes, detect conflicts, and so on. Source control tools also allow you to roll back changes at will.

Imagine being able to simply roll back any change on a server at a moment's notice. Also, do you know who stopped a service today or who deleted that important file? If all of your changes are performed in code and checked into source control, the change is as easy as seeing which account checked in the change set.

Source control might seem foreign at first. Terms like "repositories," "branching," "changesets," and "merging" may even sound like Greek. At its most basic, source control enables you to retain versioning control over changes to a bunch of text files. For example, a typical piece of infrastructure code might contain all the parameters to build and maintain a particular application server. This application server is critical to the business and must adhere to a set of specific configuration items. Your company might soon roll out new features that require a tweak to a website. By using source control and practicing infrastructure as code, you can simply add the new configuration item into a local script on your computer and check the script into source control, which will then kick off that change on all of the applicable servers and any new server built for this application's purpose.

Another benefit of source control is the ability to roll back changes. Perhaps you modified the wrong item and it was immediately changed in production. No problem -- simply roll back your change, and have the servers grab the reverted configurations and be provisioned in their new state.

Once you get the hang of source control, you'll soon see this will be the method in which configuration changes are implemented rather than the ad hoc manner you might have been making changes previously.


When you treat your infrastructure as code, deploying configuration changes to hundreds of servers simply requires the editing of a text file. Your automation tools do the rest. You can revert any unwanted changes quickly as well. If a change occurs outside of the code, tools can revert the change within a few minutes and keep your servers in the state you defined for them. This ensures all servers are in a consistent state at all times.

The speed you achieve by managing your infrastructure as code will prove essential, as every process in your server lifecycle must be lightning fast. After all, you will have to keep up with your developers, who -- in embracing a devops/agile methodology -- will be moving fast themselves. You’ll have to tap into that constant-iteration mentality of developers who release new features and patch bugs in conjunction with constant feedback from customers. Think of yourself as agile ops, iterating your infrastructure quickly to support your developers as they too speed through continuous changes in their code.

Train on new tools

Many new tools await your devops transformation. If you manage Windows servers, I highly encourage you to learn Windows PowerShell, an invaluable scripting language for automating server deployment, maintenance, and the like. Once you have PowerShell down, focus on Desired State Configuration (DSC). Microsoft built DSC as a platform on which operations teams and technology vendors can create tools. As with other configuration management technologies, DSC is a way of managing your infrastructure declaratively. Simply write a configuration script and deploy to a server -- it adheres to the state in which it was told!

For heterogeneous environments, you'll want to check out configuration management tools such as Chef, Puppet, Ansible, SaltStack, and CFEngine. These tools support both Windows and various flavors of Linux, essentially applying a management layer on top of your infrastructure. By now, you know how to install IIS or Apache. Why should you be forced to run through that every time you need a new Web server? You shouldn't. Configuration management tools already know how to do that. Use them to manage the infrastructure at a higher level and put your time into managing the software the Web server serves rather than the Web server itself. After all, that’s likely where your organization’s business advantages reside: in the software or services.

Embrace immutable infrastructure

There's a term in the software development world: "immutable object." In object-oriented programming, this simply means an object that does not change. It's a way of ensuring an object is of a particular state and stays as such. If it needs to change, the entire object is destroyed, and another is created. Take this concept and apply it to a virtual machine, a storage LUN, a network VLAN, or a container, and you have immutable infrastructure.

When the infrastructure was physical, we couldn't rebuild servers on a whim. It required a lot of work! Now that the infrastructure is treated as code, components in the infrastructure can be treated as objects. As such, due to the speed at which we can make changes, we can now treat infrastructure components as disposable.

Once you nail down this concept, your infrastructure will gain the predictability and standardization necessary to navigate constant change. Being able to manage the constant flux of enterprise architecture is vital. But trying to control each and every little change is maddening. To be sure that any given server is in the state you need, you can simply blow it away and create another. Since your entire infrastructure is defined in code, all the instructions to do so are stored in source control. Rebuilding a server in PowerShell could simply be a matter of Get-Server | Remove-Server –PassThru | New-Server. All the logic and instructions to make this happen already exist.

Devops done right

Operations needs to evolve to stay relevant. The industry is continuing to be more software-centric. Everything is a service now, and many businesses are choosing the cloud over traditional on-premises solutions. To keep up, we must embrace our inner developers and treat our infrastructure as software and manage it as such. We must manage our servers as cattle -- anonymous creatures only on this earth to provide us sustenance rather than pets with names and custom collars. This takes code and new tools based on our ability to write scripts to make the most of them.

In previous years, it was not possible for developers and operations to work side by side. Now that we're able to represent traditionally physical components as software, operations can stand on common ground as developers through code. But doing so will take a developer’s-eye view of your traditional administration tasks.

Related resources

This story, "Career makeover: From ops to devops" was originally published by InfoWorld.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2016 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2