Recuerdo, hace ya varios años, en una empresa pequeña en la cual trabajé un día mi jefe me encargó una tarea que me hizo coger gusto e interés en el mundo de operaciones o lo que suelen llamar DevOps.
Se me acerca un día miércoles o jueves y me dice:
Frank, el servidor dedicado nos cuesta X cantidad de dólares. Si el sábado logras migrar todos los sitios web que están ahí hospedados a servidores en Linode, te doy esa X cantidad a ti. Sino, toca pagar y en todo caso debes hacer la migración.
Ya venía trabajando algún tiempo con configuraciones en Linode por lo cual no había tanto desconocido pero la tarea pedía completarse en tiempo casi récord. Bueno, al final de la historia lo logré pero el resultado fue 20, aprox, servidores(más direcciones IP, más DNS, etc) que debía gestionar a diario.
Cuando algo ocurría en alguno de esos 20 servidores tenía que buscar la mejor solución sin dañar la máquina y así evitar la caída del sitio web alojado. Bastante tedioso el tema.
Mascota o Ganado, ¿qué prefieres?
Adelanto algunos años y en otra empresa en qué trabajé debí diseñar e implementar la arquitectura para una SaaS. En el diseño se contemplaba usar un balanceador de carga y diferentes máquinas detrás de este. Estuvo muy claro que debía valerme de las populares AMI de AWS.
Una AMI es una Amazon Machine Image que viene siendo una copia de un servidor lista para lanzarse como uno con la menor cantidad de configuración posible. Muy similar como en VirtualBox las OVA u OVF.
Entonces ocurría que tenía una AMI para el(los) servidor(es) que alojarían la API y los procesos en segundo plano, otra AMI para el cliente web(una app Angular) y otra AMI para el servidor de integración continua.
Cuándo había problemas en cualquiera de ellos, ingresaba en el servidor en cuestión, buscando de la lista de IPs donde cada máquina tenía un número y un comando al lado para ingresa prontamente. Si en algún momento el problema era complicado, simplemente optaba por “matar” la máquina y recrear una nueva a partir de la AMI.
Es así que por un lado está la experiencia de tener que cuidar a las máquinas con cariño y esmero; y en el otro lado estaban las máquinas “desechables”. Luego aprendí que hay un nombre, no estándar, pero sí muy preciso a modo de analogía, para determinar cómo se está administrando la infraestructura de un producto web: si como mascota o como ganado.
Infraestructura como mascota o ganado(pet vs cattle) significa que si tenemos un servidor que cuidamos mucho y que en caso de fallo el servicio se interrumpe, estamos hablando de un servidor tipo mascota. Como un perrito el cual cuidas, alimentas, mimas, etc.
Por otro lado, si el servidor simplemente, al menor indicio de un problema de muchas horas y esfuerzo, puede ser fácilmente eliminado y reproducido, sin causar mayor inconveniente a la operación del producto, estamos hablando de un servidor tipo ganado. Como las vacas, la ordeñas, le sacas cría, luego le sacas todo su producto(carne, cuero, hueso, etc) y vuelves a criar la cría para que un día repita el ciclo.
Da la sensación que hoy en día lo ideal sería tener todo como ganado. Si tenemos en cuenta la popularidad de plataformas en la nube como AWS, Google Cloud, Microsoft Azure y otras un poco menos grandes como Digital Ocean, Linode o Clouding, pensar en gestionar los servidores como mascota debería ser impensable. Sin embargo, cada uno tiene su caso de uso.
AWS, Docker, Packer, Cloud init
Es válido optar por una mentalidad donde la infraestructura web sea fácilmente reemplazable, donde las configuraciones se hagan una sola vez y sea más sencillo replicar que corregir, donde descartar sea mejor que indagar y resolver(no siempre, pero en algunos casos sí), no obstante, hay situaciones donde vamos a tener un servidor que cuidemos y demos todo el cariño del caso, y no quiere decir que esté mal.
En los casos en los que se quiera tener configuraciones repetibles uno se puede valor de herramientas como las AWS AMI(se pueden crear en la consola de AWS o usando Packer), imágenes en Docker, o scripts escritos en Bash que se ejecuten por medio de cloud-init. Cada una tiene su forma de trabajo diferente pero generalmente apuntan al mismo objetivo: hacer y deshacer como pan de cada día servidores.
Ahora, en el caso cuando debemos mantener con cuidado y por mucho tiempo a una misma máquina(o varias), lo ideal es aceptar esta situación y pensar siempre en cuadrar todo de una forma en que haya rutas definidas para identificar errores y poder resolver situaciones que interrumpan el normal funcionamiento lo más pronto posible. Con esto me refiero a herramientas de monitoreo, centralización de logs, generación de logs de comandos y/o procesos personalizados, procesos siempre vigilados por un supervisor de procesos(systemd, upstart, pm2, foreman, monit, god), mantenimientos programados y como no, respaldos(backups) de todo.
Finalmente, no se puede decir que haya un acercamiento mejor o peor, todo depende del caso de uso, del manejo que se requiera y sea adecuado según el proyecto, plataforma o necesidad.
Este artículo fue publicado primero en mi blog personal, Otro Espacio Blog. Ahí escribo sobre todo lo que aprendo al programar y también sobre temas no relacionados a tecnología.
Top comments (1)
Un articulo excelente, felicitaciones!