En los últimos años se ha extendido de forma exponencial la tecnología de docker (contenedores) en todos los campos y ámbitos de la informática.
Pero realmente, ¿está justificada la adopción de contenedores en todos los casos? Ante esta pregunta nos encontramos con defensores y detractores a ultranza, pero como todo en la vida, depende del punto de vista. Instalar en un Seiscientos un motor de un Ferrari no lo convierte en un deportivo. No todo es blanco o negro, hay una extensísima gama de grises.
El uso de Docker se justifica en muchas ocasiones como un patrón de arquitectura que asegura la inmutabilidad de una infraestructura, pero… ¿es la única forma de conseguir una plataforma inmutable?
Infraestructura inmutable
Lo primero es explicar el concepto y las ventajas de una infraestructura inmutable, y luego veremos cómo conseguirlo sin contenedores.
Un sitio Web está compuesto por una aplicación, bien sea propia o de terceros, mantenida y actualizada por un equipo de desarrollo, y por un servidor que contiene una serie de servicios instalados y configurados para poder ejecutar dicha aplicación, y cuya responsabilidad es del equipo de sistemas.
Esta forma de trabajo, para grandes proyectos, se ha quedado obsoleta. Supongamos que la aplicación y el sistema forman parte de un todo, y que son un único objeto o artefacto. Esta metodología evita que una actualización del sistema pueda representar un problema para la versión del código de aplicación que está corriendo en ese momento o viceversa, y permite tratar al conjunto como un todo, permitiendo que una actualización de código o del sistema consista básicamente en sustituir el artefacto completo por uno nuevo.
Éste es el concepto de infraestructura inmutable.
Qué es Docker
La implementación más rápida de este concepto es la de Docker, ya que permite crear un contenedor con los servicios necesarios y con el código actualizado en su interior, haciéndolo 100% funcional. Una subida a producción consistiría en sustituir los contenedores viejos por los nuevos, consiguiendo de forma indirecta un despliegue blue/green.
Por el contrario, esta implementación tiene una serie de inconvenientes que van desde la dificultad en la gestión y mantenimiento al añadir una capa más de complejidad y una nueva tecnología, hasta la imposibilidad de cambiar una configuración del sistema sin hacer una sustitución completa de todos los contenedores.
Se puede garantizar la inmutabilidad de un sistema sin necesidad del uso de contenedores, aunque en cualquier caso se requiere de un análisis profundo de cada proyecto que implica un elevado conocimiento del mismo y de un diseño de arquitectura correcto.
Para conseguir la estabilidad necesaria en un entorno de producción que permite modificar el código de la aplicación sin impacto en el sistema o viceversa, debe seguirse una única premisa: consistencia entre entornos. La capacidad de poder actualizar la aplicación o el sistema la proporciona un diseño por capas.
Ambos objetivos se consiguen siguiendo una metodología que obliga a que todos los entornos del proyecto (pre, test, Q&A, UA, pro…) sean iguales con respecto a infraestructura (aunque con diferente dimensionamiento), funcionalidades y con un único origen tanto para el sistema como para el código de la aplicación.
Para ello se requiere que:
- Todos los entornos tengan la misma configuración de infraestructura de servicios. Una metodología Infrastructure as Code (IaC) para el despliegue de cada entorno facilita la consistencia.
- Todos los entornos compartan la misma plantilla a partir de la cual se generan los servidores. La aplicación que corra en dichos servidores conocerá en qué entorno está corriendo por una simple variable que se «inyecta» a la hora de generar el servidor a partir de la imagen genérica.
- Todos los entornos compartan el mismo repositorio de código de aplicación, evitando que una versión de código pueda correr en producción sin haber pasado por los entornos anteriores (de misma disposición de infraestructura, servicios y sistema). La aplicación será capaz de seleccionar su configuración en función del entorno en el que esté corriendo.
El objetivo final es que no pueda existir en producción una combinación de código, sistema e infraestructura que no se haya dado en entornos previos.
Si todas estas reglas se implementan en scripts de creación, mantenimiento y despliegue tanto de plataforma como de código, garantizamos la consistencia entre entornos, la independencia entre capas (infraestructura, sistema, aplicación) y por tanto la inmutabilidad del entorno de producción.
Aun así, la realidad supera siempre cualquier análisis o diseño y cualquier tecnología o metodología que se emplee. Por muchas medidas que quieran tomarse para evitar una caída del sistema, esto es prácticamente imposible, y tarde o temprano pasará.
La cuestión es ¿cuánto te costará localizar, analizar y solucionar el problema? Durante el día de ayer 3 de los servicios más grandes de Internet a nivel mundial: Facebook, Instagram y WhatsApp cayeron y tan sólo les costó algo más de un par de horas solventarlo.
¿Tienes el control suficiente sobre todas tus tecnologías de producción para levantar un servicio mundial en menos de 3 horas?
