El mito de un solo panel de control

Desde que tengo memoria -y recuerdo desde hace mucho tiempo- el canto de sirena de un único panel de vidrio a través del cual ver y operar la infraestructura ha atraído al sector TI. Como el Santo Grial, nunca ha sido descubierto y muchos profesionales de TI se han vuelto cínicos en cuanto a su existencia.

La transformación digital ha puesto el último clavo en el ataúd de este mítico modelo de gestión y ha dado lugar a uno nuevo: un plano único de control.

La buena noticia es que, a diferencia del panel de vidrio único que buscaban los intrépidos exploradores de TI del pasado, un único plano de control puede estar a nuestro alcance. Esto se debe a que no se basa en una GUI sino en la API.

Y no cualquier API, sino una API declarativa .

Para entender por qué, permítanme remontarme al año 2010, cuando el término “Infraestructura 2.0” estaba de moda.

En la capa más baja de la arquitectura se encuentra la Infraestructura 2.0 . La Infraestructura 2.0 se centra en permitir el dinamismo y la colaboración en toda la red y la infraestructura de red de distribución de aplicação . Es la forma en que los componentes fundamentales de un centro de datos tradicionalmente desconectados (desde el punto de vista de la comunicación y la gestión) se dotan de la capacidad de conectarse y colaborar. Esto se logra principalmente a través de API abiertas basadas en estándares que proporcionan un conjunto granular de funciones operativas que pueden invocarse desde una variedad de métodos programáticos, como sistemas de orquestación, aplicações personalizadas y mediante la integración con soluciones tradicionales de gestión de centros de datos. La Infraestructura 2.0 trata de hacer que la red sea más inteligente tanto desde el punto de vista de la gestión como del tiempo de ejecución (ejecución), pero en el caso de su relación con la nube y TI como servicio, la visión se centra principalmente en la gestión.

La infraestructura 2.0 incluye la habilitación de servicios de todo, desde enrutadores hasta conmutadores, desde balanceadores de carga hasta aceleración de aplicação , desde firewalls hasta componentes de seguridad de aplicação web hasta infraestructura de servidor (físico y virtual). Se trata, resumido en su esencia, de componentes habilitados para API.

De < https://devcentral.f5.com/articles/infrastructure-20-cloud-it-as-a-service-an-architectural-perfait >

¿Te suena familiar? Ya no lo llamamos Infraestructura 2.0, lo llamamos "implementación continua", "automatización" y otros términos tipo DevOps. Pero el concepto es el mismo. Esta idea esconde el motivo por el cual un "panel de vidrio único" nunca se ha materializado. Porque para que exista una construcción tan mítica, una única solución necesitaría incorporar (integrar mediante métodos manuales) una amplia gama de soluciones de red, servicios de aplicação y seguridad.

Eso nunca iba a pasar.

Para ser honesto, eso nunca iba a suceder a pesar de la habilitación de API de la mayor parte de esa infraestructura. ¿Por qué?Porque todas esas API eran imperativas y estaban tan estrechamente acopladas al modelo de objetos de cada dispositivo como lo estaban sus GUI. Las API imperativas están inherentemente vinculadas a modelos de objetos específicos del dispositivo/servicio que imponen una gran carga de experiencia operativa a quienes intentan utilizarlos. Ahora imagine a los todoterrenos de su organización de TI en quienes confía para administrar operativamente enrutadores, conmutadores, dispositivos de seguridad y cinco categorías diferentes de servicios de aplicação de múltiples proveedores.

Exactamente. Una criatura así es como Bigfoot. A menudo se ha oído hablar de él, pero nunca se ha demostrado que exista.

¿Qué quiero decir con eso? Quiero decir esto:

La forma en que nosotros, por ejemplo, representamos un pool o una VIP (dirección IP virtual) o una VLAN (LAN virtual) no es la misma forma en que Cisco o Citrix o Juniper representan los mismos objetos de red. De hecho, nuestra terminología puede incluso ser diferente: utilizamos "pool" y otros proveedores de ADC utilizan "farm" o "cluster" para representar el mismo concepto. Si añadimos la virtualización a la mezcla, se añade otro conjunto de términos, a menudo conflictivos con los utilizados por los proveedores de infraestructura de red . " Servidor virtual " significa algo completamente diferente cuando lo usa un proveedor de distribución de aplicação que cuando lo usa un proveedor de virtualización como VMWare o Microsoft .

De < https://devcentral.f5.com/articles/making-infrastructure-20-reality-may-require-new-standards >

Ésta es la razón por la que no podemos tener cosas bonitas, como un solo panel de vidrio. Porque la industria no tiene un único panel a través del cual visualizar la infraestructura.

Pero esta publicación no está diseñada para deprimirlo ni para llevarlo por un camino hacia una existencia de TI arruinada por una administración basada en cada dispositivo para siempre. Al contrario. Las API declarativas (verdaderamente declarativas) pueden conducir a un único plano de control.

Pero para hacer eso, debemos alejarnos de la idea de que declarativo significa codificar las configuraciones de nuestro dispositivo en JSON o YAML. Esto no es verdaderamente declarativo porque todavía depende de la experiencia del dominio operativo que está vinculada a modelos de objetos específicos del dispositivo, y nadie más puede ingerirlos y usarlos.

Permítanme utilizar las descripciones de recursos de servicios y puntos finales de Kubernetes como ejemplo de un modelo declarativo:

Todo lo que necesito para configurar un servidor virtual está aquí, en estas definiciones muy concisas y que no dependen de la implementación. La IP externa es la dirección IP virtual: la dirección con la que se comunicará el usuario o la aplicación móvil. El nombre "my-Service" describe un servidor virtual, y la especificación proporciona detalles de la red, como qué puertos utilizar y qué grupo ("MyApp"). Los recursos de punto final describen cada uno de los nodos que componen "mi-servicio" y proporcionan los miembros para el grupo "MiAplicación". Lo único que falta aquí es una forma de seleccionar un algoritmo de equilibrio de carga para aquellos servicios capaces de hacer más que round robin.  Y podríamos ampliar fácilmente la parte " especificación " de la descripción del servicio para incluir un "algoritmo: Opción RR | WRR | LC | FR” que se aplica universalmente a todas las soluciones de equilibrio de carga. Allá. Hecho.

En teoría, puedo alimentar este mismo recurso a cualquiera de diez soluciones de equilibrio de carga diferentes y cada una determinaría cómo modelar e implementar la intención de la descripción, que es configurar un servicio virtual ubicado en el puerto 80.11.12.10 que escala solicitudes HTTP en dos instancias de aplicação ubicadas en 1.2.3.4 y 2.3.4.5 en el puerto 80.

Otra forma de pensar en esto es la diferencia entre "Me gustaría una pizza de pepperoni" y el más tedioso "Me gustaría que mezclaras un poco de masa de pizza y luego la extendieras en un círculo con un diámetro de 10 pulgadas". Cúbrelo con salsa de tomate. Cubre todo con queso mozzarella. Ahora coloca pepperoni por encima. Hornee a 425 grados durante 15 minutos."

Una de estas cosas es más fácil y te oculta los detalles. La otra te obliga no sólo a saber lo que quieres (pizza de pepperoni), sino también cómo hacerla. Ahí está la experiencia operativa.

Al igual que pedir una pizza, la descripción del recurso de Kubernetes es genérica. Nada de lo que contiene fuerza ningún modelo de objeto o método de implementación en particular en el dispositivo que ingiere este recurso. Describe lo que debe estar presente, pero de ninguna manera afecta cómo podría implementarlo.

Ser verdaderamente declarativo significa proporcionar los medios para comunicar la intención y el estado final deseado . En algún momento en el futuro, simplemente podremos decir: "configurar un servicio virtual para 'mi aplicación'" y ¡listo! Utilizando metadatos y etiquetas de aplicação y un descubrimiento inteligente automatizado, el servicio se configurará automáticamente de arriba a abajo*. 

Si alguna vez queremos alcanzar ese nirvana de un único plano de control, vamos a tener que esforzarnos y elaborar especificaciones declarativas neutrales que eliminen la necesidad de integrar mediante API imperativas todos los dispositivos en el centro de datos. Porque la integración de API dispositivo por dispositivo en realidad no es tan diferente de la gestión dispositivo por dispositivo.

Queremos cosas bonitas. Queremos un plano de control único y unificado. Pero para llegar allí, la industria tendrá que hacer algo más que simplemente asentir con la cabeza ante lo declarativo y reconocer que si nadie más puede asimilar y usar su interfaz declarativa, en primer lugar no es realmente declarativa.

*Una chica puede soñar ¿no?