Hace tiempo, revisando una publicación sobre cloud computing de la Fundación de la Innovación Bankinter, encontré un buen ejemplo que ilustra lo que puedes lograr desacoplando el repositorio de la capa de explotación:

«The New York Times decidió poner a disposición del público todos los artículos publicados entre 1851 y 1922, por medio de imágenes escaneadas de los documentos originales.

Inicialmente, las imágenes se componían dinámicamente en un PDF tras una solicitud del usuario, pero con el aumento del tráfico en su sitio web, la composición dinámica de PDF dejó de ser una forma adecuada de ofrecer la información.

Por este motivo, el periódico hizo uso del cloud computing a través de los servicios de Amazon, almacenando 4 terabytes de imágenes en Amazon S3 y procesando estas imágenes mediante un programa desarrollado por el propio periódico en la plataforma Amazon EC2.

Utilizando cien instancias del servicio Amazon EC2, el periódico generó los archivos PDF con todos los artículos en veinticuatro horas. Estos archivos se almacenaron a su vez en Amazon S3 y ahora se encuentran disponibles al público a través de su sitio web.»

(Comentario original en el blog del NYT sobre el servicio TimesMachine)

En nuestra opinión hay que buscar siempre el balance correcto entre la parte dinámica y estática del portal web.

Así, de la misma manera que dejamos que los vídeos o imágenes se descarguen desde redes de entrega de contenidos (CDN) o desde servidores especializados, podemos dejar los contenidos estáticos en nuestra granja de servidores web y «mover» parte del «dinamismo» hacía la generación de la paginación y de la navegación pregenerando, por ejemplo, las páginas de un boletín de noticias.

Las preguntas que siempre nos hacemos al abordar un proyecto son:

1. ¿Qué frecuencia de actualización tiene este contenido?
2. ¿Qué grado de interacción con el usuario es necesaria?

Y si la respuesta es que se actualiza UNA vez cada pocos minutos y que la interacción se logra a través de otros elementos (nubes de tags, noticias relacionadas, etc.), ese tipo de contenido concreto es un candidato perfecto a ser publicado en formato estático, enmarcándolo en una página dinámica o pregenerando las combinaciones de navegación posibles (atención a la complejidad del problema, aunque siempre nos alegramos de haber escogido este camino).

Las ventajas de esta aproximación son varias:

1. Mayor seguridad de los contenidos: al reducir los puntos de ruptura existentes al no ser necesarias las peticiones a BBDD.
2. Mayor escalabilidad del portal: en algunos clientes hemos conseguido reducir en un 50% el número de servidores necesarios.
3. Equipos de trabajo reducidos y con menor especialización: hemos realizado portales comparables con un orden de magnitud inferior de esfuerzo (medido en Man-Months).
4. Mayor reutililización de los contenidos: al estar mejor «encapsulados» es mucho más natural reutilizarlos que cuando se sirven a través de elementos dinámicos. Esta ventaja es potenciada por diversas funcionalidades de Ximdex (enlaces simbólicos entre documentos, includes XML mediante ximlets, documentos XML for Active Publishing -XAP- definidos por Ximdex, etc.)

La desventaja es que el tiempo de cálculo de la página, en lugar de realizarlo cuando recibes la visita, lo anticipas al momento de publicar el contenido. Aunque, realmente, sólo se calcula una vez para los millones de visitas que pueden visualizarlo en lugar de generarlo una y otra vez o buscarlo en un caché intermedia. Como vemos en la aproximación seguida por NYT evitando sobrecargar los servidores para mostrar la misma información y si observamos con atención es la aproximación seguida ad-hoc por casi todos los portales mass-media con cierto volumen de tráfico.

Nota: La publicación desacoplada originaria de Ximdex es tendencia desde 2016 en forma de los denominados Headless CMS.