Jerarquía de necesidades de automatización de Maslow
Si hay algo más popular que los contenedores en estos momentos, probablemente sea algo basado en ellos, como por ejemplo sin servidor. Además de ser el chico “genial” del momento, también es el foco de atención de cuán importante es la automatización y la orquestación* para las aplicações modernas.
Casi todos los días llega algún nuevo componente a las arquitecturas de contenedores y, con él, el nivel adecuado de automatización. Si algo se puede automatizar en un mundo de contenedores, se hará. Una gran cantidad de API y una dependencia de artefactos basados en plantillas/configuración impulsan la evolución casi continua de la automatización dentro de entornos basados en contenedores. Si la economía API es importante para la transformación digital de las empresas, entonces la otra economía API es fundamental para la transformación digital de TI.
Los entornos de contenedores no son una excepción y, a medida que continúan abriéndose camino en los entornos de producción, se vuelve cada vez más importante que los servicios ascendentes (N-S) no solo puedan entregar las aplicaciones que se escalan y sirven desde estos entornos altamente volátiles, sino también integrarse con ellos en las capas de automatización y orquestación.
Esto se debe a que algunas de las capas de esta “pila” de tecnología son más volátiles que otras. La creación y destrucción de contenedores, por ejemplo, ocurre con mucha más regularidad que la creación y/o destrucción de clústeres enteros. De hecho, el informe sobre la adopción de Docker de Data Dog HQ señala que “en marzo de 2017, aproximadamente el 40 por ciento de los clientes de Datadog que ejecutaban Docker también ejecutaban Kubernetes , Mesos, Amazon ECS , Google Container Engine u otro orquestador”. La automatización/orquestación es fundamental para el éxito del contenedor, especialmente en su núcleo. Esto significa que a medida que avanzamos, es imperativo que algunas necesidades de automatización se satisfagan lo más rápido (y completamente) posible, porque son la base de todo lo demás.
Esto también es válido para los entornos de nube. Después de todo, no es solo la volatilidad lo que impulsa la necesidad de automatización y orquestación, sino también la agilidad. El complejo modelo de “autoservicio” asociado con la computación en la nube exige automatización para respaldar la noción de arquitecturas elásticas y bajo demanda de la computación en la nube dentro de un modelo de computación de utilidad. Existe un conjunto identificable de necesidades de automatización comunes tanto a la nube como a los contenedores que sientan las bases para comprender su valor para el negocio.
Al igual que la jerarquía de necesidades de Maslow, la jerarquía de necesidades de automatización se basa en la premisa de que existen necesidades de “deficiencia” que deben satisfacerse para progresar hacia necesidades de orden superior que permitan el crecimiento.
Es necesario satisfacer necesidades de déficit de nivel inferior antes de avanzar para satisfacer necesidades de crecimiento de nivel superior. Cuando una necesidad deficitaria ha sido satisfecha, desaparecerá y nuestras actividades se dirigirán habitualmente a satisfacer el siguiente conjunto de necesidades que aún tenemos que satisfacer. Éstas se convierten entonces en nuestras necesidades más destacadas. Sin embargo, las necesidades de crecimiento siguen sintiéndose y podrían incluso hacerse más fuertes una vez que se hayan abordado. Una vez que estas necesidades de crecimiento se han satisfecho razonablemente, uno puede ser capaz de alcanzar el nivel más alto llamado autorrealización. - https://www.simplypsychology.org/maslow.html
En esencia, esta particular jerarquía de necesidades de automatización se centra en las necesidades fundamentales en torno a la escalabilidad de las aplicações y sus servicios compuestos. Como lo explica el talentosísimo ingeniero de F5 que presentó por primera vez este concepto: “La automatización en la base es la más valiosa porque es la que ocurre con más frecuencia y es crucial para que una aplicação permanezca en línea. La automatización en la cima es la menos valiosa porque ocurre con menos frecuencia (quizás solo "una vez") y ocurre al mismo tiempo que muchas personas ya están haciendo cosas manuales.
Estas son las necesidades “básicas” de automatizar la creación/destrucción de contenedores/máquinas virtuales y aplicaciones que son fundamentales no solo para la escalabilidad, sino también para la eficacia de la escalabilidad. Esa eficacia es importante para limitar los costos y aliviar la carga de escala que tradicionalmente recae sobre las operaciones manuales (costosas). Dado el volumen y la frecuencia con que tales eventos ocurren hoy en día, la automatización es un requisito, no algo lujoso. Es una necesidad deficiente , lo que significa que si no se satisface, hay pocos motivos para preocuparse por una automatización de orden superior y de ocurrencia menos frecuente.
Esto es especialmente cierto para los contenedores, y parece validado nuevamente por Data Dog cuando señala que "los contenedores tienen una vida útil promedio de 2,5 días, mientras que en todas las empresas, las máquinas virtuales tradicionales y basadas en la nube tienen una vida útil promedio de 23 días". Al parecer, esto se ve afectado por la automatización. “En las organizaciones que ejecutan Docker con un orquestador, la vida útil típica de un contenedor es inferior a un día. En las organizaciones que ejecutan Docker sin orquestación, el contenedor promedio existe durante 5,5 días”.
La capacidad de automatizar la creación y destrucción de contenedores y, posteriormente, de aplicaciones es fundamental para lograr la velocidad y la agilidad de escala necesarias para que las organizaciones aprovechen los beneficios de los contenedores tanto en entornos tradicionales como basados en la nube.
Las necesidades de automatización de orden superior son en gran medida necesidades de enrutamiento y se clasifican en necesidades de crecimiento. Las necesidades de crecimiento se buscan una vez que se han satisfecho las necesidades básicas (deficiencia) . La creación y destrucción de clústeres y los cambios de enrutamiento ocurren con poca frecuencia y solo se vuelven valiosos una vez que la aplicación está instalada y puede escalar. Esto se vuelve imperativo una vez que el entorno migra de desarrollo/prueba a un entorno de producción y se confía en que brindará valor comercial al ofrecer aplicações. Después de todo, dirigirse a una aplicación que no puede responder es como darle un abrazo a un hombre hambriento. La cálida sensación no satisface la necesidad básica de alimento. Una encuesta realizada por Mesosphere en 2016 a sus usuarios descubrió que el 62% de ellos ya utilizaban contenedores en entornos de producción. Una encuesta de Portworx de 2017 en la conferencia centrada en contenedores DockerCon descubrió que el 67,2 % de sus encuestados usaban contenedores en producción. Lo que significa que las necesidades de enrutamiento se están volviendo importantes rápidamente, al menos para el subconjunto de organizaciones que adoptan contenedores.
El objetivo final de la autorrealización empresarial –el crecimiento– no se puede lograr hasta que se cumpla toda la jerarquía; es decir, hasta que toda la “pila” esté automatizada y orquestada. Por lo tanto, debería darse por sentado que quienes viven principalmente en el plano de datos NS orquestarán desde abajo hacia arriba, permitiendo primero las necesidades de escalamiento del entorno y trabajando hasta las necesidades de enrutamiento, donde se produce la transición del tráfico NS al EW. Esto también es evidente en el continuo desarrollo de un ecosistema cada vez más acoplado en torno a los propios orquestadores de contenedores, como Kubernetes. Uno de los desarrollos más recientes se ha centrado en las necesidades de “enrutamiento” con la inclusión de controladores de ingreso que enrutan en la capa 7 (URI/API) para garantizar que la transición de NS a los servicios EW se realice sin problemas. Ese componente también debe eventualmente integrarse (automatizarse) para satisfacer las necesidades de enrutamiento y continuar impulsando a las organizaciones hacia arriba en la jerarquía para lograr el crecimiento.
Traducir esto a construcciones específicas de contenedores nos permite mapear las necesidades de automatización del entorno de contenedores a aquellos servicios en la red que respaldan su necesidad de escalar para lograr el crecimiento. Tanto las construcciones de contenedores como las de servicios de red/ aplicação requieren automatización. Crear cien contenedores para escalar una aplicación sin automatizar simultáneamente los servicios responsables de gestionarlos durante la entrega genera necesidades insatisfechas. Estas construcciones de red pueden existir como construcciones de contenedor nativas o como servicios de aplicaciones existentes adaptados para encajar de forma nativa en el entorno de contenedores. Los detalles de implementación variarán según la arquitectura y los requisitos operativos, aunque la existencia de ambos conjuntos de construcciones es necesaria para satisfacer las necesidades básicas (escala) y de crecimiento (enrutamiento) para lograr el éxito.
En todos los casos, el éxito de los contenedores y la nube depende en gran medida de sus ecosistemas y eso significa depender de la economía de otras API para permitir la automatización y la orquestación fundamentales para el crecimiento empresarial a través de iniciativas de transformación digital .
*Me resulta frustrante que los conceptos de automatización y orquestación parezcan fusionarse dentro del mundo de los contenedores, yuxtaponiéndose uno con el otro. Pero por ahora, ignoremos eso y trataré de mantener al pedante dentro de donde pertenece. Dentro de mi cabeza. Estridente. Desesperadamente.