La jerarquía de necesidades de automatización de Maslow

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Si hay algo que esté más de moda que los contenedores ahora mismo, probablemente sea algo basado en ellos, como la informática sin servidor. Además de ser la tecnología «guay» del momento, también pone de relieve la enorme importancia que tienen la automatización y la orquestación* para las aplicaciones modernas.

Prácticamente cada día aparece algún componente nuevo para las arquitecturas de contenedores y, con él, el nivel de automatización adecuado. Si algo se puede automatizar en el mundo de los contenedores, se automatizará. Una gran cantidad de API y la dependencia de artefactos basados en configuraciones o plantillas impulsan la evolución casi continua de la automatización en los entornos basados en contenedores. Si la economía de las API es importante para la transformación digital de las empresas, entonces la otra economía de las API es fundamental para la transformación digital de TI.

Los entornos de contenedores no son una excepción y, a medida que se van incorporando a los entornos de producción, resulta cada vez más importante que los servicios ascendentes (N-S) no solo sean capaces de entregar las aplicaciones que se escalan y sirven desde estos entornos tan volátiles, sino también de integrarse con ellos en las capas de automatización y orquestación.

Esto se debe a que algunas de las capas de esta «pila» tecnológica son más volátiles que otras. Por ejemplo, la creación y destrucción de contenedores se produce con mucha más frecuencia que la creación o destrucción de clústeres completos. De hecho, el informe Adopción de Docker de Data Dog HQ señala que «en marzo de 2017, aproximadamente el 40 % de los clientes de Datadog que utilizaban Docker también usaban Kubernetes, Mesos, Amazon ECS, Google Container Engine u otro orquestador». La automatización y la orquestación son fundamentales para el éxito de los contenedores, especialmente en su núcleo. Esto significa que, a medida que avanzamos, es imprescindible satisfacer determinadas necesidades de automatización con la mayor rapidez y exhaustividad posibles, ya que constituyen la base de todo lo demás.

Esto también se aplica a los entornos en la nube. Al fin y al cabo, la necesidad de automatización y orquestación no solo viene impulsada por la volatilidad, sino también por la agilidad. El complejo modelo de «autoservicio» asociado a la computación en la nube exige automatización para hacer posibles sus arquitecturas elásticas y bajo demanda dentro de un modelo de computación como servicio público. Existe un conjunto claramente identificable de necesidades de automatización comunes tanto a la nube como a los contenedores que sientan las bases para comprender su valor para la empresa.

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 carencia» que deben satisfacerse para poder avanzar hacia necesidades de orden superior que permitan el crecimiento.

Antes de avanzar para satisfacer necesidades de crecimiento de nivel superior, deben satisfacerse las necesidades carenciales de nivel inferior. Cuando se satisface una necesidad carencial, esta desaparece y nuestras actividades pasan a orientarse habitualmente hacia la satisfacción del siguiente conjunto de necesidades que aún no hemos cubierto. Estas se convierten entonces en nuestras necesidades más relevantes. Sin embargo, las necesidades de crecimiento siguen presentes e incluso pueden intensificarse una vez que se han activado. Cuando estas necesidades de crecimiento se han satisfecho de forma razonable, se puede alcanzar el nivel más alto, denominado 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 relacionadas con el escalado de las aplicaciones y los servicios que las componen. Como explica el talentoso ingeniero de F5 que presentó por primera vez este concepto: «La automatización de la parte inferior es la más valiosa porque es la que se produce con mayor frecuencia y resulta crucial para que una aplicación siga funcionando. La automatización de la parte superior es la menos valiosa porque se produce con menor frecuencia (quizá solo “una vez”) y tiene lugar al mismo tiempo que muchas personas ya estarán realizando tareas manuales».

Estas son las necesidades «básicas»: automatizar la creación y destrucción de contenedores, máquinas virtuales y aplicaciones es fundamental no solo para escalar, sino también para la eficacia del escalado. Esa eficacia es importante para contener los costes y aliviar la carga que tradicionalmente supone el escalado para las operaciones manuales (costosas). Dado el volumen y la frecuencia con que se producen actualmente estos eventos, la automatización es un requisito, no algo meramente deseable. Es una necesidad por carencia, lo que significa que, si no se satisface, no tiene mucho sentido preocuparse por automatizaciones de orden superior y menos frecuentes.

Esto es especialmente cierto en el caso de los contenedores, y parece quedar corroborado de nuevo por Data Dog cuando señala que «los contenedores tienen una vida útil media de 2,5 días, mientras que, en el conjunto de las empresas, las máquinas virtuales tradicionales y basadas en la nube tienen una vida útil media de 23 días». Al parecer, la automatización influye en este aspecto. «En las organizaciones que ejecutan Docker con un orquestador, la vida útil habitual de un contenedor es inferior a un día. En las organizaciones que ejecutan Docker sin orquestación, la vida útil media de un contenedor es de 5,5 días».

La capacidad de automatizar la creación y destrucción de contenedores y, posteriormente, de aplicaciones es fundamental para alcanzar la velocidad y la agilidad de escalado que las organizaciones necesitan para aprovechar las ventajas de los contenedores tanto en entornos tradicionales como en la nube.

Las necesidades de automatización de nivel superior son, en esencia, necesidades de enrutamiento y se engloban en lo que se conoce como necesidades de crecimiento. Las necesidades de crecimiento se buscan una vez satisfechas las necesidades básicas (carencias). La creación y destrucción de clústeres y los cambios de enrutamiento se producen con poca frecuencia y solo resultan útiles cuando la aplicación ya está implantada y puede escalar. Esto se vuelve imprescindible cuando el entorno pasa de desarrollo/pruebas a producción y se confía en él para aportar valor empresarial mediante la ejecución de aplicaciones. Al fin y al cabo, dirigir el tráfico a una aplicación que no puede responder es como abrazar a una persona hambrienta. Esa agradable sensación de calidez no satisface la necesidad básica de alimentarse. Una encuesta de Mesosphere a sus usuarios realizada en 2016 reveló que el 62 % ya utilizaba contenedores en entornos de producción. Una encuesta de Portworx realizada en 2017 durante DockerCon, una conferencia centrada en los contenedores reveló que el 67,2 % de los encuestados utilizaba contenedores en producción. Esto significa que las necesidades de enrutamiento están cobrando importancia rápidamente, al menos para el subconjunto de organizaciones que están adoptando contenedores.

El objetivo último de la autorrealización empresarial —el crecimiento— no puede alcanzarse hasta que se complete toda la jerarquía; es decir, hasta que toda la «pila» esté automatizada y orquestada. Por tanto, cabe esperar que quienes operan principalmente en el plano de datos N-S lleven a cabo la orquestación de abajo arriba, atendiendo primero las necesidades de escalado del entorno y avanzando después hasta las necesidades de enrutamiento, donde se produce la transición del tráfico N-S al E-O. Esto también queda patente en el desarrollo continuo de un ecosistema cada vez más estrechamente integrado en torno a los propios orquestadores de contenedores, como Kubernetes. Uno de los avances más recientes se ha centrado en las necesidades de «enrutamiento» mediante la incorporación de controladores de entrada que enrutan en la capa 7 (URI/API) para garantizar que la transición de los servicios N-S a E-O se produzca sin interrupciones. Este componente también deberá integrarse (automatizarse) en última instancia para satisfacer las necesidades de enrutamiento y seguir impulsando a las organizaciones hacia los niveles superiores de la jerarquía para lograr el crecimiento.

Trasladar esto a elementos específicos de los contenedores nos permite vincular las necesidades de automatización del entorno de contenedores con los servicios de red que permiten satisfacer sus requisitos de escalabilidad para lograr el crecimiento. Tanto los elementos de los contenedores como los de los servicios de red y de aplicaciones requieren automatización. Crear cien contenedores para escalar una aplicación sin automatizar simultáneamente los servicios responsables de gestionarlos durante la entrega deja necesidades sin cubrir. Estos elementos de red pueden ser nativos de los contenedores o servicios de aplicaciones existentes adaptados para integrarse de forma nativa en el entorno de contenedores. Los detalles de implementación variarán según la arquitectura y los requisitos operativos, aunque ambos conjuntos de elementos son necesarios para satisfacer las necesidades básicas (escalabilidad) y de crecimiento (enrutamiento) y alcanzar el éxito.

En todos los casos, el éxito de los contenedores y la nube depende en gran medida de sus ecosistemas, lo que implica depender de la otra economía de las API para posibilitar la automatización y la orquestación, fundamentales para el crecimiento empresarial mediante iniciativas de transformación digital.

* Me resulta frustrante que los conceptos de automatización y orquestación parezcan confundirse en el mundo de los contenedores, usando uno en lugar del otro. Pero, por ahora, dejemos eso de lado e intentaré mantener al pedante dentro, donde debe estar. Dentro de mi cabeza. Gritando. Desesperadamente.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie