How to Build a Workstation for the DevOps Model

When you're working in the DevOps model, you need a workstation that helps you get the job done. A PC setup that works for developers is not necessarily the best fit for DevOps. Nor is a desktop configured for an IT Ops engineer.

Although there is no one-size-fits-all DevOps workstation configuration, following is some guidance on how to build and configure a workstation that is tailored for the types of responsibilities a DevOps engineer needs to handle.

1. Choose your hardware.

The first thing you'll need to decide when creating a DevOps workstation is which hardware to use.

The hardware specifications won't matter a whole lot, but there are a few pointers to keep in mind. For one, it's wise to choose a machine with a lot of memory, which comes in handy when you need to run virtual machines. In fact, if for budgetary reasons you have to choose between prioritizing CPU power and prioritizing memory, I'd recommend going for more memory.

A laptop is also usually a wiser choice than a desktop. Although the latter type of machine might provide more computing power for less money, the mobility that a laptop offers is critical when work in the DevOps model requires you to go on-site to fix an ailing server or figure out why a network switch is not working, for instance.

It's probably not worth paying for fancy features like a touchscreen, which is not very useful when you spend most of your time typing out code. On the other hand, biometric authentication devices could be worth the security protections that they enable. And an SSD drive is a wise investment, especially if you'll be using your DevOps workstations to build or test code and will benefit from the high I/O rates that SSD devices provide.

2. Choose your operating system.

Just as there is no single best programming language for the DevOps model, you don't need to use a specific operating system to do DevOps. On the contrary, the best DevOps engineers are able to work equally effectively in both Windows- and Linux-based environments because they may need to support servers or applications that run both types of operating systems.

Fortunately, given the ways that the Windows and Linux ecosystems have converged in recent years, it's easy enough to run both Windows and Linux on the same device. You could provision your DevOps workstation with Windows, then install Windows Subsystem for Linux, which gives you access to most of the standard tooling and environment configurations you need to work with Linux workloads from a Windows machine.

Alternatively, you can install your favorite Linux distribution on your DevOps workstation, then set up a Windows environment in a virtual machine, or use a Linux RDP client to connect to a Windows desktop that you have running elsewhere.

The approach you take doesn't matter too much in most cases. (An exception is if you need to run some workloads on bare metal, in which case you should make sure that the workstation's host operating system supports those workloads.) The essential thing is simply to have access to both Windows and Linux tooling from the same DevOps workstation, especially if your DevOps work requires you to work with both types of environments.

(As for macOS, it doesn't hurt to know that platform, too. But because very few server-side applications are hosted on macOS these days, it is generally less important from an application-deployment and management perspective to know Mac environments. Plus, if you know Linux, you can use most of the same Unix-like CLI tools to work in a macOS environment if you ever need to.)

3. Provision dev/test environments.

In addition to making sure you can access multiple general-purpose operating system environments, it is useful in most cases to provision your DevOps workstation with a dev/test environment that closely resembles the production environment you need to support.

For example, if you deploy production applications to Kubernetes, installing a local Kubernetes cluster will allow you to test new deployments and configurations easily directly on your workstation. If you run Linux on your workstation, you can install Kubernetes directly to the host OS. If not--or if you want to keep Kubernetes isolated from the host operating system, which is generally a wise thing to do--you could install it using virtual machines.

4. Set up development tools.

If your DevOps work involves a lot of coding, you may also want to install development tools on your workstation. Install your favorite IDE (or make sure you can connect to your cloud IDE, if that is where you write code). Install code-management tools like Git, as well, so that you can manage local and/or remote code repositories, depending on your needs. Build tools may be necessary, too. For example, if you deploy applications to your production systems using Docker, you'll probably want to install Docker locally so that you can build container images for testing purposes.

5. Configure storage and backup.

If you are a DevOps engineer, you hopefully don't need to be reminded of the importance of backing up your systems and data, even your workstation.

The best way to manage backups will depend on how the workstation is configured. You can use image snapshotting to back up any virtual machines that you use. For backing up the host operating system, you can use whichever native backup tooling your operating system offers, or set up a backup routine yourself using a tool like rsync.

A small tip: On Linux machines, I like to install /home on its own disk partition. That way, I can reinstall the operating system whenever I want, or move to a new machine, while keeping all of my user data and configurations in place.

Conclusion

DevOps is a broad field, and the DevOps workstation you build should align with the types of work you do in the DevOps model. But, in general, choosing a laptop that gives you access to both Windows and Linux--as well as to all of the development and dev/test tooling you need for your job--will go a long way toward helping you work efficiently, no matter which challenges your DevOps workflows throw at you.