2026 DevOps stack update

Modern DevOps is converging on a smaller core stack: Kubernetes for running apps, GitHub Actions for pipelines, Terraform for infrastructure, and Git-based deploy tools for production. (kubernetes.io) Kubernetes is the software layer that schedules and scales containers across clusters, and the project’s own documentation describes it as an engine for automating deployment, scaling, and management of containerized applications. GitHub Actions says its workflows run directly in a repository and can automate build, test, and deployment jobs. (kubernetes.io) (docs.github.com) That combination is displacing older, more pieced-together setups built around Jenkins, the open-source automation server that still powers many build systems but usually requires separate hosting, plugins, and maintenance. Jenkins’ documentation still centers on installing and operating the server yourself, whether through packages, Docker, or a standalone Java archive. (jenkins.io 1) (jenkins.io 2) Terraform fills the infrastructure layer by turning cloud resources into versioned configuration files, with a write-plan-apply workflow that lets teams preview changes before creating them. HashiCorp’s documentation describes Terraform as infrastructure as code for cloud and on-premises resources, from compute and storage to higher-level services. (developer.hashicorp.com 1) (developer.hashicorp.com 2) Observability is the watchtower layer: metrics show system health over time, logs show what happened line by line, and traces follow a request across services. Grafana’s documentation groups metrics, logs, traces, and profiles as the core telemetry signals, while Grafana Loki stores logs by indexing labels rather than every log line’s full contents. (grafana.com 1) (grafana.com 2) That label-based design is why Loki often gets paired with Grafana dashboards in leaner stacks. Loki’s docs say it compresses log data into chunks and indexes metadata labels, which cuts storage and query overhead compared with systems that fully index raw log text. (grafana.com) (grafana.com) GitOps tools such as Argo CD and Flux move deployment control into Git, treating a repository as the source of truth for what should be running. Argo CD says it continuously compares the live cluster with the target state in Git, and Flux says it keeps clusters in sync with configuration sources such as Git repositories. (argo-cd.readthedocs.io) (fluxcd.io) That changes the shape of day-to-day operations: developers merge code, automation updates manifests, and the cluster reconciles itself back to the declared state. Argo CD’s documentation contrasts that model with imperative pipelines, where deployment logic lives inside scripts instead of a versioned configuration repository. (argo-cd.readthedocs.io) (argo-cd.readthedocs.io) The Amazon Web Services difficulty ranking that circulated alongside the stack map follows the same logic. Amazon Elastic Compute Cloud and Amazon Simple Storage Service are easier entry points because they map closely to familiar ideas—virtual servers and object storage—while Amazon Elastic Kubernetes Service adds the operational weight of Kubernetes itself. (docs.aws.amazon.com) (docs.aws.amazon.com) (docs.aws.amazon.com) AWS Step Functions lands higher on the difficulty curve because it asks teams to model software as state machines, with workflows made of event-driven steps, branching logic, retries, and service integrations. AWS says each workflow is defined in Amazon States Language and can coordinate distributed application components as a visual workflow. (docs.aws.amazon.com) (docs.aws.amazon.com) The practical message in both diagrams is less about brand names than about abstraction layers. Teams that can run containers, describe infrastructure as code, observe systems through shared telemetry, and deploy from Git are moving onto the part of the stack where scale problems usually start to show up. (kubernetes.io) (developer.hashicorp.com) (grafana.com)