La gente que sigue este blog (que no suelo actualizar mucho y que a partir de ahora intentaré hacer) habrá notado como cada vez se ha vuelto más simple y rápido. Este cambio proviene de querer olvidarme por completo de Wordpress y todo el ecosistema que tiene a su alrededor para pasar a algo más sencillo, ligero y rápido, que permita centrarme en el contenido y olvidarme del continente lo máximo posible.

A una conclusión llegué, si quería que el blog fuera rápido (independientemente del número de visitas) debería usar un sistema de generación de contenido estático. (Podría haber usado un sistema dinámico + una capa de caché como Varnish, pero mi objetivo era que el blog fuera muy simple).

Jekyll

Como primera opción elegí Jekyll, una herramienta escrita en Ruby de generación de contenido estática con la que obtuve unos resultados muy buenos.

Su uso es muy sencillo: en un directorio denominado posts se crean ficheros cuyo contenido es HTML o Markdown y cuando se ejecuta Jekyll estos ficheros se procesan, generando como resultado una serie de ficheros HTML estáticos que son los que hay que publicar en un servidor web. Más fácil imposible.

Sin embargo Jekyll no me terminó de convencer debido a que la estructura de esta aplicación no facilita la gestión de diferentes temas visuales y el motor de plantillas Liquid no es precisamente de mis favoritos (no tengo nada contra él).

Si quieres probar Jekyll te recomiendo que empieces por Jekyll-Bootstrap ya que no tendrás que pelearte con ciertos aspectos estáticos que son un poco incómodos inicialmente.

Ruhoh

Después de llevar un tiempo usando Jeyll investigué un poco más y encontré Ruhoh, una herramienta creada por el mismo autor que el paquete Jekyll-Bootstrap.

Ruhoh viene a ser una alternativa a Jekyll que intenta solucionar algunos problemas y aportar nuevas características. Tal y como hace Jekyll, Ruhoh usa Markdown a la hora de escribir los artículos. Sin embargo como sistema de templates en vez de Liquid usa Mustache que es bastante más conocido y soportado, siendo usado en frameworks como Backbone.js.

Su línea de comandos me parece mucho más sencilla que la de Jekyll y con un simple ruhoh compile ya está disponible en el directorio compiled una versión completamente estática del blog para poder ser publicado inmediatamente.

Publicando el blog

La primera opción a la hora de publicar tu blog estático es usar Github Pages, la segunda sería la de usar tu propio alojamiento compartido o dedicado, y la tercera opción que es la que he elegido yo es usar un servicio como Amazon S3 + Amazon CloudFront.

GitHub Pages

Esta es la opción más rápida y sencilla. Este servicio de GitHub te permite subir tus ficheros y que sean ellos los que los sirvan desde sus servidores. Es posible usar un subdominio gratuito del estilo http://usuario.github.com o usar directamente tu propio dominio sin ningún tipo de cargo adicional. Este fue el sistema que usé durante unos meses para alojar mi blog, pero no terminó de convencerme ya que estas páginas están alojadas en Estados Unidos, y por tanto la latencia es bastante alta desde España (entre 150ms y 200ms). Si estás decidido a usar GitHub Pages para alojar tu blog y tienes dudas puedes encontrar toda la información necesaria aquí: https://help.github.com/categories/20/articles.

Tu propio servidor

Con el fin de reducir la latencia puedes usar tu propio servidor, simplemente subir los ficheros generados mediante FTP o SCP y listo.

Amazon S3 y CloudFront

Esta opción es la que elegí finalmente para alojar mi blog por todas las ventajas que conlleva y el bajo coste asociado.

Amazon S3 es un servicio de Amazon que nos permite almacenar ficheros en ese sitio que está tan de moda últimamente, es decir, en la nube. Proporciona una API sencilla y una heramienta web para poder cargar y descargar cualquier tipo de fichero. Cada uno de estos ficheros está posteriormente accesible desde una URL. Gracias a esto nos libramos de preocupaciones sobre disponibilidad, ya que en caso de que nuestro blog tuviera cientos de miles de visitas ellos se encargarían de replicar ese fichero de manera transparente al número de servidores que fuera necesario para garantizar su disponibilidad.

Cuando creamos un espacio de alojamiento en S3 (denominado bucket) elegimos en qué zona del mundo de las disponibles va a estar alojado ese fichero (en el caso de mi blog yo elegí el datacenter que Amazon tiene en Irlanda). Sin embargo si únicamente usamos S3 volvemos a tener el problema de la latencia que expliqué anteriormente pero de manera inversa, es decir, si alguien de otra parte del mundo (como por ejemplo América del sur) visita mi blog tendrá una latencia considerablemente alta y la navegación por la web puede que no sea todo lo rápida que quisiéramos. La solución pasa por usar Amazon CloudFront, ya que de esta manera cuando alguien visite el blog los ficheros se les servirán desde el datacenter que más cercano tenga, minimizando así la latencia asociada a la visita.

Resumen

Este blog no tiene un gran tráfico, así que muchas personas que lean este artículo pensarán que es ridículo usar una solución de tan grandes prestaciones para una página tan poco importante. Es posible que así sea, sin embargo mi objetivo era también usar S3 y CloudFront para familiarizarme con estos servicios de Amazon y tener más experiencia con ellos para el futuro cuando tenga que aplicarlos a una situación real donde el tráfico sea muy alto.



blog comments powered by Disqus

Published

2012-11-11

Categories


Tags