Ngôn ngữ lập trình cho DevOpsProgramming Languages for DevOps

Part of the DevOps Roadmap knowledge base.

Overview

DevOps sits at the intersection of software engineering and operations, and virtually everything in that space — provisioning, deployment pipelines, monitoring, incident tooling — is driven by code. A DevOps engineer who cannot program is limited to clicking through consoles and gluing together other people’s scripts. Knowing at least one general-purpose language well (and being able to read several others) is what turns “operations work” into “engineering work”: you can automate repetitive tasks, build internal tools, extend existing platforms, and debug the systems you operate.

The modern infrastructure ecosystem also speaks specific languages. Kubernetes, Docker, Terraform, Prometheus, and most CNCF projects are written in Go. Ansible, and a huge share of automation and data tooling, is Python. Older configuration management tools (Chef, Puppet, Vagrant) are Ruby. Understanding these languages means you can read the source of the tools you depend on, write plugins and providers, and contribute fixes instead of waiting for upstream.

You do not need to master five languages. The realistic goal is: one scripting language for daily automation (usually Python), one systems/tooling language for building performant CLIs and services (usually Go), plus shell scripting as table stakes (covered in the Terminal & Scripting topic). This page is about how to choose deliberately rather than by habit, and about the trade-offs — performance, distribution, concurrency, ecosystem — that make one language the right tool and another the wrong one for a given job.

A useful mental model: a programming language is not just syntax, it is a distribution and operations story. The question “which language?” is really three questions — how fast can I write it, how will it reach the machines that run it, and who will maintain it after me. DevOps weighs the second and third questions much more heavily than application developers do.

Fundamentals

Why a DevOps engineer needs a programming language

• Automation: replace manual, error-prone runbooks with idempotent scripts and tools. A documented runbook decays; a tested script is executable documentation.
• Glue code: connect APIs — cloud providers, CI systems, chat, ticketing — into workflows. Most “automation” is actually integration: take output from system A, transform it, feed it to system B.
• Reading tool source: when documentation ends, source code is the ground truth. Being able to read Go and Python means the entire cloud-native stack becomes legible.
• Extending platforms: Terraform providers, Kubernetes operators/controllers, CI plugins, Ansible modules, Backstage plugins all require real programming, not configuration.
• Debugging production: understanding memory models, concurrency, and I/O behavior of the apps you run helps you diagnose incidents faster. Knowing what a goroutine leak or a Python GIL contention looks like shortens an outage.
• Data wrangling: parsing logs, reshaping metrics, reconciling inventories, and generating reports are everyday tasks that reward a language with good text and data-structure support.

Scripting vs. tooling development

These are two distinct modes of programming in DevOps, and they favor different languages:

A common failure mode is a 2,000-line Bash script that should have been Python, or a quick Python script that grew into a critical service nobody can deploy reliably. Recognize when a script has crossed the line and rewrite it as a tool. Warning signs that a script has outgrown its language: it needs real data structures (nested maps, structs), it has more than a couple of functions, multiple people edit it, it runs on a schedule that matters, or a failure in it causes an incident.

The main languages in the DevOps ecosystem

The interpreted vs. compiled distinction

This single axis explains most of the practical differences you will feel day to day.

• Interpreted (Python, Ruby, JS): no build step, edit-and-run, excellent for exploration and one-offs. The cost is that the runtime (interpreter + dependencies) must be present on every target machine, and errors that a compiler would catch surface only when that line executes.
• Compiled (Go, Rust): a build step produces a self-contained artifact. The compiler catches whole classes of bugs before shipping, and the result runs with no runtime prerequisites. The cost is slower iteration and more ceremony.

For DevOps, the compiled model’s “one binary, no dependencies” property is disproportionately valuable: you can scp a Go binary to a bare host or drop it in a FROM scratch container and it just runs. That is why cloud-native tooling converged on Go.

Key Concepts

Which language to pick, and when

• Start with Python if you are new. It covers 80% of daily DevOps work: API calls, file/text processing, cloud SDKs, small web services, Ansible modules. Its readability makes shared team scripts sustainable.
• Learn Go second if you work with Kubernetes/cloud-native tooling, need to ship CLIs to teammates, or write controllers/operators. The single-binary distribution story alone justifies it, and the tooling you operate is written in it.
• Learn Ruby only if forced — i.e., your organization runs Chef or Puppet with heavy custom code. It is a lovely language, but new infrastructure work rarely starts in it.
• TypeScript makes sense when your org standardizes on AWS CDK or Pulumi, or when platform engineers serve predominantly Node.js product teams, or you are building internal developer portals (Backstage).
• Rust is an investment for performance-critical tooling (agents, proxies, eBPF, sidecars where every millisecond and megabyte counts); not a first or second language for most DevOps engineers.
• PowerShell is non-negotiable in Windows/Azure-heavy shops; its object pipeline is genuinely more powerful than text-based shells for structured data.

A decision cheat-sheet:

The same task in Python and Go

Checking a URL’s health — Python favors brevity:

import requests, sys

try:
    r = requests.get("https://example.com/healthz", timeout=5)
    r.raise_for_status()
    print("healthy")
except requests.RequestException as e:
    print(f"unhealthy: {e}")
    sys.exit(1)

Go favors explicit error handling and compiles to a dependency-free binary:

package main

import (
    "fmt"
    "net/http"
    "os"
    "time"
)

func main() {
    client := &http.Client{Timeout: 5 * time.Second}
    resp, err := client.Get("https://example.com/healthz")
    if err != nil || resp.StatusCode >= 400 {
        fmt.Println("unhealthy:", err)
        os.Exit(1)
    }
    fmt.Println("healthy")
}

Notice the trade-off in miniature: the Python version is shorter and needs requests installed; the Go version is longer, handles the error path explicitly (no hidden exceptions), and ships as a binary you can run anywhere with no interpreter. Neither is “better” — they optimize for different points in the scripting/tooling spectrum.

Concurrency models (why it matters for infra tooling)

DevOps tools are overwhelmingly I/O-bound: they wait on thousands of API calls, network reads, and disk operations. The concurrency model determines how gracefully a tool fans that work out.

• Python: asyncio for I/O-bound concurrency; the GIL (Global Interpreter Lock) restricts CPU-bound threading to one core at a time (use multiprocessing, concurrent.futures.ProcessPoolExecutor, or native extensions for CPU work). For “call 500 endpoints in parallel,” asyncio + aiohttp or a ThreadPoolExecutor works well because the waiting releases the GIL.
• Go: goroutines + channels make it trivial to fan out thousands of concurrent API calls or watch loops — the reason it dominates cloud-native tooling. A goroutine costs a few KB; you can spawn hundreds of thousands. sync.WaitGroup, context.Context for cancellation/timeouts, and channels for coordination are the everyday primitives.
• Node/TypeScript: single-threaded event loop; excellent for I/O-heavy glue, poor for CPU work (which blocks the loop — offload to worker threads). Promise.all for concurrent I/O.
• Rust: async/await with zero-cost abstractions over runtimes like Tokio; fearless concurrency enforced by the borrow checker at compile time — maximum control, maximum effort.

A concrete rule of thumb: if your tool’s job is “talk to many things at once and don’t fall over,” Go’s concurrency will save you the most grief; if it is “occasionally call a few APIs and process the result,” Python’s simplicity wins.

Distribution and packaging

How your code reaches machines matters as much as the code:

Cross-compiling a Go tool for a Linux server from your Mac is one line — no target machine, no toolchain on the host:

GOOS=linux GOARCH=amd64 go build -o myapp-linux-amd64 ./cmd/myapp
GOOS=linux GOARCH=arm64 go build -o myapp-linux-arm64 ./cmd/myapp   # for Graviton/ARM nodes

For Python, the modern answer to dependency hell is to stop installing into the system interpreter. Use per-project virtual environments and a lockfile-based tool:

python -m venv .venv && source .venv/bin/activate   # isolate dependencies
pip install -r requirements.txt                     # or: uv pip sync requirements.txt
pipx install some-cli-tool                           # install CLI tools in isolation

Type systems: dynamic vs. static, and gradual typing

Static typing (Go, Rust, TypeScript) catches a large class of errors — typos, wrong argument types, nil/None handling — before the code runs, which matters enormously for tools that mutate infrastructure where a runtime crash means a half-applied change. Dynamic languages trade that safety for speed of authoring.

The pragmatic middle ground is gradual typing: Python’s type hints checked by mypy/pyright, and TypeScript over JavaScript. You get much of the safety without abandoning the fast feedback loop. For any Python that lives longer than a week or is edited by more than one person, add type hints — the cost is small and the payoff (editor autocomplete, refactor safety, self-documentation) is large.

def scale_deployment(name: str, replicas: int, namespace: str = "default") -> None:
    ...   # a reviewer and mypy both know exactly what this expects

Beyond general-purpose languages

DevOps also involves domain-specific languages you should recognize. These are not substitutes for a programming language, but you will read and write them daily:

A recurring anti-pattern is pushing YAML or HCL past its limits with copy-paste and clever templating until it becomes an unmaintainable pseudo-program. When you feel that happening, that is the signal to move logic into a real language (Pulumi, CDK, a code generator) and treat the DSL as an output format.

Common pitfalls

• Rewriting everything in the “cool” language. A working Python script does not need to be Rust. Rewrites are justified by concrete pain (distribution, performance, safety), not fashion.
• Ignoring the distribution story until the end. A brilliant Python tool that nobody can install reliably is worse than a mediocre Go binary that just runs.
• Unpinned dependencies. “It worked yesterday” almost always traces to a floating dependency version.
• Shell scripts that should be programs. Once you need arrays of structured data, arithmetic on floats, or real error handling, Bash is fighting you.
• Hardcoded secrets and environment assumptions. Code that only runs on the author’s laptop because of implicit paths, env vars, or credentials.
• No tests on infra-mutating code. The blast radius of a bug in a provisioning tool is your production environment.

Best Practices

1. Master one language deeply before adding another. Shallow knowledge of three languages produces worse tooling than deep knowledge of one. Depth means you know the standard library, the idioms, and the debugging tools.
2. Match the language to the job’s lifespan and blast radius. Quick one-off task → shell/Python. Long-lived distributed tool → Go. Rewrite when a script outgrows its language rather than piling on complexity.
3. Version-control every script. If it ran in production once, it belongs in Git with history and review — not in someone’s home directory or a wiki page. Untracked automation is a future outage.
4. Pin and lock dependencies. Use requirements.txt with hashes / poetry.lock / uv.lock, go.mod + go.sum, package-lock.json, Cargo.lock. Unpinned dependencies are how “worked yesterday” breaks today and how supply-chain attacks land.
5. Write idempotent automation. Running a script twice must be safe. Check current state before mutating — the core idea behind Ansible and Terraform. Idempotency is what makes automation re-runnable after a partial failure.
6. Handle errors explicitly — never ignore them. A provisioning script that continues after a failed step causes half-configured systems, the worst state to debug. In Go, do not discard err; in Bash, use set -e; in Python, do not blanket-except: pass.
7. Add --dry-run (plan) flags to destructive tooling. Let operators preview changes before they touch production. This is why terraform plan exists before apply.
8. Use type hints and linters, and run them in CI. mypy/ruff for Python, golangci-lint/go vet for Go, ESLint + strict tsconfig for TS, clippy for Rust. Static analysis catches what tired reviewers miss and enforces consistency for free.
9. Format code automatically. gofmt/ruff format/prettier/rustfmt end style debates and keep diffs meaningful. Make formatting a pre-commit hook or CI check.
10. Log to stdout/stderr in structured form. Tools that print JSON logs integrate with any log pipeline; avoid writing your own log files that nobody rotates. Follow the twelve-factor rule: treat logs as an event stream.
11. Never hardcode secrets. Read from environment variables or a secrets manager (Vault, AWS Secrets Manager, SOPS); scan repos with tools like gitleaks or trufflehog in CI. A committed secret is compromised the moment it is pushed.
12. Write tests for anything that mutates infrastructure. Even a small pytest/go test suite over the logic (with mocked APIs) prevents expensive mistakes. Test the dangerous paths — deletion, scaling down, destructive migrations — hardest.
13. Make tools configurable, not hardcoded. Accept config via flags, env vars, and files (in that precedence order); provide sane defaults; validate inputs early and fail with a clear message.
14. Design for observability. Exit with meaningful codes, emit metrics or at least timing logs, and make failures diagnosable from output alone — you will run these tools at 3 AM.
15. Keep dependencies few and vetted. Every dependency is attack surface and future maintenance. Prefer the standard library; audit what you add; watch for abandoned packages.
16. Read the source of your tools. Cloning Kubernetes or Terraform and stepping through a code path is one of the fastest ways to level up — and the only way to truly understand a bug in them.

References

• DevOps Roadmap — roadmap.sh/devops
• Python official documentation
• Real Python — tutorials
• Go official documentation
• A Tour of Go
• Effective Go
• Go by Example
• Standard Go Project Layout
• Ruby official documentation
• TypeScript documentation
• The Rust Programming Language (book)
• PowerShell documentation
• Automate the Boring Stuff with Python — Al Sweigart
• uv — fast Python package manager
• Ruff — Python linter/formatter
• golangci-lint
• The Twelve-Factor App
• CNCF landscape
• Book: The Phoenix Project — Gene Kim, Kevin Behr, George Spafford (context on why automation matters)
• Book: The Go Programming Language — Donovan & Kernighan
• Book: Fluent Python — Luciano Ramalho (O’Reilly)
• Book: Site Reliability Engineering — Google (free online)