Skip to main content
Exploring what’s next in tech – Insights, information, and ideas for today’s IT and business leaders

The death of the command line

Don't get me wrong: The command line will always be important to sysadmins. But in many ways, it's being superseded by DevOps tools such as Ansible, Chef, and Puppet.

I cut my sysadmin teeth on IBM 360 Job Control Language. Later I moved to Unix and Linux, where I used shell languages such as Borne, Korn, and Bash to get my work done. If you're an experienced sysadmin, you can relate to the experience.

However, while knowing Bash or PowerShell may have been enough for sysadmins in 2010, it won't be enough in 2020. The rise of DevOps has led system administrators to define and abstract infrastructure into configuration management code, using programs like Ansible, Chef, Puppet, and Salt. Today, technologists who learn how to use tools to automate IT can help their company become more agile. Those who don't are doomed for the unemployment line.

That's not just my opinion as a grizzled sysadmin veteran who's seen the DevOps light. It's the view of many experienced sysadmins.

We can all indulge in technology nostalgia. You sometimes hear sysadmins talking about how their jobs expanded way beyond anything they ever dreamed of. They remember a clean, simple time when being a Unix sysadmin was one thing, Windows Server admin was a different role, and database administrator was yet another specialty. And if you dealt with physical layer network wires, Ethernet cables, and Cisco routers and switches, that was another thing altogether. But today, as one sysadmin complains, you're "asked to admin 10,000 computers at once [using] VMware vSphere, Chef, Puppet, Docker, and Elastic Provisioning, Red Hat Satellite and Ansible—every buzzword they can think of."

To these people: Get with the program.

This isn’t your parents’ networking infrastructure

Sysadmins today are not being asked to run a single server or even a cluster of servers. A typical sysadmin may very well have thousands of server instances running at the same time, counting virtual machines (VMs) and containers. We used to automate individual server processes; now we automate multiple server instances.

For example, in the old days, sysadmin work was all about uptime. You had to keep your servers up, come hell or high water. A down server meant mission-critical work was not being done. Today? Not so much.

In today’s IT shops, server uptime is not the same thing as service uptime. Now, servers are cheap and abstracted. We've decoupled service availability from individual servers. A sysadmin puts it this way: "When once you might update a given service's software every two to 36 months, today the time between live production updates might be measured in days or even hours."

We also have much better tools to update software without rebooting. Oracle Ksplice, Red Hat Kpatch, and Canonical Livepatch all enable you to reboot Linux systems without any downtime.

Over 1M people read Enterprise.nxt. Are you one of them?

Another difference from the old days is that back then, for most IT staff, the workday was 8 to 12 hours, Monday to Friday. Today, your customers and staffers expect to go to the company website and find your services up and running 24/7, 365 days a year.

Sure, you could manage everything with Bash scripts, but would you want to? I understand the appeal of a command line—truly I do—but today’s infrastructure has so many connected parts that nobody can keep all the pieces straight without help. It's a tremendous waste of time and effort to stick to the command line when you can move to DevOps infrastructure-as-code approach for server deployment and management.

Just as VMs and containers have abstracted away physical servers, DevOps is abstracting the command line and scripts into DevOps "programs." DevOps does more than just automate away old sysadmin jobs. It also enables such new and vital practices as continuous integration/continuous delivery.

The DevOps approach dates back to 2005's introduction of the first DevOps program, Puppet, and Google's Borg. While Borg is the Kubernetes container orchestration program's direct ancestor, it also laid DevOps' foundations. To quote from the Google Site Reliability Engineering (SRE) Handbook: “[The] traditional ops-focused group scales linearly with service size: If the products supported by the service succeed, the operational load will grow with traffic. That means hiring more people to do the same tasks over and over again. To avoid this fate, the team tasked with managing a service needs to code or it will drown.”

While Google was turning sysadmin jobs into automated code behind closed doors, Puppet began building its open source proto-DevOps configuration management platform. With Puppet, sysadmins could define and abstract their infrastructure into config management code with Puppet's Ruby-based domain-specific language.

Fast-forward to today. Now, the goal is to avoid putting your hands directly on the machine and the virtual infrastructure. Instead, say sysadmins, learn to declare the infrastructure as code so you can execute the intent and abstract the manual labor away into repeatable and reusable components.

How to move from sysadmin to DevOps

Let’s get specific. What should you do if you need to reinvent yourself and you want to be a gainfully employed sysadmin in the 2020s?

1. Accept that you need to learn new processes

Most of us don’t like to change once we’ve paid our dues. Few of us look forward to learning new ways of doing things. Too bad. Technology waits on no one.

If you stick with just your existing skill set, you're not long for your job. Even small businesses are adopting VMs, containers, and clouds. This means that, at the least, you need to pick up DevOps skills to manage multiple systems at once. (Attending a conference can help you get started.)

2. Learn how to program

As a sysadmin, you're already part of the way there. Shell scripting is already part of your job.

No one's saying you need to learn C++. But you do need to pick up one or more DevOps-friendly languages such as Python, Ruby, and Go.

3. Pick up a DevOps program

Just as you once had to learn Bash or PowerShell, today you must learn how to work with Ansible, Chef, Puppet, or some other DevOps programs.

Which one should you pick up? Start with whichever tool your company is using. If you’re given free rein (and want to pick the most marketable skill), you could follow RightScale's 2019 State of the Cloud Report and choose Ansible, which is now the most popular program with 41 percent adoption. Puppet and Chef are tied for second with 37 percent adoption each. While in fourth place, Terraform showed the strongest growth, expanding from 20 percent in 2018 to 31 percent in 2019.

4. Ace version control

No matter which platform you use, you're going to have to manage a lot of scripts. To do this efficiently. you can use both the program’s built-in tools and version control programs.

That means you must learn Git, the distributed source code control system. Git is central to essentially all DevOps operations. There are many Git systems, or you can run it natively. But for learning its basics, GitLab's free services are an excellent playground. I also recommend Atlassian’s Git tutorials.

5. Learn to fix in development, replace in production

This goes against the grain of experienced sysadmins. But in DevOps, when something goes wrong in production, you don't fix it in production. Instead, you fix it in the development system and then redeploy in production.

The popular analogy is “pets vs. cattle.” Your production machines are cattle; you replace them when they're sick. The servers aren’t pets, which you nurse back to health with hours of effort.

Yes, your production boxes are not the same as your development systems. But in DevOps, server configuration and logs are kept in an external environment. With this approach, production machines are immutable; all fixes must come by replacing them with fixed development systems.

To make yourself ready for this paradigm, learn yet another set of deployment programs. These include Jenkins, AWS CodeDeploy, and GitLab CI.

Moving from the CLI to DevOps

It won't be easy to shift to DevOps from old-school system administration practices. But you really have no choice. Businesses demand the speed DevOps brings to today's IT world.

One estimate is that it takes a sysadmin six months to learn DevOps with an hour of study a day, five days a week. You should also look into DevOps classes from the Linux Foundation.

This is a lot of work. But it's good work.

Lessons for leaders: Beyond the command line

  • DevOps isn't hype.
  • Traditional sysadmin work is still important, but the future belongs to those who learn DevOps like a pro.
  • Picking up DevOps skills takes months. It can't be done overnight.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.