Dos clientes llegaron el mismo mes. El primero, un startup en etapa temprana que corre completamente sobre Lovable.dev y Supabase, quería escalar, asegurar la plataforma contra ataques y reducir costos. El segundo, una empresa consolidada que ya estaba en AWS, quería volver escalable y confiable un único servidor sobrecargado sin tumbar el servicio.
En la superficie son proyectos distintos — uno es “no tenemos infraestructura”, el otro es “nuestra infraestructura ya no da abasto”. Pero vistos juntos son los dos extremos opuestos de un mismo eje. Y el diagnóstico para ambos es idéntico: los planos de substrato y workload no están separados limpiamente.
Esa frase es todo el artículo. El resto es qué significa y por qué nombrarlo primero cambia la forma de resolverlo.
Los dos planos
Todo sistema en producción vive sobre dos planos:
- El plano de substrato es todo lo que tiene que existir antes de que tu código pueda correr: cómputo, red, almacenamiento, DNS, certificados, secretos, el motor de base de datos, el relay de correo, el balanceador de carga. Es el terreno.
- El plano de workload es tu aplicación en sí — el código que escribe tu equipo, los contenedores y servicios que entregan el producto real. Es lo que corre sobre el terreno.
La salud de un sistema no se mide por qué nube usa ni por lo moderno que se vea su stack. Se mide por qué tan limpiamente están separados esos dos planos — si puedes reconstruir el substrato sin tocar el workload, y redesplegar el workload sin reconstruir el substrato.
Cuando la separación es limpia, el substrato se vuelve reproducible (descrito como código, versionado, auditable) y el workload se vuelve portable (corre donde sea que el substrato esté aprovisionado). Cuando falta la separación, todo cambio es riesgoso, toda recuperación es manual, y “¿qué tenemos realmente corriendo?” se convierte en una pregunta que nadie puede responder con certeza.
Caso 1 · Un workload sin substrato propio
Este startup hizo todo bien para su etapa. Construyeron rápido sobre Lovable.dev para la aplicación y Supabase para el backend. Sin servidores que administrar, sin factura de infraestructura, capa gratuita de punta a punta. El producto funciona y tiene usuarios.
El desafío es estructural, no funcional. Tienen un workload, pero su substrato nunca fue suyo. Vive dentro de proveedores de plataforma opacos (PaaS). No hay red que segmentar, no hay instancia de base de datos que endurecer, no hay infraestructura que auditar, no hay configuración que mover — porque nada de eso existe como suyo. Cuando el requerimiento pasa a ser “asegura esto contra atacantes” o “reduce costos al escalar”, no hay nada sobre lo que poner las manos. No puedes endurecer un substrato que no posees.
Así que el trabajo aquí es materialización de substrato: un levantamiento del código y los datos que ya tienen, y luego fabricar un substrato desde cero como Infraestructura como Código — moverse de un proveedor de plataforma a un proveedor de infraestructura, donde la red, la base de datos, los secretos y las reglas de escalado se vuelven activos reales, propios y versionados. El workload casi no cambia. El terreno debajo de él se construye por primera vez.
Caso 2 · Un substrato sin separación
El segundo caso es la imagen opuesta. Esta empresa ya está en AWS, con dos repositorios de código — un frontend en Angular y un backend en PHP/SugarCRM. Pero todo corre sobre una única máquina virtual: Apache, Node.js, MySQL, Postfix y más, todo en un solo host. Es una “mascota” en el sentido clásico de infraestructura — un único servidor mantenido a mano que creció orgánicamente junto con el negocio, y que hoy es riesgoso de cambiar porque demasiado depende de él.
Aquí el substrato sí existe. Lo que le falta es separación: está separado de nada. El servidor web, el runtime de la aplicación, la base de datos y el relay de correo comparten un sistema operativo, un mismo set de credenciales, un mismo radio de impacto. Una actualización de la base de datos puede tumbar el correo. Un pico de tráfico en el frontend compite con SugarCRM por el mismo CPU. No hay eje de escalado, ni aislamiento de fallas, ni recuperación limpia — porque el substrato y el workload están fundidos en un solo objeto.
Así que el trabajo aquí es descomposición de substrato: un inventario de todo lo que esa máquina hace en realidad, una especificación escrita de Substrato + Workloads que nombre cada función como su propio plano, y un plan de mejoras por fases para separar esas funciones — volviendo el sistema escalable, seguro y confiable sin romper nada ni tumbar el servicio por periodos prolongados. La descomposición es incremental por necesidad; el servicio sigue vivo durante todo el proceso.
Un eje, dos enfermedades
Pon los dos casos lado a lado y el patrón es inconfundible:
- El primero no tiene substrato propio. El workload flota sobre plataformas que no controla.
- El segundo no tiene separación. El substrato existe pero está fundido al workload en una sola máquina.
No son problemas inconexos. Son los dos extremos patológicos del mismo eje — muy poca propiedad del substrato en un lado, cero separación de planos en el otro. Y el destino es idéntico para ambos: una arquitectura limpia de dos planos donde el substrato es propio y reproducible como código, y el workload corre sobre él, portable y aislado. Mismo norte, enfermedades opuestas.
Por eso importa nombrar el modelo primero. Una vez que ves a ambos clientes como puntos sobre el eje substrato/workload, el proyecto deja de ser “migrar a la nube” o “arreglar el servidor” y se vuelve una pregunta precisa: ¿cuál plano falta, y cuál separación hay que construir?
Por qué el diagnóstico va primero
En ambos casos el primer entregable no es un servidor. Es el levantamiento — una evaluación que mapea lo que existe hoy sobre los dos planos, y una arquitectura escrita de Substrato + Workloads que define el destino. Solo después viene el plan por fases: para el startup, fabricar el substrato como IaC; para la empresa consolidada, descomponer el monolito una función a la vez con cortes de bajo downtime.
Esa insistencia en una arquitectura escrita y auditable antes de cualquier cambio es nuestro principio de Caja de Vidrio en la práctica: tu infraestructura está descrita como código que te pertenece y que puedes leer. Sin plataforma opaca que no puedas inspeccionar, sin máquina irreemplazable que solo una persona entiende. El substrato se vuelve un activo, no un pasivo — reproducible, revisable y tuyo.
Si tu plataforma está en algún punto de este eje — demasiada opacidad de PaaS, o todo amontonado en una sola caja — el lugar para empezar es el diagnóstico, no la migración. Conversemos sobre un levantamiento de substrato y workload de tu stack.