Riesgo frente a recompensa: una guía para comprender los contenedores de software

Aquellos de nosotros que tenemos la edad suficiente podemos recordar un día en que el software se entregó principalmente por medios físicos. La difusión de Internet de banda ancha y los teléfonos inteligentes nos ha llevado a la era del servicio web: software alojado en la nube al que acceden los clientes de los usuarios, como navegadores y aplicaciones.

No hace mucho tiempo, las aplicaciones web se ejecutaban directamente en máquinas físicas en centros de datos privados. Para facilitar la administración, estas aplicaciones solían ser monolíticas: un solo servidor grande contendría todo el código de back-end y la base de datos. Ahora, los servicios de alojamiento web como Amazon y la difusión de la tecnología de hipervisor han cambiado todo eso. Gracias a Amazon Web Services (AWS) y herramientas como VirtualBox, se ha vuelto fácil empaquetar un sistema operativo completo en un solo archivo.

Con servicios como EC2, se ha vuelto fácil empaquetar imágenes de máquinas y unir conjuntos de servidores virtuales. Llegó el paradigma de los microservicios, un enfoque de la arquitectura de software en el que las aplicaciones monolíticas grandes se dividen en servicios enfocados más pequeños que hacen bien una cosa. En general, este enfoque permite una escalabilidad y un desarrollo de funciones más sencillos, ya que los cuellos de botella son más rápidos de encontrar y los cambios del sistema son más fáciles de aislar.

Mascotas al Ganado

Me convertí en ingeniero de infraestructura justo en el apogeo de esta tendencia. Recuerdo haber construido mi primer entorno de producción en Amazon usando una serie de scripts de bash. Los servidores eran como mascotas para mí. Le di a cada uno de ellos lindos nombres. Los supervisé cuidadosamente. Respondí a las alertas rápidamente y las mantuve saludables. Traté esos casos con amor y afecto porque era doloroso tratar de reemplazarlos, como una mascota querida.

Llegó Chef, una herramienta de administración de configuración, y casi de inmediato mi vida se hizo más fácil. Con herramientas como Chef y Puppet, puede eliminar la mayor parte del dolor manual asociado con la administración de un sistema en la nube. Puede usar su construcción de "entornos" para separar los servidores de desarrollo, ensayo y producción. Puede usar sus "bolsas de datos" y "roles" para definir parámetros de configuración e impulsar conjuntos de cambios. Ahora, todos mis servidores “mascotas” se habían graduado de la escuela de obediencia.

Luego, en 2013, llegó Docker y comenzó una nueva era: la era del software como ganado (disculpas a los veganos en la audiencia). El paradigma del contenedor es de orquestación, no de gestión de la configuración. Herramientas como Kubernetes, Docker Compose y Marathon se centran en mover imágenes predefinidas en lugar de ajustar los valores de configuración en las instancias en ejecución. La infraestructura es inmutable; cuando un contenedor falla, no tratamos de arreglarlo, le disparamos en la cabeza y lo reemplazamos. Nos preocupamos más por la salud del rebaño que por los animales individuales. Ya no damos nombres lindos a nuestros servidores.

las recompensas

Los contenedores facilitan muchas cosas. Permiten que las empresas se concentren más en su propia salsa especial. Los equipos de tecnología pueden preocuparse menos por la administración de la infraestructura y la configuración y, en cambio, preocuparse principalmente por el código de la aplicación. Las empresas pueden ir un paso más allá y usar servicios administrados para cosas como MySQL, Cassandra, Kafka o Redis para no tener que lidiar con la capa de datos en absoluto. Hay varias nuevas empresas que ofrecen servicios de aprendizaje automático "plug and play" para permitir que las empresas realicen análisis sofisticados sin preocuparse por la infraestructura. Estas tendencias han culminado en el modelo sin servidor, un enfoque de arquitectura de software que permite a los equipos lanzar software sin administrar una sola VM o contenedor. Los servicios de AWS como S3, Lambda, Kinesis y Dynamo lo hacen posible. Entonces, para extender la analogía, hemos pasado de mascotas a ganado a algún tipo de servicio de animales a pedido.

Todo esto mola mucho. Es una locura que vivamos en una época en la que un niño de doce años puede poner en marcha un sistema de software sofisticado con unos pocos clics. Recordemos que, no hace mucho tiempo, esto era imposible. Hace solo unos pocos presidentes de EE. UU., los medios físicos eran el estándar y solo las grandes empresas tenían los medios para fabricar y distribuir software. Las correcciones de errores fueron un lujo. Ahora, ese niño de doce años puede crear una cuenta de AWS y hacer que su software esté disponible para todo el mundo. Si hay un error, alguien lo molestará en Slack y, en unos minutos, habrá una solución para todos los usuarios.

Los riesgos

Muy, muy bueno, pero no sin su precio: la dependencia de los proveedores de la nube como Amazon significa la dependencia de las grandes corporaciones y las tecnologías patentadas. Si Richard Stallman y Edward Snowden no te han hecho preocuparte por esas cosas, la reciente debacle con Facebook ciertamente debería haberlo hecho.

Una mayor abstracción lejos del hardware también conlleva el riesgo de una menor transparencia y control. Cuando algo falla en un sistema que ejecuta cientos de contenedores, debemos esperar que la falla surja en algún lugar que podamos detectar. Si el problema está relacionado con el sistema operativo host o el hardware subyacente, puede ser difícil determinarlo. Una interrupción que podría haberse resuelto en 20 minutos con máquinas virtuales puede tardar horas o días en resolverse con contenedores si no tiene la instrumentación adecuada.

No son solo las fallas las que debemos preocuparnos cuando se trata de cosas como Docker. También está el problema de la seguridad. Independientemente de la plataforma de contenedores que utilicemos, debemos confiar en que no hay puertas traseras ni vulnerabilidades de seguridad no reveladas. El uso de plataformas de código abierto tampoco es garantía de seguridad. Si confiamos en imágenes de contenedores de terceros para partes de nuestro sistema, podemos ser vulnerables.

Envolver

El paradigma ganadero es atractivo por varias razones, pero no está exento de inconvenientes. Antes de apresurarse a colocar en contenedores toda la pila, los equipos de tecnología deben pensar si es o no la opción correcta y asegurarse de que pueden mitigar los efectos negativos.

Personalmente, me encanta trabajar con contenedores. Estoy emocionado de ver a dónde van las cosas en los próximos diez años a medida que surgen nuevas plataformas y paradigmas. Sin embargo, como ex consultor de seguridad, soy lo suficientemente cauteloso como para saber que todo tiene un precio. Depende de los ingenieros permanecer atentos para garantizar que no renunciemos a nuestra autonomía como usuarios y desarrolladores. Ni siquiera el flujo de trabajo de CD/CI más sencillo del mundo valdría la pena.