En el pasado, las transmisiones de los automóviles eran manuales. Algunos podrían haberse referido a ellos como "palo" gracias al mecanismo mediante el cual se cambian las marchas. En aquella época, una transmisión automática era algo especial que a menudo había que pedir. Su nombre viene de la forma en la que el coche cambia de marcha automáticamente. Lo cual, para ser honesto, es bastante agradable. Después de todo, hay muchas variables que gestionar cuando intentas cambiar de marcha manualmente.
Hoy en día, las transmisiones automáticas son el estándar. El manual es un misterio para la mayoría. Intenté enseñarle a cada uno de mis tres hijos mayores cómo conducir uno. No recomiendo intentarlo si estás considerándolo. No, si te gusta tener una transmisión que funcione en tu auto.
Menciono este cambio en las expectativas y estándares como preludio a una discusión sobre las operaciones. En gran parte, esto se aplica a la infraestructura de red y de servicios de aplicação , pero esto también es válido fuera de esos dominios.
El cambio es hacia la automatización, sí, pero también es un cambio en las expectativas con respecto al conocimiento necesario para operar la infraestructura.
Volviendo a mi analogía de la transmisión, si conduces un coche con transmisión manual tienes muchas variables que gestionar. Es necesario coordinar el embrague y el acelerador. Es necesario escuchar el motor y reconocer cuándo cambiar de marcha. También tienes que saber en qué marcha estás, y en qué marcha vas a ir, y cómo mover el "stick" para llegar allí.
Estos reflejan los tipos de conocimientos que necesita para implementar manualmente la infraestructura de servicios de aplicação y redes. Es necesario saber mucho sobre cómo funciona la red para garantizar que el tráfico llegue de un lugar a otro.
La adopción de la nube inició la transición de las expectativas respecto de este "estándar". Si bien aún es necesario comprender algunos conceptos básicos de redes, no es necesario que comprenda necesariamente cómo funcionan. Con la introducción de los contenedores, la expectativa se ha desplazado aún más hacia la derecha, y casi no hay necesidad de pensar siquiera en direcciones IP.
Lo que esto hace es cambiar las expectativas operativas. Estamos pasando de una economía de operaciones expertas a una economía de operaciones mercantilizadas . Hoy en día, se espera que los aspectos operativos de la implementación de la infraestructura de servicios de redes y aplicação sean accesibles para un conjunto más amplio de roles dentro de la organización. Para llegar a ello es necesaria la simplificación.
En concreto, la simplificación operativa . No basta con entregar servicios de red y aplicação a través de opciones de autoservicio, sino que deben ser utilizables por aquellos que los utilizarán. Tiene que ser aún más sencillo de lo que es ahora.
Eso puede significar sacrificar la configurabilidad por la operatividad.
Al igual que con la nube y los contenedores, las abstracciones ubicadas sobre la infraestructura de servicios de aplicação y redes se extienden al uso de esas abstracciones. Con esto me refiero a la lengua vernácula. La terminología. El modelo de datos. La configuración actual .
Lo que quiero decir con esto, para aquellos lectores que no son programadores, es que cada construcción tiene un conjunto de atributos asociados que conforman el "objeto". Un objeto de servidor virtual tiene una dirección IP, un grupo de aplicações, eventos, un nombre y muchas otras características. Algunas de esas características son en realidad objetos, o listas de objetos. Recorrer estos constructos puede resultar complejo. Porque la configurabilidad es imperativa a la hora de ajustar la infraestructura. Desea tener la capacidad de ajustar características muy específicas (como alternar el algoritmo de Nagle o modificar el tamaño de la ventana TCP) para optimizar el rendimiento o la capacidad.
Ahora bien, en un modelo de operaciones mercantilizado —que es hacia donde nos dirigimos— la operabilidad es más importante que la configurabilidad. Menos opciones, tiempo de actividad más rápido.
Pero esto no significa simplemente quitar opciones. La simple eliminación de la capacidad de modificar las opciones sólo satisface los requisitos básicos de operatividad ; no cumple las expectativas de una experiencia operativa simplificada. Todavía es necesario comprender el modelo de objetos. Lo que es necesario es abstraer el modelo en algo más simple. Digamos que un servidor virtual se reduce a una dirección IP, un nombre y una lista de instancias de aplicação .
Se trata de una iniciativa importante porque no existe un modelo común sobre el cual opere la infraestructura del servicio de aplicação . La forma en que se representan los servidores virtuales, el control de ingreso y las políticas de seguridad varía de un producto a otro y de un servicio a otro.
Se requiere que las operaciones, ya sea del lado de desarrollo o del lado de TI, comprendan una gran cantidad de modelos para implementar y operar los catorce servicios de aplicação que se usan en promedio para entregar y proteger las aplicaciones . Existe mucha variación, lo que en el pasado ha llevado a que se requieran innumerables certificados para verificar la experiencia requerida para gestionar estos servicios.
El otro cambio operativo se aleja de este enfoque. Se trata de una expectativa de simplicidad, facilidad de uso y uniformidad en las ofertas como forma de reducir la deuda técnica generada por los modelos operativos específicos de cada dispositivo. Es una expectativa de estandarización ; no de protocolos y comportamiento de red, que ya existen en el espacio de infraestructura de red . Pero de cómo representamos esos protocolos y comportamientos de red.
Vemos que esto se desarrolla en las encuestas sobre contenerización , en las que las habilidades necesarias son citadas como un inhibidor importante para la adopción por casi uno de cada cuatro (24%) de los encuestados, junto con el 33% que dijo que era un inhibidor moderado. La infraestructura (en la que ciertamente se incluyen los contenedores y los sistemas de orquestación de contenedores dada su prevalencia en los entornos de producción actuales) está siendo impulsada por una falta de habilidades y un deseo de velocidad hacia operaciones mercantilizadas.
Ese deseo y necesidad se ve en la adopción orgánica de archivos de recursos de Kubernetes que intentan describir dichos servicios de infraestructura. Estos recursos obligan a todas las operaciones a utilizar un modelo (formato) de datos común (mercantilizado) para describir la implementación y la configuración de un servicio determinado. Dado que las operaciones de TI son el principal impulsor de la adopción de contenedores (35 %) en las organizaciones actuales (según la Encuesta de adopción de contenedores de Diamanti de 2019 ), casi el doble de influyentes que los desarrolladores (16 %) y cuatro veces más que los equipos DevOps integrados (9 %), es importante reconocer este cambio y considerar cuidadosamente cómo la nueva infraestructura encaja (o no encaja) en un entorno de operaciones mercantilizado.
Con o sin esfuerzos oficiales (de un grupo de trabajo o de una fundación), la mercantilización impulsará un estándar de facto en las operaciones. Y ese estándar de facto será uno que enfatice la operabilidad sobre la configurabilidad .