Desde hace unos años a esta parte, surgía en nuestro equipo de trabajo, el deseo de reconstruir el sitio web de la empresa.

El sitio que estaba vigente había sido construido en el año 2014.

Lenguajes como PHP formaban pareja perfecta con bases de datos MySql para facilitar la construcción de vistosos portales donde exponer las características principales de la empresa, sus productos y sus actividades.

El ecosistema ya estaba en su madurez, bajo la denominación de Content Management Systems (CMS)

Los sistemas administradores de contenido surgieron para atender la necesidad que las personas de los departamentos que generaban y requerían publicar información, no contaban con el conocimiento técnico necesario para realizarlo de forma autónoma, por lo que requerían del apoyo del área de tecnología para publicar su contenido.

La arquitectura de dichos sistemas estaba formada por:

  • Base de datos donde se almacena la configuración y contenido del sitio. Normalmente se usaba el motor de base de datos MySQL.
  • Servidor de aplicaciones, ejecutando código en PHP para la construcción de las páginas. Desde este servidor, se establecían conexiones a la base de datos para recuperar el contenido a mostrar. El servidor más usado es Apache HTTP Server.

Arquitectura Tradicional

tradicional

Algunos ejemplos de CMS populares son:

Nuestro sitio

Se trataba de una instalación de Wordpress, conectado a una base de datos Mysql.

La publicación se realizó adquiriendo los servicios de una empresa de Hosting que proveía las características técnicas que requerían las tecnologías utilizadas.

Algunas de las razones por las cuales sentíamos la necesidad de un cambio:

  • Queríamos una nueva presentación de su diseño gráfico.
  • No teníamos un proceso de respaldo del sitio.
  • No estábamos conformes con la velocidad de presentación del sitio.
  • Requería esfuerzo para actualizar versiones de sus herramientas.

Tenemos que hablar …

Llegó el momento en el que pusimos el tema sobre la mesa y conversamos alternativas.

Básicamente teníamos dos caminos:

  1. Mejorar lo existente
    1. Definir estrategias de respaldo. Archivos de configuración y base de datos donde se define el contenido.
    2. Instalar un nuevo diseño gráfico compatible con Wordpress. Tarea relativamente sencilla por el universo de soluciones y maquetas definidas para Wordpress.
    3. Migrar hacia un nuevo servicio de hosting que posea una mejor infraestructura y nos garantice más velocidad.
  2. Utilizar una nueva arquitectura

El uso que le damos a nuestro sitio web tiene algunas características que influyeron en la decisión por la nueva arquitectura:

  • Las secciones más dinámicas son las de Experiencia y los artículos (blog) de nuestro equipo. Pero ninguna de las dos tiene una alta frecuencia de actualización. Estas modificaciones se dan en plazos de meses.
  • Todos los usuarios para administración del sitio son técnicos.

Nueva Arquitectura

Elegimos aplicar los principios de Jamstack.

Jamstack es un acrónimo, que refiere a Javascript, API & Markup stack. En esta arquitectura, tenemos contenido (markup) que incorpora Javascript, previamente compilado en bienes (assets), que son entregados al cliente desde una CDN (Red de distribución de Contenidos), y utilizan recursos externos a través de API para sus funcionalidades.

El markup es el HTML del sitio. Los tipos más simples de Jamstack son HTML plano con estilos en CSS, mientras que usualmente se les agrega Javascript para hacerlos más dinámicos y atractivos.

Arquitectura Jamstack

tradicional

Proceso de Construcción

El proceso normal de construcción es el siguiente:

  1. Desarrollo del sitio.
  2. Control de versiones. Se utilizan para almacenar el contenido y sus cambios (GIT).
  3. Construcción automática. El proceso de construcción del sitio y sus recursos es automático al detectar una nueva versión del contenido.
  4. Recursos estáticos. Resultado de los pasos anteriores, básicamente HTML + CSS + Javascript.
  5. Publicación atómica. Cada publicación, es una captura completa del sitio. Ayuda a garantizar su consistencia.
  6. Invalidar Cache. El CDN debe invalidar el cache para notificar que hay una nueva versión del sitio.
  7. CDN actualizado. La nueva versión se publica y queda disponible para su acceso.

Beneficios

  • Mejor rendimiento. El sitio es compilado en recursos estáticos que son servidos a través de la CDN.
  • Más seguro. No hay que preocuparse por vulnerabilidades del servidor de aplicaciones o base de datos.
  • Más económico. El hosting de archivos estáticos es más económico.
  • Escalabilidad. Como su almacenamiento es en CDN, puede adecuarse cualquiera sea la demanda de tránsito por parte de los usuarios.
  • Trazabilidad. Al usar control de versiones, tenemos disponible todos sus beneficios, partiendo por los respaldos y su perfecta trazabilidad.

Generadores de Sitios Estáticos

Un generador de sitios estáticos (SSG, por Static Site Generators) es una aplicación que toma el contenido del sitio, lo aplica a ciertos templates, y genera una estructura HTML totalmente estática, lista para disponer a los usuarios.

Estos generadores pueden estar escritos en una variedad de lenguajes, Ruby, Go, Javascript, etc.

proceso

Algunos de los más populares son:

Estos generadores, cumplen con la arquitectura Jamstack presentada.

Elección de Hugo

Al momento de analizar las distintas ofertas de generadores, valoramos las propiedades de Hugo que nos impulsaron a elegirlo:

  • Fácil instalación. Se trata de un ejecutable que realiza todo el trabajo. No queríamos procesos complejos de instalación o lenguajes adicionales (como por ejemplo Ruby).
  • Generación de Contenido. Se escribe en Markdown lo que lo hace muy fácil de redactar, así como independiente de su presentación.
  • Rapidez de generación. Se presenta como el generador más rápido. De nuestra parte agradecemos sea veloz, que sea el más veloz no nos genera valor agregado.
  • Excelente Documentación. Proceso de publicación y personalización muy bien explicado.
  • Comunidad. Se encuentran gran variedad de artículos sobre Hugo, frecuente actualización de versiones, y participación activa de su comunidad.

De todas formas, es importante notar que:

Lo más importante es la elección de la arquitectura. El motor usado no afecta todas las propiedades y ventajas mencionadas.

Nuestro Stack

Nuestro stack de implementación de la arquitectura quedó formado por las siguientes herramientas y servicios:

  1. Desarrollo del sitio utilizando la herramienta de edición Visual Studio Code
  2. Optimización de todas las imágenes con la herramienta en línea Squoosh
  3. GitLab para control de código fuente.
  4. Hugo como generador estático del sitio.
  5. Como proveedor de CDN usamos Azure, y sus herramientas de compilación y publicación asociadas:
    1. Pipeline de Compilación, usando la extensión de Azure para Hugo.
    2. Pipeline de Publicación, para publicar en el almacenamiento final.

Conclusiones

Quedamos muy satisfechos con el resultado. Como habrán visto, el nuevo sitio se siente sumamente rápido.

El esfuerzo fue mucho menor al que estimamos en un principio. Luego de una semana de migración y ajustes, tuvimos el sitio completamente funcional.