Principia #4: Segmentación
Porque con un buen vallado se consiguen buenos vecinos
A lo largo de mi carrera, me he encontrado más de una vez con entornos de desarrollo y producción mezclados, llegando incluso a compartir el mismo servidor de base de datos. Esta es una situación completamente normal en una startup o en empresas más pequeñas y tradicionales, donde se busca la máxima optimización de los costes de infraestructura o en las que se tiene una visión menos cloud-native.
Si el equipo que gestiona toda esa infraestructura centralizada es el mismo, es posible mantener cierto control sobre la situación. Pero si lo que queremos es fomentar una cultura DevOps, donde cada equipo de desarrollo sea autónomo y gestione sus servicios de principio a fin, entonces más nos vale establecer fronteras claras y seguras en la infraestructura.
Las consecuencias de no hacerlo pueden ser devastadoras. He visto desaparecer bases de datos enteras de producción durante un ciclo de desarrollo. También he presenciado cómo una prueba de carga lanzada alegremente en staging provocaba una contención brutal en los discos compartidos y la consiguiente caída de los sistemas de producción. Es mucho más común de lo que creemos.
Good fences make good neighbors
— Robert Frost
Para evitar estos desastres y habilitar la autonomía, hay que contar con un buen diseño de segmentación de nuestras cargas de trabajo. De hecho, es uno de los pilares de la arquitectura de plataformas que trato en mi libro Crafting Platforms, cuyo capítulo dedicado a la segmentación publicaré precisamente esta misma semana. Hoy quiero traer la esencia de este concepto a la newsletter.
El porqué
Formalmente, un segmento es un límite físico o lógico que delimita un conjunto de cargas de trabajo, recursos y usuarios en la infraestructura. No se trata solo de agrupar cosas en carpetas. Lo fundamental de un segmento es que define un conjunto específico de capacidades, guardrails y restricciones.
Si tienes una infraestructura monolítica, dependes de complejas configuraciones de red o de políticas de IAM (Identity and Access Management) frágiles para evitar exposiciones. La segmentación te proporciona aislamiento por diseño. Sus principales beneficios son:
Reducción del radio de explosión (Blast Radius): Contiene los fallos. Si un proceso se vuelve loco o si hay una brecha de seguridad, el desastre se queda aislado en su parcela.
Reducción de la carga cognitiva: Un ingeniero no tiene que lidiar con toda la infraestructura de la empresa, sino solo con la que es relevante para su servicio.
Diferentes reglas para contextos distintos: Las estrictas políticas de auditoría que necesitas en producción son un estorbo en un entorno de desarrollo donde hace falta experimentar.
Cuatro dimensiones
Para no acabar gestionando cientos de cuentas anidadas ni paralizando a la organización cuando ocurra un problema por tenerlo todo agrupado en una sola cuenta, recomiendo segmentar por cuatro dimensiones principales.
Sector (o Dominio): Separa el contexto del negocio del contexto interno o de habilitación. Un sector define una gobernanza y un propósito claros. Por ejemplo:
Core (o Platform): herramientas de ingeniería (control de versiones, CI/CD, observabilidad) y de gestión de la infraestructura (management plane).
E-commerce: productos enfocados al cliente que generan ingresos.
Tier: Separa las cargas de trabajo según su criticidad y el tipo de datos que manejan. He preferido “tier” (nivel) en lugar de “entorno” para no pisar la terminología que usan los desarrolladores:
dev,testoqa. Un Tier impone políticas de datos y de acceso. Por ejemplo:Sandbox (Non-Production): donde hay más libertad y se usan datos sintéticos. Las políticas son más relajadas.
Live (Production): donde hay más restricciones y se usan datos reales.
Region: Organiza físicamente dónde están los recursos (p. ej.,
europe,usoapac) para reducir la latencia o cumplir con leyes de residencia de datos.Tenant: Aísla la infraestructura por propietario (el equipo de desarrollo o el cliente).
Espectro de aislamiento
No todas las vallas son de la misma altura ni están hechas del mismo material. Según lo que compartas con tus “vecinos”, el nivel de protección varía considerablemente. Es lo que llamamos el espectro de aislamiento:
Aislamiento lógico: como los namespaces de Kubernetes o las funciones de Lambda. Es el más ligero y barato, pero en general compartes el kernel del sistema operativo, el hardware y la red. Un vecino ruidoso puede afectarte con facilidad.
Aislamiento de runtime: máquinas virtuales independientes. Aquí un hipervisor separa las cargas, pero sigues compartiendo la red y el hardware físico con otros.
Aislamiento de red: VPCs o VNets separados. Las cargas no pueden comunicarse directamente entre sí, aunque vivan en la misma cuenta administrativa.
Aislamiento administrativo: cuentas de AWS o suscripciones de Azure independientes. Es el estándar de oro para la segmentación de plataformas. Aquí aislas la identidad y el acceso, la facturación y los límites de las APIs de la nube.
Aislamiento de hardware: servidores dedicados (bare metal) o sistemas totalmente desconectados de la red (air-gapped) para casos de extrema seguridad o regulación.
La regla general que siempre recomiendo es utilizar el límite administrativo como mínimo para separar los sectores y los tiers. No intentes ahorrar costes mezclando producción y desarrollo, ni servicios internos con externos en la misma suscripción mediante etiquetas. El riesgo de un error humano en una política de IAM es muy alto.
¿Cómo funciona en la práctica?
Vamos a diseñar una plataforma imaginaria que aplique estos conceptos.
Primero, empezamos definiendo dos grandes sectores (podrían haber más como security, it u otras líneas de negocio de la empresa):
core( oplatform): es el sector interno. Aquí viven las herramientas de gestión compartidas, tus repositorios de código, tus runners de CI/CD, tu stack de observabilidad y las herramientas de seguridad.ecommerce: es un sector de negocio. Aquí viven las aplicaciones de tus equipos de producto, las que atienden el tráfico de clientes y generan ingresos.
Luego, establecemos dos tiers o niveles de criticidad:
sandbox: es la zona de juegos. Políticas relajadas, datos sintéticos o anonimizados, acceso amplio para que los desarrolladores puedan romper cosas e innovar sin miedo.live: es producción. Datos reales de clientes, control de acceso humano estrictamente auditado y despliegues automatizados obligatorios.
Al combinar sector y tier, creamos nuestros segmentos de alto nivel. Por ejemplo, el segmento core-live es tu entorno de producción de servicios de ingeniería, mientras que ecommerce-sandbox es donde los equipos de producto prueban sus nuevas versiones antes de pasarlas a producción.
Dentro del segmento ecommerce-live, las cosas siguen siendo demasiado grandes. Aquí entran en juego las dimensiones de la región y del tenant.
Si nuestra empresa opera a nivel global, dividimos ese segmento en regiones geográficas (p. ej., europe y us). Y finalmente, dentro de la región, dividimos por tenant, es decir, por equipo. El equipo de payments tendrá su parcela en cada región y el de recommendations, las suyas. El equipo de payments no podrá acceder por defecto a la base de datos de recommendations.
El modelo de segmentación determina qué aislamos, pero la nube define cómo lo implementamos en la práctica mediante primitivas nativas.
La regla de oro (y el estándar de la industria) es utilizar fronteras administrativas en los niveles más altos. Esto significa que tu combinación $sector-$tier determinará si se creará una cuenta de AWS o una suscripción de Azure. Tendrás una suscripción de Azure para ecommerce-live, otra para ecommerce-sandbox, otra para core-live, etc.
Así garantizamos que una credencial comprometida en ecommerce-sandbox de la empresa no pueda interactuar de ninguna manera con las APIs que gestionan la infraestructura en producción.
A medida que bajamos hacia las subdivisiones más granulares, como región y tenant, solemos usar límites lógicos y de red. Por ejemplo, dentro de la suscripción ecommerce-live, puedes aislar los recursos del tenant payments en la región europe con un resource group (en Azure) payments-europe. O definir redes virtuales por región ecommerce-live-europe. Aquí ya depende un poco de la naturaleza de cada organización.
¡Muchas gracias por leerme!