Career makeover: From ops to devops
Our days as ops admins consisted of unboxing pallets of servers, heaving them into the closest server rack, and struggling to get the rails aligned just right. Then we'd pop in the manufacturer's CD, install the OS, drivers, and load it onto the network. Only then would we return to the cooler confines of our desks to remote desktop or SSH into the server to install the required software and configure the settings necessary to meet developers’ application specs.
Those days are over: No more servers treated as individuals with funny names like Uranus to care and feed like an ops family cat. Today, the cloud -- whether public, private, or hybrid -- has greatly transformed operations work, an evolution that has many dyed-in-the-wool admins wading in waters once considered entirely the realm of developers. Isn’t it high time you do the same
Following are our essential career makeover tips for admins looking to develop their devops chops and future-proof their careers, as organizations increasingly head for the cloud.
These days, IT must deploy services faster, with greater reliability and fewer people on hand to do the work. This means automation. Without automation, IT can no longer provision, manage, and support the kind of services architecture that enterprises use today. Consider automation the most essential of tasks for you to master.
This is where code comes in -- yes, the cryptic files of commands that developers cobble together. To manage the vast number of virtual machines, containers, and physical servers both on-premises and in the cloud, you will be thrown headfirst into the world of code. Provisioning and managing the configurations of your servers will depend heavily on your ability to think like a developer.
Code is simply pure text. It has allowed software developers to add, modify, and remove critical features in software that businesses depend on every day for years. It has enabled developers to patch security vulnerabilities and fix problems quickly. It was only a matter of time before forward-thinking businesses caught onto this fact to ask: How can we apply the flexibility and dynamic nature of code to infrastructure
Code comes in many forms under many different languages, but a few languages will naturally lend themselves to the ops person. If you're in a Microsoft shop, you'll need to learn Windows PowerShell. PowerShell is the successor to the command prompt, batch files, VBScript, and much more. PowerShell allows ops admins to automate every aspect of the Microsoft ecosystem, and nearly every Microsoft product now has PowerShell support.
For the Linux and open source crowd, Python is a worthwhile language to check out. It is well established and, as such, is used in many different scenarios. Python is a great tool for infrastructure automation. Certain configuration management tools, like Chef, require knowledge of Ruby, so that’s another language to investigate.
Regardless of what you choose, remember this: The languages themselves are semantics. You can eventually pick up any language, but the key is to understand the underlying principles of coding and what code can do. If you're brand-new to coding, I highly recommend starting with "Coding for Dummies." It will introduce you to scripting/coding and give you a leg up once you choose your preferred language (or the language chooses you).
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.
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.
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.
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.
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.
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.