There has been a sharp uptick of developers and systems administrators interested in “getting into DevOps” in recent years. This makes sense: a single developer can now spin up globally distributed infrastructure with a few API calls, compressing the gap between development and operations dramatically. Yet while there is no shortage of blog posts about cool DevOps tools, there is far less practical guidance for people who actually want to make the career transition. This article aims to draw that path clearly.
Understanding “Olde World” IT: Why DevOps Exists
Understanding where DevOps came from is key to understanding what it actually is. To appreciate the movement, it helps to look at what IT operations looked like in the late 1990s and through most of the 2000s.
In large enterprises of that era, adding compute capacity meant placing multi-hundred-thousand-dollar hardware orders — servers, networking gear, cables, and software licenses — destined for on-site and off-site data centers. VMware was still convincing skeptical CFOs that virtual machines were cost-effective. Many companies ran applications directly on physical hardware. Entire teams were dedicated to data center operations: negotiating lease rates, managing cooling, and ensuring offshore night-shift staff could identify the right server rack without pulling the wrong cable during after-hours trading.
Software releases were similarly painful. The typical workflow looked something like this:
- Business analysts gathered requirements in meetings developers were not invited to attend.
- Developers wrote code to those requirements, optionally writing unit tests along the way.
- When code was marked “Ready for QA,” a quality assurance engineer picked it up and ran it in their own environment — which might bear little resemblance to production or even the developer’s local setup.
- Failures were sent back to developers days or weeks later, depending on business priorities.
Both sysadmins and developers shared one common frustration: change management. Most enterprises followed ITIL practices, which imposed heavily regulated processes governing when and how technical changes could happen. The intent was to minimize costly mistakes. In practice, this meant releases only every two weeks and all server changes — regardless of size or impact — batched into a Friday-evening-to-Monday-morning maintenance window. Ironically, this batching of work often led to even larger, more complex failures when things went wrong.
DevOps Is Not a Tiger Team
One of the most persistent and damaging misconceptions about DevOps is that it is a team, a department, or a Jira project. You may have encountered this in practice: a “DevOps team” that owns the CI/CD pipeline, a “configuration management group” that has to approve your deployment, or release planning meetings scheduled weeks after code was marked complete. If that sounds familiar, you are watching history repeat itself — the same silos, just with new labels.
Silos form naturally. People gravitate toward colleagues who share their context and vocabulary. In software companies, as codebases grow in complexity, developers working on related features cluster together. What starts as informal collaboration becomes official team structures. That is entirely human. The problem arises when those structures harden into walls, and the walls generate friction, blame, and waste.
In the pre-DevOps world, developers and sysadmins not only worked in separate silos — they actively competed. Developers blamed sysadmins for broken or overly locked-down environments. Sysadmins blamed developers for making arbitrary changes that destabilized shared systems and demanding more compute than they actually needed. Neither side understood the other’s constraints, and neither side was particularly motivated to learn. Developers threw environment problems over the wall; sysadmins prioritized them among hundreds of other requests; everyone waited angrily.
DevOps is a way of thinking, not an org chart entry. The movement’s core premise is that developers, sysadmins, and business stakeholders should function as a unified team. They do not need to know everything about each other’s domains, but they need to know enough to understand each other’s work, read each other’s backlogs, and speak a shared language. This is the philosophical foundation behind infrastructure as code, shared deployment pipelines, and accessible monitoring dashboards — practices that make the entire system legible to everyone involved.
As Chef co-founder Adam Jacob put it: “DevOps is the word we will use to describe the operational side of the transition to enterprises being software led.”
What Do You Actually Need to Know to Get Into DevOps?
The honest answer is: it depends on the company. The “DevOps engineer” role varies significantly by organization size, maturity, and existing team composition.
- Smaller companies with many developers but limited infrastructure expertise tend to hire people with strong systems administration backgrounds who can also write code.
- Larger or older organizations with established sysadmin teams often look for something closer to what Google calls a Site Reliability Engineer — essentially a software engineer who designs and improves operational functions.
Regardless of company size, the following skill areas appear consistently in DevOps roles:
Cloud Platforms
Knowing how to architect and administer secure, scalable cloud environments is table stakes. AWS is the most common platform to encounter, but Azure, Google Cloud Platform, and managed PaaS providers like DigitalOcean and Heroku are also widely used. Focus on understanding core networking concepts (VPCs, subnets, security groups), IAM and access controls, compute and storage services, and how to design for resilience.
CI/CD Pipelines
Continuous integration and continuous delivery are the mechanical heart of DevOps practice. Understanding how to build, optimize, and troubleshoot deployment pipelines is essential. Common tools include Jenkins, GoCD, Travis CI, CircleCI, and increasingly GitHub Actions and GitLab CI. Learn not just how to configure these tools but why specific pipeline strategies — blue/green deployments, canary releases, feature flags — exist and what problems they solve.
Monitoring, Logging, and Alerting
You cannot operate what you cannot observe. Familiarity with time-series metrics tools (Grafana, Prometheus), log aggregation platforms (the Elastic Stack including Kibana and Logstash, Splunk, Loggly), and alerting pipelines is expected. The goal is not just to collect data but to derive actionable signals from it.
Infrastructure as Code
Manually configured infrastructure is a liability: it is hard to reproduce, hard to audit, and hard to recover from. Configuration management tools like Ansible, Chef, and Puppet allow you to define system state in version-controlled code. Provisioning tools like Terraform and AWS CloudFormation let you declare entire infrastructure topologies the same way. This discipline is central to DevOps because it makes infrastructure legible, testable, and collaborative.
Containers and Orchestration
Containers have become a standard unit of deployment. Docker is the dominant container runtime, with alternatives like containerd now widely used under the hood. Kubernetes has emerged as the standard orchestration platform for running containers at scale, handling scheduling, self-healing, scaling, and service discovery. Understanding how to build, publish, and run container images, and how to write basic Kubernetes manifests, will serve you well in almost any DevOps role.
Skill Gaps: What Sysadmins and Developers Each Need to Learn
If You’re Coming from Systems Administration
You will need to learn to write code — not just shell scripts, but real programming. Python and Ruby are the most practical starting points for this path. Both are portable across operating systems, readable, and widely used in the DevOps ecosystem. Python underpins Ansible and is the dominant language for AWS, Azure, and GCP SDKs. Ruby is the foundation of Chef and Puppet. Either language will open doors; Python has somewhat broader adoption today.
Focus on writing clean, testable automation scripts before attempting to build complex tooling. The ability to write a reliable Python script that interacts with a cloud API or parses logs is immediately valuable in a DevOps role.
If You’re Coming from Software Development
Invest time in Unix fundamentals, basic Windows Server administration, and networking. Even though cloud platforms abstract away much of the complexity of raw infrastructure, debugging slow application performance, network latency, or mysterious crashes is dramatically easier when you understand what happens below the application layer. Learn how processes, file descriptors, TCP/IP, DNS, and HTTP actually work. This knowledge pays dividends every time something breaks in production — which it will.
Hands-On Projects to Build Your Skills
Reading about DevOps is a starting point; doing it is how you actually learn. Here are practical ways to build experience:
Deploy a Real Application Through a Full Pipeline
Take an open-source application from a public GitHub repository and build everything required to run it in production: a cloud environment provisioned with Terraform or CloudFormation, a CI/CD pipeline that runs tests and deploys on merge, and monitoring that alerts on errors and latency. Doing this end-to-end — even for a toy application — teaches you more than any course because you will encounter real failure modes.
Replicate a Manual Setup with Infrastructure as Code
Choose a common service — a web server, a database cluster, a message queue — and set it up manually on a cloud provider first. Document every step. Then tear it down and rebuild the entire thing using only Terraform (or CloudFormation) and Ansible. This two-pass approach forces you to understand what you are automating before you automate it, and the resulting code is something you can show to potential employers.
Run Containers Locally, Then in the Cloud
Start by containerizing an existing application using Docker. Run it locally with Docker Compose to simulate a multi-service environment. Then push the images to a container registry and deploy them to a managed Kubernetes service (Amazon EKS, Google GKE, or Azure AKS all offer free-tier or low-cost options for learning). Working through the networking, storage, and configuration challenges of a real Kubernetes deployment will sharpen your skills quickly.
Final Thoughts
Getting into DevOps is not about memorizing a tool list. It is about developing a mindset that treats infrastructure as software, values collaboration over hand-offs, and prioritizes feedback loops that make systems safer and faster to change. The tools matter, but they exist in service of that philosophy.
Start with the fundamentals — cloud basics, scripting, and a CI/CD pipeline — and build outward from there. Pick one real project, make it actually work in production, and you will have learned more in that process than in months of passive study.
This article draws on content originally published at opensource.com, adapted and expanded for a DevOps engineering audience.