Voy a decir algo que le va a arder a más de un arquitecto de software: Tu aplicación no necesita Kubernetes.

No hoy. No con 100 usuarios. Probablemente no con 10.000. Y tal vez nunca.

Existe una epidemia silenciosa en la industria del software. Equipos que pasan meses diseñando arquitecturas distribuidas de clase mundial, con message brokers, service meshes, orquestadores de contenedores y pipelines de datos en tiempo real. Todo esto para un producto que todavía no ha validado si alguien está dispuesto a pagar por él.

La escalabilidad prematura no es un error técnico. Es un error de negocio disfrazado de buena práctica.

La Epidemia de la Infraestructura Fantasma

He visto esta película tantas veces que ya me sé los diálogos de memoria.

Un equipo nuevo arranca un proyecto. El Tech Lead se emociona, arma un diagrama en Excalidraw con quince cajas conectadas por flechas, propone Kafka para los eventos, un par de lambdas para las integraciones, Redis para el caché, Kubernetes para el deploy y múltiples bases de datos porque “necesitamos flexibilidad”.

Le preguntas cuántos usuarios esperan el primer mes.

Ni idea.

Y lo peor no es la plata de las instancias cloud. Lo peor es el costo invisible: el tiempo que tu equipo gasta configurando, manteniendo y debuggeando una infraestructura que no necesita existir. Tiempo que podría estar puesto en lo único que importa en esa etapa: construir algo que alguien quiera usar.

Por Qué Nos Pasa Esto

La respuesta fácil es el ego técnico. Y sí, hay algo de eso. Pero el problema es más profundo.

El Hype de las Conferencias

Cada año alguien de una FAANG sube al escenario de una conferencia y cuenta cómo resolvieron un problema a escala planetaria con una arquitectura increíble. Y miles de devs vuelven a sus oficinas pensando “nosotros también deberíamos hacer eso”.

Frena. Vuelve dos pueblos más atrás.

Netflix resolvió un problema de Netflix. Spotify resolvió un problema de Spotify. Esas soluciones nacieron de necesidades reales con millones de usuarios concurrentes, no de un whiteboard el primer día del proyecto.

Copiar la solución sin tener el problema es como tomar la medicina de otro paciente. En el mejor caso no hace nada. En el peor, te mata.

La Falsa Seguridad del “Futuro”

“Pero es que si después necesitamos escalar, va a ser más caro migrar.”

Esta es la justificación favorita. Y es engañosa, porque suena responsable. Parece que estás protegiendo el futuro de la empresa.

La realidad es distinta. En la fase de descubrimiento, el producto va a cambiar tanto que la mitad de lo que construiste hoy probablemente no exista en seis meses. ¿De qué te sirve haber diseñado una arquitectura “escalable” para un módulo que terminaste borrando?

El Costo Real que Nadie Calcula

Cuando un equipo elige una arquitectura distribuida prematura, lo que realmente está comprando es:

• Complejidad operacional: Cada servicio nuevo es un nuevo punto de falla, un nuevo pipeline de CI/CD, un nuevo set de logs que monitorear. Con tres devs. ¿Quién va a estar de turno a las 3 AM cuando el pod de pagos no levante?
• Fricción de desarrollo: Lo que en un monolito es un import y una llamada a función, en microservicios es un contrato de API, serialización, networking, manejo de errores distribuidos y eventual consistency. Para 100 usuarios.
• Tiempo de onboarding: Llega un dev nuevo y necesita dos semanas solo para entender cómo levantar el ambiente local con Docker Compose, 8 servicios y 4 bases de datos distintas.
• Muerte del Time-to-Market: Mientras tu equipo pelea con la infraestructura, tu competencia ya lanzó con un monolito en Rails, validó el mercado y está cerrando su ronda de inversión.

Exceso de talento puesto en el lugar equivocado.

El Monolito no es una Mala Palabra

Hay una idea tóxica instalada en la industria: que los monolitos son para giles principiantes y que los “ingenieros de verdad” hacen microservicios.

Mentira.

Shopify corre sobre un monolito en Ruby on Rails. Basecamp también. Stack Overflow manejó millones de usuarios con un monolito en C# y un equipo ridículamente pequeño.

Un monolito bien estructurado te da:

• Velocidad de desarrollo: Un solo repo, un solo deploy, un solo debug. Tu equipo avanza el doble.
• Simplicidad operacional: Un servidor, un proceso, un log. Cuando algo falla, sabes exactamente dónde mirar.
• Refactoring sin dolor: Mover código entre módulos es un cambio de carpeta, no una migración de servicio con downtime.

La clave está en el “bien estructurado”. Un monolito no significa spaghetti code. Significa que tu código vive en un solo lugar, con límites claros entre dominios, listo para ser separado el día que realmente lo necesites.

Cuándo Sí Escalar (Las Señales Reales)

No estoy diciendo que nunca escales. Estoy diciendo que escales cuando los datos te lo pidan, no cuando tu ego te lo sugiera.

Las señales reales son concretas y medibles:

• Latencia degrada consistentemente bajo carga normal (no un pico puntual, una tendencia).
• Un módulo específico consume el 80% de los recursos y está ahogando al resto del sistema.
• El equipo creció lo suficiente como para que trabajar todos en el mismo repo genere conflictos reales de merge y coordinación.
• Los deploys son tan grandes que cada release se vuelve un evento de alto riesgo.

Cuando estas señales aparecen, extraes quirúrgicamente el componente que duele. No haces un big bang de microservicios. Sacas el módulo caliente, lo pones detrás de una API interna, y sigues adelante. Cirugía con bisturí, no con motosierra.

La Decisión que Protege la Caja

Al final del día, esto no es solo una decisión técnica. Es una decisión de negocio.

Cada hora que tu equipo gasta en infraestructura innecesaria es una hora que no está puesta en producto. Y en etapas tempranas, el producto es lo único que te mantiene vivo.

El Director de tecnología que vale su peso no es el que arma la arquitectura más elegante. Es el que protege el Time-to-Market de la empresa con decisiones pragmáticas, aunque sean aburridas, aunque no queden bien en una conferencia, aunque el diagrama tenga una sola caja en vez de quince.

La próxima vez que alguien en tu equipo proponga Kubernetes para un MVP, hazle una sola pregunta: “¿Cuántos usuarios tenemos hoy?”

Si la respuesta cabe en un post-it, tu arquitectura también debería.

La complejidad técnica se gana con tracción. No se asume con fe.