Practice 02, Cloud and infrastructure

The path from commit to production, made boring.

We build Kubernetes platforms and internal developer platforms, define your infrastructure in Terraform, and instrument everything with OpenTelemetry. The result is repeatable environments, deploys your engineers run themselves, and an on-call rotation that stays quiet.

What this practice covers

Infrastructure that your team can reason about.

Most cloud pain is not about the cloud. It is snowflake environments nobody can reproduce, a deploy process only two people understand, and dashboards that light up after the customer already called. We fix the operational substrate: one governed platform, everything in code, and telemetry that tells you what broke before it pages you.

Kubernetes and developer platformsA governed cluster fleet with golden paths, so teams ship services without filing a ticket for every namespace, secret, or ingress route.
Infrastructure as code with TerraformEvery environment defined in version control, reviewed like application code, and applied through a pipeline with plan gates and drift detection.
Observability with OpenTelemetryMetrics, logs, and traces from one instrumentation standard, wired to SLOs and alerts that fire on symptoms your users feel, not on CPU graphs.
SRE, on-call, and cost engineeringError budgets, runbooks, blameless review, and a monthly bill you can explain line by line and actually bring down.

Scope a platform build See the stack we run

Reference engagement, at a glance

EnvironmentsDev, staging, prod, DR

IaC coverage98% in Terraform

Deploys per day60+, self-service

MTTRUnder 20 minutes

Change failureUnder 8%

Monthly cost trendDown 62%

Platform uptime99.98% median

On-call24/7, managed option

Error budget healthy

What we build

Five pieces of the operational substrate.

Each of these ships as working infrastructure with the documentation and pipelines to keep it working after we leave. We build in vertical slices, so a real service reaches production early rather than at the end.

01 / Platform

Kubernetes platforms

A governed cluster fleet with sane defaults for networking, autoscaling, secrets, and multi-tenancy. Namespaces, quotas, and RBAC are provisioned from templates, not hand-edited YAML.

02 / IDP

Internal developer platform

Golden paths that turn a new service from a repository into a running deployment with logging, metrics, and a CI pipeline attached. Developers self-serve; the platform stays governed.

03 / IaC

Infrastructure as code

Terraform modules for networks, clusters, databases, and IAM, composed per environment. Changes go through plan review and are applied by a pipeline, with drift detection catching anything edited by hand.

04 / Observability

OpenTelemetry pipeline

One instrumentation standard emitting metrics, logs, and traces through the OTel collector to your backend of choice. Trace context follows a request across services, so you can see where the latency actually went.

05 / SRE

SRE and on-call

SLOs tied to user-visible behavior, error budgets that gate risky changes, runbooks for the alerts that page, and a rotation designed so the pager stays quiet on a normal night.

06 / Cost

Cost engineering

Spend attributed to teams and services, rightsized requests, spot and committed-use where it fits, and a monthly trend you can defend. We treat the bill as an engineering metric, not a finance surprise.

How a platform engagement runs

From audit to a platform your team owns.

Audit and target architecture

We inventory what you run today: clusters, accounts, pipelines, and the spend behind them. Then we agree a target platform, the golden paths it exposes, and the SLOs it has to hold. Two weeks, fixed fee.

Inventory SLO targets Cost baseline

Build the platform in code

Terraform modules, cluster provisioning, the OTel pipeline, and CI templates land in your repositories with plan gates on every change. One real service migrates onto the golden path first, end to end, so the platform is proven under real traffic before the fleet moves.

Terraform modules Cluster fleet OTel collector

Migrate, harden, and hand over

Services move onto the platform in waves, with observability and cost attribution in place from day one. We set up the on-call rotation, write the runbooks, and either operate it under an SLO or hand it cleanly to your team. No lock-in to us.

Wave migration Runbooks On-call rotation

Everything in code

A module you can read, and a pipeline that applies it.

Environments are composed from small, reviewed Terraform modules. Nothing reaches production by hand. The pipeline plans on every pull request, requires an approval, then applies, so an environment is a diff you can read rather than a state nobody remembers creating.

Plan on every changeThe pipeline posts a plan to the pull request so reviewers see exactly what will change before anything applies.
Drift detectionA scheduled plan flags any resource edited outside the pipeline, so the code stays the source of truth.
Policy as codeGuardrails reject public buckets, untagged spend, and missing SLO labels before they merge.

platform/service.tf

# one golden-path service, fully governed

module "ledger_api" {

source = "./modules/service"

name = "ledger-api"

cluster = module.platform.prod

replicas_min = 3

cpu_request = "250m"

slo_target = 99.95

otel_export = true

cost_owner = "payments"

}

pipeline.log

> terraform plan // on pull request

> plan: 2 to add, 1 to change, 0 to destroy

> policy check passed, review approved

> apply complete, drift none in 38s

Observability that maps to reliability

The signals we wire up, and why.

One OpenTelemetry standard produces the three signal types below. We connect them to SLOs so an alert means a user is affected, not that a graph moved.

Signal	What it answers	How we use it
Metrics	Is the service inside its latency and error budget right now?	Drive SLO burn-rate alerts and the request-level dashboards on-call opens first.
Traces	Which hop in a request path added the latency?	Follow trace context across services to find the slow dependency instead of guessing.
Logs	What exactly happened around a specific failing request?	Correlate by trace ID so a log line links straight to the trace that produced it.
Cost	Which team or service is driving the monthly trend?	Attribute spend by label so a cost spike has an owner, not a mystery.

Related work

Eleven clusters into one governed platform.

Helio Energy had grown eleven ad hoc Kubernetes clusters across teams, each with its own deploy process and its own bill. We consolidated them into a single governed platform with self-service golden paths, moved every environment into Terraform, and wired cost attribution to each service. Infrastructure spend fell 62% and over 400 services now deploy themselves.

We went from arguing about who owns which cluster to shipping on one platform nobody has to think about. The bill dropped and the pager got quieter in the same quarter.

Sofia Reinhardt

CTO, Helio Energy

Energy / Platform

Kubernetes platform consolidation

Merged eleven ad hoc clusters into one governed internal platform with self-service deploys, infrastructure in Terraform, and per-service cost attribution.

62%Infra cost cut

400+Services

View all case studies

What good looks like

The numbers we hold a platform to.

99.98%

Median platform uptime over twelve months

60+

Self-service production deploys per day

62%

Infrastructure cost cut on a consolidation

6 wk

Median time from kickoff to first release

Common questions

Before you commit a platform budget.

No. Kubernetes earns its keep when you run many services with varied scaling needs. If you run a handful of steady workloads, managed compute or serverless is often the cheaper, quieter choice, and we will say so. The audit decides based on your actual workloads, not a default answer.

AWS, Google Cloud, and Azure. We write the platform in Terraform against provider modules, so the golden paths and pipelines look the same to your engineers regardless of which one you run on. We do not chase multi-cloud for its own sake, because it doubles the operational surface for a benefit most teams never use.

First by attributing spend to teams and services so waste has an owner. Then by rightsizing requests against real usage, retiring idle resources, using spot capacity for tolerant workloads, and committing to reservations where the baseline is predictable. The Helio Energy consolidation cut infrastructure cost by 62%, mostly from removing duplicate clusters and rightsizing what remained.

Yes. Managed operation is optional and comes with defined SLOs, runbooks, and 24/7 on-call from our engineers. Many clients start with us operating it and take the rotation in-house once the platform is stable and the runbooks are proven. Either path is a clean handover, because everything is in code and documented.

All of it. The Terraform, the pipelines, the OpenTelemetry configuration, the dashboards, and the runbooks live in your repositories under your control. There is no proprietary layer you have to license from us and no component only we can operate. If you take it fully in-house, the handover is a set of documented systems, not a dependency on our calendar.

The other three practices

One engineering standard, four practices.