Hoy os presentamos como se encuentra funcionando actualmente el CDN que está misma web está utilizando, Alefnode CDN. Las configuraciones son complejas y la arquitectura no es lo más común en un CDN, sin embargo, mediante diversas pruebas hemos conseguido llegar a límites que hasta ahora no eran alcanzables con una estructura similar. Como podéis observar estamos trabajando con un servidor de DNS que realiza distinciones por país y envía la petición a nodos diferentes en función de la geolocalización del usuario, lo que nos permite no solo tener una menor latencia sino también un menor tiempo de carga.

En la actualidad en las arquitecturas cloud se está utilizando el SDS que significa Software Definied Storage, la idea principal de estos sistemas es tratar el almacenamiento como si fuese software independientemente del hardware físico que tengamos. Este tipo de sistemas facilita mucho a las empresas el cambio de hardware, por uno de mejores prestaciones, reduciendo el tiempo de migraciones a cero. Algunos ejemplos de SDS son; CEPH, Swift, pNFS, SDDC by VMWare,…

Desde hace algún tiempo me dedico a la automatización de cierto proyectos que tienen como fundamento la capacidad de funcionar de forma autónoma, es decir, pueden adaptarse a las necesidades que se soliciten en cada momento. Para poder realizar este tipo de tareas debemos conocer como orquestar toda nuestra plataforma. En primer lugar debemos saber exactamente de que hablamos cuando nos referimos a orquestar, para ello se define el verbo orquestar como organizar, dirigir o coordinar un plan.

Haproxy es un software opensource que nos permite tener nuestro propio balanceador de carga en casa. Lo bueno de esta aplicación es que nos permite disponer de alta disponibilidad en formato Activo-Activo de forma sencilla y al mismo tiempo disponer de un potente software diseñado exclusivamente a esta tarea. Una de las opciones que se puede utilizar es mantener nuestros certificados de diferentes webs todos centralizados con una mayor facilidad a la hora de gestionarlos, asi como, balancear las peticiones de cada web a un servidor diferente, evitando que la carga de una web afecte a otra web.

Cada día que pasa se premia más la velocidad de carga de una web, desde un principio Google puso mucho de su parte para tratar de crear el buscador más rápido y lo consiguió, una de las claves de su éxito fue la capacidad de ofrecer al usuario la web que esta buscando en milésimas de segundo, se dice que los creadores estaban obsesionados con este tema. Actualmente es relativamente sencillo crear una web, empresarial o personal para una pequeña empresa y que no vaya a requerir de gran carga, sin embargo a medida que las empresas crecen se encuentran en situaciones en las que tienen que elegir si pagar más por mejorar su infraestructura o contratar gente que mejore el código de la web, en el mejor de los casos la solución es implementar ambas.

Una de las tareas que nos permite realizar la integración continua es hacer o construir nuestra aplicación una vez que se haga un push a la rama deseada de nuestro servidor de Git. Para ello en nuestra arquitectura hemos usado Gitlab y Jenkins. Lo primero que debemos hacer es crear un usuario para Jenkins que tenga permisos de “reporter” en nuestro proyecto (Los permisos se asignan en el apartado Project->Settings->Members)