Twitter permite insertar en nuestras webs diversos widgets que muestran tweets, timelines, perfiles, etc. De esta forma podemos interactuar directamente con Twitter desde la web que los esté usando. Para ello utiliza un fichero de creación propia llamado widgets.js que no es más que una librería Javascript para cargar y formatear el contenido de los diversos widgets en la web.
Este fichero está insertado en millones de páginas web, y es servido cerca de 300.000 veces por segundo. Twitter actualiza este fichero semanalmente para arreglar fallos y añadir nuevas características de forma totalmente transparente para los usuarios. Por tanto, un despliegue de esta librería es crítico para Twitter y necesita realizarse de la forma más segura posible. Twitter considera que un despliegue es seguro si es:
Como widgets.js es un fichero muy utilizado y con un nombre bastante conocido (su url es platform.twitter.com/widgets.js, no incluye ningún tipo de versión en su nombre lo que hace difícil controlar el progreso de su despliegue.
Twitter ha preferido mantener un fichero único sin versión para mayor comodidad de sus usuarios. Si el fichero utilizara un número de versión, el despliegue consistiría en obligar al usuario a cambiar la dirección de carga del script. Esto es lo que hacen la mayoría de librerías Javascript como jQuery o Bootstrap.
Al tener siempre la misma dirección de carga (y encima los navegadores utilizar su propia caché para mantener la copia local), ahora el problema consiste en invalidar el fichero antiguo en el propio DNS de Twitter y apuntar al nuevo.
Para ello Twitter ha tenido que crear una configuración propia para llevarlo a cabo.
Servicio de gestión DNS: este servicio permite a Twitter controlar como platform.twitter.com se resuelve a una dirección IP. Usando regiones geográficas para el despliegue por fases, utilizan las siguientes reglas:
CDN (Content Delivery Network): este servicio permite servir recursos estáticos de manera rápida a muchos puntos del mundo. Twitter tiene el suyo configurado de tal forma que si una petición se hace desde IP1, el fichero se sirve desde el origen 1; en caso contrario se sirve desde origen 2.
Origen: servicio de almacenamiento como Amazon S3 donde se sube el fichero widgets.js. El CDN le pide al origen la última versión del fichero cuando se sirve.
Por defecto todas las peticiones son servidas por el origen 1. El despliegue comienza al subir una nueva versión del fichero widgets.js al origen 2. Entonces Twitter empieza a mover el tráfico hacia el origen 2 usando las fases descritas anteriormente en el DNS. Si el despliegue es satisfactorio, se copian los archivos del origen 2 al origen 1 y se resetea todo el tráfico hacia el origen 1.
En resumen, Twitter lo que tiene son dos copias del fichero widgets.js: la que hay actualmente (que está en origen 1) y la nueva (que está en origen 2). Usando fases va "forzando" mediante DNS a sus usuarios a descargar la versión nueva en lugar de la vieja, y una vez que están seguros que todo ha ido bien, sobreescriben la antigua de origen 1 por la nueva de origen 2.
Esto nos da una visión bastante general de cómo algo tan simple como desplegar un único fichero a los clientes conlleva todo un proceso de ingeniería detrás debido a la enorme concurrencia y uso del software.