Buckingham Cloud

Si una entrada te sirvió, hay una forma de seguir la pista

La bitácora se arma con lo que aparece en producción: límites de recursos mal calibrados, estados de Terraform que se pisan, colas que acumulan mensajes muertos. Cada tema queda etiquetado por redes, almacenamiento o CI/CD para que puedas volver cuando el problema reaparezca. Si querés plantear un caso concreto de tu equipo, escribinos y lo miramos con el mismo criterio con el que escribimos las notas.

Escribir al equipo

También podés revisar primero qué cubrimos y con qué enfoque antes de mandar tu consulta.

Entradas programadas de la bitácora

Lo que viene en Buckingham Cloud: revisiones de límites en Kubernetes, estado remoto en Terraform, ruido en observabilidad, colas con reintentos, facturas de nube y migraciones de servicios legados. Cada texto sale con fragmentos de configuración, capturas de paneles y comparativas sin patrocinio.

Terminal con manifiestos de Kubernetes y métricas de uso de recursos en pantalla

Kubernetes en producción: límites de recursos que sí evitan caídas

Cómo ajustar requests y limits sin ahogar los pods

Los límites de recursos en Kubernetes parecen simples hasta que un pod empieza a reiniciarse sin motivo aparente. En este repaso se comparan requests y limits mal calibrados con configuraciones que sostienen cargas variables, se muestran fragmentos de manifiestos y se explica cómo leer los eventos del scheduler y del kubelet para distinguir falta de memoria de throttling de CPU. También se comentan los errores más comunes al copiar valores de un entorno de pruebas a producción y qué métricas conviene vigilar antes de tocar los números.

Leer la entrada
Pantalla con archivos de configuración de Terraform y plan de cambios resaltado

Terraform con estado remoto: cuándo el backend local deja de servir

Bloqueos, concurrencia y trabajo en equipo sobre la misma infraestructura

Trabajar con Terraform en solitario es cómodo hasta que dos personas aplican cambios el mismo día. Este artículo describe los síntomas típicos del estado local compartido por accidente: planes que se pisan, recursos huérfanos y bloqueos que nadie declaró. Se revisa cómo funciona el locking en backends remotos, qué precauciones tomar antes de mover el archivo de estado y cómo verificar que el plan sigue siendo el esperado después de la migración. Incluye fragmentos de configuración y una lista de comprobaciones previas al cambio.

Leer la entrada
Panel de monitoreo con gráficos de métricas y registros de eventos

Observabilidad sin ruido: métricas, logs y trazas que sí se usan

Cómo reducir el volumen de datos sin perder capacidad de diagnóstico

Acumular métricas, logs y trazas es fácil; decidir cuáles sirven para diagnosticar incidentes es otra cosa. Aquí se plantea un criterio para clasificar señales por su valor operativo, se muestran ejemplos de paneles que priorizan pocas series bien elegidas y se discute cuándo conviene muestrear trazas en lugar de guardarlas todas. También se abordan los costos asociados al almacenamiento prolongado y las decisiones de retención que suelen tomar los equipos de plataforma.

Leer la entrada
Diagrama de flujo de mensajes entre productores y consumidores en una cola

Colas de mensajes: reintentos, letras muertas y duplicados

Patrones para que un mensaje fallido no arrastre al resto del sistema

Cuando un consumidor falla, la cola puede convertirse en un amplificador de errores si no hay una política clara de reintentos. Este texto compara enfoques de backoff, colas de mensajes muertos y deduplicación por clave de idempotencia, con ejemplos de configuración en brokers conocidos. Se explica por qué los reintentos infinitos esconden fallos de diseño y cómo medir la antigüedad de los mensajes pendientes para detectar acumulación. El cierre incluye criterios para decidir cuándo descartar un mensaje y cuándo alertar a un humano.

Leer la entrada
Gráfico de costos de servicios en la nube con desglose por categoría

Costos de instancias en la nube: dónde se escapa el presupuesto

Revisión de recursos sobredimensionados y apagados olvidados

La factura de nube rara vez sube por un solo recurso; suele ser la suma de instancias sobredimensionadas, discos huérfanos y entornos de prueba que nadie apaga. Este artículo propone una revisión periódica de los servicios con mayor gasto, muestra cómo etiquetar recursos para atribuir costos a equipos y advierte sobre compromisos de uso que se contratan sin medir la demanda real. No promete ahorros mágicos: describe hábitos de revisión que ayudan a mantener el gasto alineado con el uso.

Leer la entrada
Contenedores y servicios desplegados en un clúster con registros de arranque

Migrar un servicio legado a contenedores: errores que se repiten

Supuestos sobre estado, red y arranque que rompen la primera versión

Mover un servicio legado a un contenedor suele chocar con supuestos que el código daba por sentados: rutas absolutas, estado en disco, dependencias de red o arranques que tardan más de lo que la sonda de vida tolera. Este texto recoge patrones de fallo observados en migraciones y propone una secuencia de verificación antes de exponer el servicio al tráfico. Se comentan también los ajustes de readiness y liveness que evitan reinicios en cascada y cómo separar la configuración del entorno sin recompilar la imagen.

Leer la entrada

Las entradas se agrupan con etiquetas como redes, almacenamiento o CI/CD para que puedas volver sobre un tema concreto cuando lo necesites. Si querés recibir las nuevas publicaciones, la suscripción al boletín semanal está disponible desde la página de contacto.

Buckingham Cloud

Bitácora técnica independiente

Esta bitácora la sostiene un equipo de ingenieros que trabaja a diario con clústeres en producción. No hay una firma externa ni un patrocinador detrás: lo que se publica sale de incidentes reales, de planes de Terraform que se torcieron y de paneles que alguien tuvo que leer a las tres de la mañana. Cada entrada se revisa antes de salir y se corrige cuando una práctica queda obsoleta.

El material está pensado para quien toma decisiones concretas: equipos de plataforma, SRE y desarrolladores backend que necesitan saber qué configuración aguanta una carga variable y cuál solo funciona en un entorno de pruebas. Por eso cada publicación incluye fragmentos de configuración, capturas de paneles y comparativas de herramientas sin patrocinio, con las limitaciones a la vista y no escondidas en una nota al pie.

Los temas se agrupan con etiquetas como redes, almacenamiento o CI/CD, para que puedas volver sobre un asunto puntual sin releer todo el archivo. Si algo de lo que se documenta aquí te sirve, la suscripción al boletín semanal llega con las entradas nuevas y las correcciones que se van acumulando.

Quiénes escriben esta bitácora Consultas y suscripción al boletín

Por qué volvemos a esta bitácora antes de tocar producción

No publicamos notas por llenar el archivo. Cada entrada sale de un problema que ya nos tocó resolver, con el manifiesto, el panel o la comparación que usamos en ese momento. Si algo no lo probamos, lo decimos.

Sin patrocinio ni notas de prensa

Cuando comparamos dos herramientas, la comparación incluye lo que no nos gustó. No hay acuerdos con proveedores ni enlaces pagos escondidos en el texto. Si una solución nos decepcionó, queda escrito con el mismo detalle que la que sí funcionó.

Fragmentos que se pueden copiar

Los manifiestos de Kubernetes, los bloques de Terraform y las configuraciones de colas aparecen completos y con el contexto donde fallaron. No son ejemplos de laboratorio: vienen de clústeres con tráfico real, límites mal calibrados y despliegues que se rompieron antes de quedar bien.

Capturas de paneles reales

Cuando una métrica explica un incidente, mostramos el panel. Preferimos pocas series bien elegidas antes que un tablero lleno de ruido. Eso también sirve para discutir retención, costos de almacenamiento y qué señales conviene muestrear.

Ordenado por etiquetas, no por fecha

El archivo se agrupa por redes, almacenamiento, CI/CD y otros temas recurrentes. Así un equipo de plataforma puede volver a una entrada concreta cuando el problema reaparece, en lugar de recorrer meses de publicaciones hasta encontrar lo que buscaba.

Escrito para quien decide

El tono apunta a SRE, equipos de plataforma y desarrolladores backend que necesitan criterio, no teoría. Cada nota cierra con lo que haríamos distinto la próxima vez, aunque eso signifique admitir que el primer enfoque estaba mal.

Un boletín, sin relleno

La suscripción semanal avisa cuando hay una entrada nueva, sin campañas ni recordatorios automáticos. Si querés ver primero cómo trabajamos, podés empezar por los servicios que cubrimos o volver al índice de la bitácora.

Consultas sobre la bitácora y cómo seguir una entrada

Si algo de un artículo no cierra, si un fragmento de configuración no coincide con tu versión o si querés proponer un tema para las próximas notas, escribinos. No hay mesa de ayuda ni tiempos de respuesta garantizados: leemos los mensajes cuando podemos y contestamos por correo cuando corresponde.

Correo directo hello@buckinghamcloud.com es la vía más simple para dudas sobre Kubernetes, Terraform, observabilidad o cualquier entrada publicada. Contanos en qué versión estás trabajando y qué error viste, así podemos ubicar el caso. Teléfono +54 11 4281-7054 queda disponible para conversaciones puntuales sobre infraestructura. Si el tema es extenso, mejor arrancar por correo y dejar el teléfono para lo que no se resuelve escribiendo. Formulario de contacto La página de contacto acepta consultas generales, sugerencias de temas y correcciones sobre fragmentos de configuración. El formulario no crea cuenta ni suscripción: solo deja el mensaje en el procesador y muestra la confirmación técnica. Guía de etiquetas y material previo Antes de escribir, vale la pena revisar la guía central: ahí se explica cómo están agrupadas las entradas por etiquetas como redes, almacenamiento o CI/CD, y qué tipo de material práctico incluye cada publicación.

Las dudas sobre una entrada puntual se responden mejor si citás el título, la sección y el fragmento exacto del manifiesto o del plan de Terraform que no está funcionando. No prometemos revisar configuraciones completas ni depurar entornos ajenos, pero sí aclarar lo que quedó ambiguo en el texto.

Política del sitio Términos de uso
Configuracion de cookies

Usamos cookies para mantener el sitio estable, recordar opciones basicas y entender que paginas resultan utiles. Puedes aceptar, rechazar o revisar la configuracion antes de continuar.

ES EN