<p><em>You already know the tools. Here is what happens when you stop using them separately.</em></p>
<p>Every DevOps engineer hits a moment where the job quietly changes underneath them.</p>
<p>You are not just shipping code anymore. You are shipping the system other engineers use to ship code. That shift has a name: platform engineering. The tools to do it right are not new. You probably have most of them running already. The question is whether they are working together or just coexisting.</p>
<h2>Docker: The Baseline</h2>
<p>Everything starts with a container. Docker changed the contract between developers and infrastructure forever. You ship the environment along with the code. In 2026 this is not a debate. It is step one. Everything else in this stack assumes your workloads are containerized.</p>
<h2>Kubernetes: The Runtime</h2>
<p>Docker tells you how to package a workload. Kubernetes tells you how to run it at scale. 82% of container users now run Kubernetes in production. The moment you have more than a handful of services, you need something handling scheduling, health checks, scaling, and networking. Kubernetes does this as a baseline.</p>
<p>The model that matters: declarative config, desired state, reconciliation loops. Internalise that and the rest of the stack makes sense immediately.</p>
<h2>Argo CD: The GitOps Engine</h2>
<p>Running workloads is one thing. Changing them safely is another. GitOps solves this. Git becomes the single source of truth. Every change goes through a pull request. Argo CD watches the repo and reconciles the cluster to match it continuously. No manual kubectl in production. No snowflake clusters. Every deployment is auditable because every deployment is a Git commit.</p>
<p>The mental model: humans own intent, the platform owns reconciliation.</p>
<h2>Observability: Seeing Inside the System</h2>
<p>You can run a system. You can deploy to it. But until you can see inside it, you are flying blind. Observability means three things working together: metrics, logs, and distributed traces. Metrics tell you something changed. Logs tell you what happened. Traces tell you why, across every service involved.</p>
<p>OpenTelemetry is the standard that ties this together. 89% of organisations have consolidated on OTel-compatible stacks. It is not a monitoring tool. It is the vendor-neutral instrumentation layer that feeds Prometheus, Loki, Tempo, and Grafana. Standardise on it early and you will never be locked to a vendor again.</p>
<h2>The Moment Everything Changes</h2>
<p>Here is where it gets interesting.</p>
<p>You have all four pieces. But a developer wanting to ship a new service still has to wire up the Argo CD application manually, manage service URLs across environments, configure Prometheus scraping, and write a CI pipeline that matches everyone else’s format.</p>
<p>The tools are doing their jobs. The developer is doing the glue work the platform should be doing.</p>
<p>This is the gap platform engineering exists to close. When you close it, what you have built has a name: an <strong>Internal Developer Platform</strong>.</p>
<p>An IDP is what emerges when your tools stop being separate things and become a coherent system. A developer declares a new service. The platform creates the namespace, wires the pipeline, configures Argo CD, injects service URLs, and sets up telemetry collection. All of it. Without a ticket. The platform team stops being the bottleneck and becomes the team that removes bottlenecks.</p>
<h2>The Layer That Connects Everything</h2>
<p>The CNCF ecosystem has the building blocks: Kubernetes, Argo CD, OpenTelemetry, Backstage. What has been harder is the layer that connects them, the one that translates developer intent into platform reality, enforces golden paths, and makes observability automatic rather than optional.</p>
<p>That is exactly what OpenChoreo was built for. It is an open-source IDP for Kubernetes and a CNCF Sandbox project. The stack described above is still the foundation. But instead of wiring it together yourself, OpenChoreo provides the abstractions on top. A developer declares a Component, what it listens on, what it depends on, what environment it needs. The platform handles the rest including a built-in Backstage-powered developer portal.</p>
<p>The stack you have been assembling piece by piece becomes a platform. The platform becomes what makes your entire organisation faster.</p>
<h2>Where to Start</h2>
<p>Get comfortable with Kubernetes first. Add Argo CD and commit hard to the GitOps discipline. Instrument one service with OpenTelemetry and make that the default for everything that follows. When the glue work starts feeling expensive, that is the signal to look at OpenChoreo. It runs locally on a single cluster in under thirty minutes.</p>
<p>The tools are ready. The ecosystem is mature. The only question is whether you are building a collection of tools or a platform.</p>
<p>Build the platform.</p>

Smiley Face

DevOps Daily

Platform engineering is the natural evolution of DevOps, where you build the system other engineers use to ship code. The core stack consists of Docker for containerization, Kubernetes for orchestration, Argo CD for GitOps-based deployments, and OpenTelemetry for observability. The real shift happens when these tools stop coexisting separately and become a coherent Internal Developer Platform (IDP) — automating namespace creation, pipeline wiring, telemetry setup, and more without manual glue work. OpenChoreo, a CNCF Sandbox open-source IDP, is highlighted as a layer that connects these building blocks and provides developer-facing abstractions including a Backstage-powered portal. The recommended path: master Kubernetes, adopt GitOps with Argo CD, standardize on OpenTelemetry, then evaluate an IDP layer when integration overhead becomes costly.

The Platform Engineering Stack Every DevOps Engineer Needs to Know