A veces, mejorar la disponibilidad no requiere añadir otra capa de infraestructura. Requiere preguntar por qué la página dependía de tantas capas desde el principio.

TL;DR

En una migración reciente revisé sitios estáticos que se habían publicado en el mismo clúster —un conjunto de servidores que opera de forma coordinada— ya utilizado para servicios más complejos. Nadie había construido un clúster para servir una página institucional: se había aprovechado una infraestructura que ya existía. El coste de esa comodidad se hizo visible cuando una indisponibilidad originada en uno de los servidores afectó al conjunto y derribó páginas sencillas que podrían haberse distribuido mediante alojamiento estático, como el plan gratuito de Cloudflare Pages. En uno de los casos, la renderización en el servidor (server-side rendering, o SSR) —en la que el servidor prepara el HTML de la página durante la visita— se heredó de la arquitectura predeterminada del recurso de creación de sitios de Codex en la versión 0.1.46 instalada y en las tres ejecuciones que observé, aunque la interfaz no necesitaba generar contenido nuevo en cada acceso. Los clústeres y el SSR son capacidades útiles, no certificados automáticos de madurez. Si el resultado puede producirse antes de la solicitud y distribuirse como HTML para estructurar el contenido, CSS para presentarlo y JavaScript para añadir comportamiento, retirar el servidor de aplicaciones de la ruta crítica —el conjunto de componentes que debe funcionar para responder a cada visita— puede reducir puntos de fallo, trabajo operativo y acoplamiento —la fuerza con que los componentes dependen unos de otros—. Esto no convierte toda aplicación en candidata a alojamiento estático ni elimina dependencias externas. La decisión madura consiste en descubrir qué debe ocurrir realmente durante cada solicitud y mantener en el camino solo lo que aporta valor en ese momento.

El contexto importa. El clúster no se había creado para alojar una landing page. Ya existía, sostenía servicios con necesidades operativas más complejas y ofrecía un camino conocido para publicación, enrutamiento y monitorización. Aprovecharlo también para el sitio era una decisión pragmática en aquel momento, no un ejercicio de construir infraestructura por deporte.

La indisponibilidad hizo visible el acoplamiento. Un problema iniciado en uno de los servidores no afectó solo a las cargas que realmente necesitaban el clúster: también dejó fuera de línea una interfaz de presentación que podría haber seguido disponible de forma independiente.

Durante esa migración tuve que responder entonces una pregunta sencilla sobre una arquitectura que había crecido por comodidad:

Si este sitio entrega archivos que ya estaban terminados antes de que alguien entrara, ¿por qué necesita sobrevivir a mi clúster?

El sitio no procesaba una compra. No montaba una página diferente para cada visitante. No consultaba una base de datos para decidir qué título mostrar. No contenía una regla empresarial secreta que tuviera que permanecer en el servidor.

Era, esencialmente, una interfaz de presentación.

Aun así, para seguir en línea dependía de una red privada sana, de un conjunto de máquinas coordinadas como una unidad —el clúster—, de servicios en ejecución, de enrutamiento, de versiones correctamente publicadas y de una cantidad razonable de piezas operativas que aceptaran no tener un mal día al mismo tiempo.

En su origen, había pragmatismo.

En la práctica, una página sencilla había heredado el dominio de fallo de toda la infraestructura: si una parte importante de la cadena se detenía, el visitante dejaba de recibir un archivo que ya podría haber estado listo.

Yo no había comprado una bazuca para matar una mosca. La bazuca ya estaba allí, funcionando, y pareció práctico aprovecharla.

El problema fue hacer que la mosca dependiera del calendario de mantenimiento de la bazuca.

Un sitio estático no es un sitio sin ingeniería

Para algunas personas, la palabra «estático» todavía suena a antiguo, limitado o amateur.

No lo es.

Un sitio estático es aquel cuyo contenido entregable puede construirse antes de la visita. El navegador solicita un archivo y recibe ese archivo sin depender de un servidor de aplicaciones para volver a producir la página en ese instante. MDN explica esta diferencia entre servir archivos tal como están y ejecutar software para montar contenido dinámico antes de responder.

Eso no significa que el proyecto haya sido escrito a mano en un index.html de 1998.

Puede incluir componentes en React —piezas reutilizables de la interfaz—, procesamiento de estilos, optimización de imágenes, internacionalización —la preparación del producto para distintos idiomas y convenciones locales—, pruebas, validación de enlaces y una etapa completa de construcción —el build—. La diferencia es cuándo ocurre ese trabajo.

En vez de repetir una parte cada vez que alguien abre la página, el sistema produce por anticipado un conjunto de HTML, CSS, JavaScript, fuentes e imágenes. Vite documenta que su build de producción genera, de forma predeterminada, un paquete apto para ser servido por un alojamiento estático.

Hay ingeniería antes de publicar.

Simplemente no existe la obligación de mantener un servidor de aplicaciones ejecutándose para entregar después el resultado.

El SSR es una capacidad, no una medalla

En aquel sitio, el origen del SSR era menos épico y más cotidiano: algún tiempo antes había decidido probar el recurso de Codex para crear sitios. Fui perezoso. En lugar de cuestionar cada decisión arquitectónica, acepté la estructura que entregó, y esta venía con renderización en el servidor (server-side rendering, o SSR).

Después abrí la versión 0.1.46 del paquete OpenAI Sites instalada en mi entorno —el conjunto local de reglas que orientaba este tipo de generación— y la explicación se volvió más precisa. No dice literalmente «usa SSR en todos los sitios». Sin embargo, en esa versión indica que los sitios nuevos deben partir del scaffold de OpenAI Sites —una estructura inicial de código—, producir una salida compatible con Cloudflare Workers y entregar a la plataforma de alojamiento incluso un artefacto de servidor, es decir, un paquete preparado para ejecutar código en el servidor. La propia integración de OpenAI administra los recursos reales en Cloudflare y el enlace de la publicación. Esta inspección es una evidencia local identificada, no una especificación pública ni una afirmación sobre todas las versiones pasadas o futuras del recurso.

Tampoco era una coincidencia aislada. Ejecuté tres sitios con la misma skill —un paquete reutilizable de instrucciones, recursos y procedimientos que orienta al agente— y los tres recibieron esta estrategia. En este caso, formaba parte del paquete OpenAI Sites citado arriba. La repetición observada coincide con la regla escrita: la solución nace preparada para un caso en el que quizá sea necesario ejecutar algo en el servidor. Para un creador de sitios de propósito general, es una precaución comprensible. Para una página sencilla, significa heredar una infraestructura de ejecución que quizá nunca llegue a utilizar de verdad.

En este modelo, los componentes de la aplicación se transforman en HTML dentro de un entorno de servidor. La propia documentación de React describe sus API de servidor como recursos utilizados en el nivel superior de la aplicación para generar el HTML inicial.

Es el equivalente digital de usar el cuchillo que tenemos delante para apretar un tornillo. Según el cuchillo y el tornillo, puede que incluso gire. El problema parece resuelto, pero eso no convierte el cuchillo en un destornillador ni hace que sea el método más adecuado.

El generador ofreció una solución capaz de hacer más y consiguió publicar el sitio. Fui yo quien no se detuvo a preguntar si ese «más» formaba parte del requisito. La herramienta disponible puede resolver el problema; comprobar si además es apropiada sigue siendo responsabilidad mía.

El SSR puede ser la elección correcta.

Puede ayudar cuando el contenido varía realmente con cada solicitud, cuando la respuesta depende de una sesión, cuando existe personalización que no debe enviarse al navegador, cuando hay requisitos específicos sobre el tiempo hasta el primer contenido o cuando la arquitectura necesita combinar datos dinámicos y HTML inicial.

Pero, en aquel caso, una función se ejecutaba para entregar una interfaz que podría haberse construido antes.

El servidor se despertaba, preparaba la bandeja y entregaba un plato que ya estaba listo.

Lo llamamos arquitectura moderna porque «alguien encendió una función para devolver archivos» no luce tan bien en una presentación.

El problema no es el SSR.

El problema es tratarlo como una evolución obligatoria. Una capacidad deja de demostrar madurez cuando está presente sin que exista el requisito correspondiente. En ese punto solo demuestra que somos capaces de operar una cosa más.

Y todo lo que podemos operar también es algo que podemos romper, actualizar, monitorizar, pagar e intentar entender a las dos de la mañana.

La ruta de lectura cargaba dependencias que pertenecían a la publicación

Esta distinción cambió mi forma de mirar el sistema.

Hay dependencias necesarias para producir una nueva versión del sitio: el repositorio, las herramientas de build, las pruebas, la validación, el servicio que recibe el artefacto —el conjunto de archivos generado— y el proceso de aprobación.

Y hay dependencias necesarias para leer la versión ya publicada.

Las dos listas no tienen que ser iguales.

Si el proceso de build deja de estar disponible, quizá no pueda publicar una versión nueva en ese momento. Es un problema real. Pero no debería impedir automáticamente que alguien lea los archivos de la versión que ya estaba publicada.

Cuando coloco el sitio en la misma ruta operativa de servicios dinámicos, bases de datos, redes internas y otras aplicaciones, acoplo la lectura a problemas que no guardan relación con ella.

Un servicio auxiliar falla y la página institucional cae con él.

Un mantenimiento del clúster retira la documentación del aire.

Un problema en el mecanismo usado para empaquetar y publicar servicios impide recuperar una interfaz que, después del build, era solo un conjunto de archivos.

No gané necesariamente resiliencia por tener más componentes.

Gané más componentes capaces de participar en la indisponibilidad.

La resiliencia también puede venir de la sustracción

En ingeniería existe una tendencia comprensible a responder al riesgo añadiendo cosas.

Otra réplica —una copia adicional de la aplicación lista para responder—. Otro servidor. Otro balanceador —el componente que distribuye solicitudes entre las copias disponibles—. Otro sistema de monitorización —el que observa señales y alerta cuando algo se aparta de lo esperado—. Otro mecanismo de recuperación. Otro panel para observar el panel que observa el servicio.

A veces, eso es exactamente lo que necesita el sistema.

En otras ocasiones, la pregunta más valiosa es:

¿Cuál de estas piezas puede dejar de participar en esta entrega?

El capítulo sobre simplicidad del libro de Ingeniería de Fiabilidad de Sitios de Google diferencia la complejidad esencial del problema de la que introdujimos por la manera en que decidimos resolverlo. También destaca el valor de retirar código y responsabilidades que ya no sirven al objetivo del sistema.

Esa fuente no demuestra que todo sitio estático será más disponible en una plataforma gestionada. Sustenta un principio más limitado: la simplicidad operativa y el bajo acoplamiento ayudan a que los sistemas sean más comprensibles, comprobables y confiables.

Mi síntesis a partir del caso es directa: si una dependencia no necesita participar en la lectura, retirarla de la ruta crítica puede ser una medida de resiliencia.

No es «menos ingeniería».

Es ingeniería aplicada para dejar de operar aquello que no necesitaba existir allí.

Salir del clúster no exige abandonar la gobernanza

Retirar una página estática de la infraestructura propia no significa lanzar una carpeta en cualquier lugar y cruzar los dedos.

Todavía necesito preservar:

• el origen versionado del contenido;
• un build reproducible;
• validaciones antes de publicar;
• versiones de evaluación protegidas;
• dominio correcto; conexión cifrada mediante el Protocolo seguro de transferencia de hipertexto (HTTPS); cabeceras de respuesta —metadatos que orientan caché, seguridad y comportamiento del navegador—; e indexación —condiciones para que los buscadores descubran e incluyan la página—;
• métricas bajo una política de privacidad;
• historial de publicación;
• una forma verificable de volver a la versión anterior;
• una copia portátil del resultado que pueda servirse en otro lugar.

Lo que cambia es la responsabilidad operativa.

En vez de mantener máquinas, procesos, una red interna y enrutamiento solo para entregar archivos, envío el artefacto a una superficie especializada en distribuirlos. Una red de distribución de contenidos (content delivery network, o CDN) mantiene copias cerca de distintas regiones y responde sin obligar a cada visitante a atravesar mi infraestructura privada para buscar cada archivo.

Eso cambia una dependencia por otra.

No elimina el riesgo ni convierte al proveedor en una institución divina incapaz de fallar. La nueva plataforma puede sufrir indisponibilidad, límites, cambios de precio, errores de configuración o bloqueos de cuenta. El dominio y el sistema que traduce nombres en direcciones de internet —el DNS— siguen importando. El proceso de publicación sigue necesitando seguridad. Una función demasiado propietaria puede recrear el acoplamiento que yo intentaba retirar.

Por eso importa la portabilidad del artefacto.

Si el resultado final es una carpeta normalizada de archivos, puedo probarla localmente, comparar su contenido y publicarla en otro destino con menos reconstrucción. Si cada página depende de una función específica del proveedor, solo cambié el nombre del clúster en el diagrama.

La parte dinámica puede seguir siendo dinámica sin secuestrar la página entera

Una interfaz estática puede enviar un formulario, consultar una interfaz mediante la cual se integran sistemas —una API—, cargar datos autenticados o iniciar una automatización.

Esas operaciones son dinámicas.

Necesitan validación, límites, control de abuso, protección de secretos, registros seguros y un comportamiento predecible cuando el servicio de destino no está disponible. En algunos casos basta una pequeña función ejecutada solo en esa ruta. En otros existe un sistema completo detrás.

La diferencia es que la página entera no necesita ser generada por ese sistema solo porque un botón conversa con él.

Puedo separar:

• la presentación pública, construida por anticipado y distribuida como archivos;
• las rutas dinámicas, ejecutadas solo cuando hay una acción real;
• los sistemas privados, fuera del alcance directo del navegador;
• el comportamiento de fallo, que informa del problema sin fingir que la acción se completó.

Esta separación no mantiene todo funcionando durante cualquier incidente. Si cae la API de suscripción, la suscripción puede dejar de estar disponible. Pero el sitio todavía puede explicar el servicio, mostrar un canal alternativo y aclarar qué no funcionó.

La disponibilidad no tiene que ser binaria. Una parte puede degradarse sin llevarse consigo todo lo que aún resulta útil.

Cómo decido si un sitio puede salir de este camino

No empiezo preguntando qué plataforma está de moda. Empiezo inventariando qué ocurre cuando alguien accede a cada ruta.

1. ¿El HTML cambia en cada solicitud? Si el contenido es el mismo para todos hasta la próxima publicación, es un candidato fuerte a ser construido por anticipado.
2. ¿Se procesan datos secretos o personales? Si es así, no pueden empujarse al navegador solo para llamar estática a la arquitectura.
3. ¿El contenido necesita el servidor o solo lo necesitan las acciones? Un formulario dinámico no obliga a todas las páginas a depender del mismo entorno de ejecución —el runtime.
4. ¿El resultado puede probarse como artefacto? Quiero abrir la carpeta generada y validar enlaces, idioma, metadatos, accesibilidad y comportamiento antes de enviarla.
5. ¿La publicación es reversible? Una nueva versión debe poder fallar sin destruir la anterior, y volver necesita ser algo más concreto que «la plataforma probablemente guarda algo».
6. ¿El destino crea dependencias propietarias innecesarias? Funciones, bases de datos y recursos específicos entran solo cuando resuelven un requisito real.
7. ¿Qué ocurre durante un fallo parcial? ¿La página sigue siendo legible? ¿La acción se deshabilita de manera honesta? ¿Existe un canal alternativo? ¿El error es observable sin exponer información sensible?
8. ¿Cuándo termina la migración? Después de las pruebas, del período de observación y de confirmar el camino de vuelta, la infraestructura anterior debe retirarse. De lo contrario, la «simplificación» termina manteniendo las dos arquitecturas para siempre.

Este último punto es menos encantador que el diagrama de migración.

También es donde finalmente aparecen el ahorro y la reducción real del riesgo.

Lo que este caso no permite concluir

No estoy proponiendo que toda aplicación se convierta en un conjunto de archivos estáticos.

Un sistema transaccional, un área autenticada con datos sensibles, una aplicación que monta respuestas específicas por solicitud o un producto que depende de lógica en el servidor siguen necesitando una capa dinámica. Según la latencia, la soberanía, la integración, el coste y el control, la infraestructura propia puede ser la mejor elección.

Tampoco afirmo que las aplicaciones de una sola página —las SPA, que actualizan la interfaz en el navegador sin cargar un documento nuevo en cada interacción— resuelvan automáticamente indexación, accesibilidad o rendimiento. Un sitio puede ser estático y seguir siendo malo. Para contenido público, generar HTML por anticipado puede ser mejor que entregar una página vacía que solo aparece después de ejecutar demasiado JavaScript.

El SSR tampoco es desperdicio por definición. Es desperdicio cuando pagamos su complejidad de ejecución sin atender una necesidad de la aplicación.

Por último, una plataforma gestionada no elimina la responsabilidad. Sigo siendo responsable de decidir qué publico, verificar el build, proteger las rutas dinámicas, limitar dependencias y mantener una salida.

La tesis no es «externaliza todo».

Es «no obligues a una página terminada a depender de que una fábrica entera siga funcionando».

La arquitectura madura no es la que tiene más cajas

Me gusta la infraestructura. Durante años atravesé toda la cadena entre requisitos, software, publicación, monitorización, seguridad, backup y continuidad.

Tal vez precisamente por eso tengo menos interés en mantener una pieza solo porque sé operarla.

El conocimiento técnico no debería aumentar la cantidad de tecnología que coloco en cada problema. Debería aumentar mi capacidad de distinguir qué es esencial, qué es contingencia y qué se convirtió en decoración arquitectónica.

Un clúster es una herramienta excelente cuando existe trabajo para un clúster.

El SSR es una herramienta excelente cuando hay algo que necesita renderizarse en el servidor.

Un sitio estático es una solución madura cuando el requisito consiste en distribuir, con seguridad y previsibilidad, algo que ya está terminado.

La resiliencia no es contar cuántas cajas aparecen en el diagrama.

Es saber cuántas pueden fallar sin derribar aquello que debería haber seguido disponible.

En i-9.ai, este es el tipo de pregunta que prefiero hacer antes de añadir otra capa: ¿qué capacidad necesita realmente el sistema y qué responsabilidad podemos retirar sin perder control?

Si tu empresa mantiene una arquitectura entera para entregar algo que ya podría estar terminado, ponte en contacto. La conversación puede comenzar por el recorrido real de cada solicitud, no por la herramienta que alguien decidió poner en el diagrama.

Seguir leyendo

• Evolución de la tecnología: del mainframe al infame juego de palabras en tiempo real: un recorrido por las abstracciones que aportaron flexibilidad y por las responsabilidades que continuaron existiendo.
• Tu empresa no necesita descubrir dónde colocar IA: un método para empezar por el problema y elegir solo la capacidad necesaria.
• Nací en 1986 y sobreviví al menos a nueve fines del mundo: por qué los cambios importantes piden método, backup y dirección, no pánico ni euforia.
• La mejor respuesta no es la que más me agrada: cómo transformar el criterio en infraestructura sin ocultar dependencias inevitables.

Para profundizar

• Página web estática: una visión enciclopédica de páginas entregadas sin generación dinámica por solicitud.
• Programación del lado del servidor: contexto sobre la generación de contenido en el servidor y su diferencia respecto de la ejecución en el navegador.
• Red de distribución de contenidos: una introducción a puntos distribuidos que entregan archivos más cerca del lector.
• Clúster de computadoras: una visión general de máquinas coordinadas para trabajar como un conjunto.

Referencias y límites de uso

Las fuentes siguientes sostienen mecanismos y principios técnicos específicos. No demuestran que una plataforma gestionada siempre será más disponible, barata o adecuada que la infraestructura propia. La decisión descrita es una síntesis autoral aplicada a casos en que el contenido podía construirse por anticipado.

• MDN — «¿Qué es un servidor web?»: diferencia servidores que entregan archivos estáticos de aquellos que ejecutan software para generar contenido dinámico; no prescribe una arquitectura para un producto específico.
• MDN — «El modelo de estándares web»: explica en lenguaje introductorio las funciones de estructura, presentación y comportamiento de HTML, CSS y JavaScript.
• MDN — «HTTPS»: define el protocolo utilizado para proteger la comunicación entre navegador y servidor; no demuestra que una implantación específica esté configurada correctamente.
• MDN — «Cabeceras HTTP» y Google Search Central — «Cómo funciona la Búsqueda»: explican los metadatos de respuesta y las etapas generales de descubrimiento e indexación; no auditan la publicación descrita en este artículo.
• Google SRE — «Cómo abordar fallos en cascada»: describe cómo las dependencias y la sobrecarga pueden propagar fallos; aplicar ese principio a la retirada del servidor de aplicaciones es la síntesis arquitectónica del artículo.
• React — «Inicio rápido»: presenta los componentes como piezas reutilizables de la interfaz; no determina qué arquitectura de publicación debe usar un proyecto.
• W3C — «¿Qué es la internacionalización?»: explica la preparación de productos para diferentes idiomas, culturas y convenciones; no evalúa la implementación específica citada en el artículo.
• Kubernetes — «Réplicas», Cloudflare — «Balanceo de carga» y Google SRE — «Monitorización de sistemas distribuidos»: presentan, respectivamente, copias de aplicaciones, distribución de tráfico y observación de señales operativas; no convierten estos componentes en necesarios para toda arquitectura.
• Vite — «Build para producción»: documenta que el build predeterminado produce un paquete adecuado para alojamiento estático; no garantiza la calidad, indexación, seguridad o portabilidad de toda aplicación construida con Vite.
• React — «API de servidor de React DOM»: documenta API que renderizan componentes React como HTML en el servidor; no afirma que el SSR sea obligatorio ni inadecuado para una clase entera de aplicaciones.
• Cloudflare Workers — «Visión general»: presenta el entorno de ejecución, sus capacidades y la entrega de activos estáticos. Esta página no documenta las reglas del paquete OpenAI Sites: ese pasaje se limita a la versión 0.1.46 instalada y a las tres ejecuciones observadas por el autor.
• Cloudflare Pages — «Límites»: identifica los límites actuales del plan gratuito citado en el artículo; la disponibilidad, las cuotas y las condiciones pueden cambiar y deben revisarse en una decisión futura.
• MDN, “DNS”: define el sistema de nombres de dominio y su función de asociar nombres con recursos como direcciones IP; este glosario solo sustenta la definición técnica, no una arquitectura de DNS ni la tesis amplia del artículo.
• MDN, “API”: define una API como una interfaz de reglas y recursos mediante la cual un software interactúa con otro; este glosario solo sustenta la definición técnica, no la disponibilidad de las integraciones citadas.
• MDN, “SPA”: define las aplicaciones de página única y registra ventajas y desventajas generales; este glosario solo sustenta la definición técnica, no demuestra que el HTML estático sea superior para todo producto.
• MDN — «Modelo de ejecución de JavaScript»: describe de forma abstracta la infraestructura básica de un entorno de ejecución de JavaScript y la cooperación entre motor y anfitrión; su alcance no prescribe cómo deben organizarse todos los runtimes o arquitecturas.
• Google — «Ingeniería de confiabilidad de sitios: simplicidad»: sostiene la relación operativa entre simplicidad, bajo acoplamiento, comprensión y confiabilidad; sus ejemplos provienen del contexto de Google y no constituyen una garantía universal de disponibilidad.