For Business | Buckingham Cloud

What changes when infrastructure is decided with production data

These are the situations that come up most often in teams that turn to the log looking for judgment to move real workloads. They are not platform promises: they are points where a concrete decision about Kubernetes, Terraform, or message queues prevents weeks of later adjustments.

Migrating a legacy service without taking the business offline

When the old service carries absolute paths, on-disk state, and slow startups, the container works locally and fails in the cluster. The migration notes document that verification sequence before exposing traffic: well-calibrated readiness and liveness probes, configuration separated from the environment, and a list of assumptions worth reviewing before the first deployment.

Resource limits that do not choke the pods

A pod that restarts for no apparent reason almost always points to requests and limits copied incorrectly from tests. The articles about Kubernetes in production show how to read scheduler and kubelet events to distinguish lack of memory from CPU throttling, and which metrics are worth monitoring before touching the numbers.

Shared Terraform without stepping on someone else's plan

Local state stops working the day two people apply changes. Posts about remote backends describe the typical symptoms: plans that overwrite each other, orphaned resources, and locks nobody declared. They include checks to run before moving the state file and how to confirm the plan is still the expected one after the migration.

Observability that actually gets used during an incident

Accumulating metrics, logs, and traces is easy; deciding which ones help diagnose is another matter. Here a criterion is proposed for classifying signals by operational value, with examples of dashboards that prioritize a few well-chosen series and discussions about when to sample traces instead of storing them all.

Queues that don't amplify an error

Without a clear retry policy, a failing consumer drags down the rest of the system. Comparisons of backoff, dead-letter queues, and deduplication by idempotency key help decide when to discard a message and when to alert a person, instead of retrying endlessly.

Instance costs that don't blow past the budget

The bill rarely goes up because of a single resource: it is the sum of oversized instances, orphaned disks, and test environments that no one shuts down. Notes on costs recommend periodic reviews, tagging to attribute spending to teams, and warnings about usage commitments signed without measuring actual demand.

If you want to see how these decisions are applied in a specific context, review the services we document or the details of the topics we cover.

What you see when a legacy service is already running in the cluster

Screenshots of dashboards and diagrams we use in our enterprise notes. They are not mockups: they are the views a platform team looks at three in the morning when something restarts. Each image accompanies a specific entry about migration, resource limits, or message queues.

CPU limits that prevent restarts in production

The screenshot shows a pod that restarts every few minutes due to a memory limit copied from the test environment. In the note we compare poorly calibrated requests and limits with values that sustain variable load, and we explain how to read kubelet events to distinguish out-of-memory from CPU throttling.

The Terraform plan before moving the state

When two people apply changes on the same day to a local state, the plan stops being reliable. This view documents the moment before migrating to a remote backend: locks, orphaned resources, and the verification we do afterward to confirm that the plan is still the expected one.

A dashboard with a few well-chosen series

Accumulating metrics and traces is easy; deciding which ones help diagnose an incident is another matter. The observability post's dashboard prioritizes a few series with operational value and leaves out the noise that only inflates the cost of long-term storage.

Retries, dead letters, and duplicates in a queue

The diagram traces the journey of a message that fails three times before landing in the dead-letter queue. It helps explain why infinite retries hide design flaws and how to measure the age of pending items to detect buildup before it shows up in the consumer.

Where the budget leaks every quarter

The bill rarely goes up because of a single resource. This view breaks down oversized instances, orphaned disks, and test environments nobody shuts down, and accompanies the note on review and tagging habits to attribute spending to each team without promising magic savings.

The startup that the liveness probe does not tolerate

A legacy service that worked locally restarts in a cascade when containerized because it takes longer than the liveness probe accepts. The screenshot captures the startup logs and the readiness and liveness settings that separate environment configuration without rebuilding the image.

If your team is migrating a legacy service, start with a concrete note

You don't need a full transformation to benefit from the log. It's enough to pick a real problem — pod restarts, shared Terraform state, costs that grow without explanation — and read how other platform teams solved it in production. Each entry includes configuration snippets, dashboard screenshots, and unsponsored comparisons, so you can weigh the trade-offs before touching the cluster. If you'd rather start with the big picture, review the scenarios we've already covered for organizations migrating distributed workloads.

Write to us and tell us your case

You can also see the services we document or review the technical notes grouped by topic.