Buckingham Cloud

If an entry was useful to you, there is a way to keep track of it

The log is built from what shows up in production: poorly calibrated resource limits, overlapping Terraform states, queues that accumulate dead messages. Each topic is tagged by networking, storage, or CI/CD so you can come back when the problem reappears. If you want to raise a specific case from your team, write to us and we will look at it with the same criteria we use when writing the notes.

Write to the team

You can also first review what we cover and with what approach before sending your inquiry.

Scheduled log entries

What's coming on Buckingham Cloud: Kubernetes limit reviews, Terraform remote state, observability noise, queues with retries, cloud bills, and legacy service migrations. Each piece comes with configuration snippets, dashboard screenshots, and unsponsored comparisons.

Terminal with Kubernetes manifests and resource usage metrics on screen

Kubernetes in production: resource limits that actually prevent outages

How to tune requests and limits without starving your pods

Resource limits in Kubernetes look simple until a pod starts restarting for no apparent reason. This review compares poorly calibrated requests and limits with configurations that sustain variable workloads, shows manifest snippets, and explains how to read scheduler and kubelet events to tell memory shortage apart from CPU throttling. It also covers the most common mistakes when copying values from a test environment to production and which metrics are worth watching before touching the numbers.

Read the entry
Screen with Terraform configuration files and highlighted change plan

Terraform with remote state: when the local backend stops working

Locking, concurrency, and teamwork on the same infrastructure

Working with Terraform solo is comfortable until two people apply changes on the same day. This article describes the typical symptoms of accidentally shared local state: plans that overwrite each other, orphaned resources, and locks that no one declared. It reviews how locking works in remote backends, what precautions to take before moving the state file, and how to verify that the plan is still the expected one after the migration. It includes configuration snippets and a pre-change checklist.

Read the entry
Monitoring dashboard with metric charts and event logs

Observability without noise: metrics, logs, and traces that are actually used

How to reduce data volume without losing diagnostic capability

Accumulating metrics, logs, and traces is easy; deciding which ones are useful for diagnosing incidents is another matter. Here, a criterion is proposed for classifying signals by their operational value, examples of dashboards that prioritize a few well-chosen series are shown, and it is discussed when it is better to sample traces instead of storing all of them. The costs associated with long-term storage and the retention decisions that platform teams usually make are also addressed.

Read the entry
Flow diagram of messages between producers and consumers in a queue

Message queues: retries, dead letters, and duplicates

Patterns to keep a failed message from dragging down the rest of the system

When a consumer fails, the queue can become an error amplifier if there is no clear retry policy. This text compares backoff approaches, dead-letter queues, and deduplication by idempotency key, with configuration examples in well-known brokers. It explains why infinite retries hide design flaws and how to measure the age of pending messages to detect accumulation. The closing includes criteria for deciding when to discard a message and when to alert a human.

Read the entry
Cloud service cost chart with breakdown by category

Cloud instance costs: where the budget leaks

Review of oversized and forgotten shut-down resources

The cloud bill rarely goes up because of a single resource; it is usually the sum of oversized instances, orphaned disks, and test environments that nobody shuts down. This article proposes a periodic review of the highest-spend services, shows how to tag resources to attribute costs to teams, and warns about usage commitments that are signed without measuring actual demand. It does not promise magic savings: it describes review habits that help keep spending aligned with usage.

Read the post
Containers and services deployed in a cluster with startup logs

Migrating a legacy service to containers: mistakes that keep happening

Assumptions about state, networking, and startup that break the first version

Moving a legacy service into a container often clashes with assumptions the code took for granted: absolute paths, on-disk state, network dependencies, or startups that take longer than the liveness probe tolerates. This text gathers failure patterns observed in migrations and proposes a verification sequence before exposing the service to traffic. It also discusses readiness and liveness settings that prevent cascading restarts and how to separate environment configuration without rebuilding the image.

Read the entry

Entries are grouped with tags such as networking, storage, or CI/CD so you can return to a specific topic whenever you need to. If you want to receive new posts, the weekly newsletter subscription is available from the contact page.

Buckingham Cloud

Independent technical logbook

This logbook is maintained by a team of engineers who work with production clusters every day. There is no external firm or sponsor behind it: what gets published comes from real incidents, from Terraform plans that went sideways, and from dashboards that someone had to read at three in the morning. Every entry is reviewed before it goes out and is corrected when a practice becomes outdated.

The material is intended for those who make concrete decisions: platform teams, SREs, and backend developers who need to know which configuration holds up under variable load and which only works in a test environment. That is why each publication includes configuration snippets, dashboard screenshots, and unsponsored tool comparisons, with limitations in plain sight and not hidden in a footnote.

Topics are grouped with tags such as networking, storage, or CI/CD, so you can return to a specific subject without rereading the entire archive. If something documented here is useful to you, the weekly newsletter subscription arrives with new entries and the corrections that accumulate over time.

Who writes this logbook Inquiries and newsletter subscription

Why we keep coming back to this log before touching production

We don't publish posts just to fill the archive. Every entry comes from a problem we already had to solve, with the manifest, the dashboard, or the comparison we used at that moment. If we haven't tested something, we say so.

No sponsorships or press releases

When we compare two tools, the comparison includes what we didn't like. There are no deals with vendors or paid links hidden in the text. If a solution disappointed us, it's written up with the same detail as the one that did work.

Snippets you can copy

Kubernetes manifests, Terraform blocks, and queue configurations appear complete and with the context where they failed. They aren't lab examples: they come from clusters with real traffic, poorly calibrated limits, and deployments that broke before they worked.

Screenshots of real dashboards

When a metric explains an incident, we show the dashboard. We prefer a few well-chosen series over a board full of noise. That also helps when discussing retention, storage costs, and which signals are worth sampling.

Sorted by tags, not by date

The archive is grouped by networks, storage, CI/CD, and other recurring topics. This way a platform team can return to a specific entry when the problem reappears, instead of scrolling through months of posts to find what they were looking for.

Written for those who decide

The tone is aimed at SREs, platform teams, and backend developers who need judgment, not theory. Each note closes with what we would do differently next time, even if that means admitting the first approach was wrong.

A newsletter, without filler

The weekly subscription notifies you when there is a new entry, with no campaigns or automatic reminders. If you want to see how we work first, you can start with the services we cover or go back to the log index.

Questions about the blog and how to follow a post

If something in an article doesn't add up, if a configuration snippet doesn't match your version, or if you want to suggest a topic for upcoming posts, write to us. There is no help desk and no guaranteed response times: we read messages when we can and reply by email when appropriate.

Direct email hello@buckinghamcloud.com is the simplest way to ask questions about Kubernetes, Terraform, observability, or any published post. Tell us which version you're working with and what error you saw, so we can locate the case. Phone +54 11 4281-7054 is available for specific conversations about infrastructure. If the topic is extensive, it's better to start by email and leave the phone for what can't be resolved in writing. Contact form The contact page accepts general inquiries, topic suggestions, and corrections about configuration snippets. The form does not create an account or subscription: it only leaves the message with the processor and shows the technical confirmation. Guide to tags and prior material Before writing, it is worth reviewing the central guide: it explains how entries are grouped by tags such as networking, storage, or CI/CD, and what type of practical material each post includes.

Questions about a specific entry are best answered if you cite the title, the section, and the exact excerpt from the manifest or the Terraform plan that is not working. We do not promise to review complete configurations or debug external environments, but we will clarify what remained ambiguous in the text.

Site policy Terms of use
Cookie settings

We use cookies to keep the site stable, remember basic options, and understand which pages are useful. You can accept, reject, or review the settings before continuing.

ES EN