Desde que tengo memoria —y tengo memoria de muchos años—, el canto de sirena de un panel único desde el que visualizar y gestionar la infraestructura ha seducido al sector de TI. Al igual que el Santo Grial, nunca se ha encontrado, y muchos profesionales de TI se han vuelto escépticos respecto a su existencia.
La transformación digital ha dado la puntilla a este mítico modelo de gestión y, en su lugar, ha dado paso a uno nuevo: un plano de control único.
La buena noticia es que, a diferencia del panel único que buscaban los intrépidos exploradores de TI del pasado, puede que un plano de control único esté a nuestro alcance. Esto se debe a que no se basa en una interfaz gráfica de usuario, sino en la API.
Y no una API cualquiera, sino una API declarativa.
Para entender por qué, permíteme remontarme a 2010, cuando el término «Infraestructura 2.0» estaba de moda.
En la capa más baja de la arquitectura se encuentra Infraestructura 2.0. Infraestructura 2.0 se centra en aportar dinamismo y colaboración a toda la infraestructura de red y de la red de entrega de aplicaciones. Es la forma de dotar a los componentes fundamentales del centro de datos, tradicionalmente desconectados (desde el punto de vista de la comunicación y la gestión), de la capacidad de conectarse y colaborar. Esto se consigue principalmente mediante API abiertas y basadas en estándares que proporcionan un conjunto granular de funciones operativas que pueden invocarse mediante diversos métodos programáticos, como sistemas de orquestación, aplicaciones personalizadas y la integración con soluciones tradicionales de gestión de centros de datos. Infraestructura 2.0 consiste en hacer que la red sea más inteligente tanto desde el punto de vista de la gestión como del tiempo de ejecución, pero, en lo que respecta a su relación con la nube y TI como servicio, la perspectiva se centra principalmente en la gestión.
Infraestructura 2.0 permite ofrecer como servicio todo tipo de elementos, desde routers hasta conmutadores, desde balanceadores de carga hasta soluciones de aceleración de aplicaciones, desde cortafuegos hasta componentes de seguridad de aplicaciones web, así como infraestructura de servidores (físicos y virtuales). En esencia, se trata de componentes habilitados mediante API.
De <https://devcentral.f5.com/articles/infrastructure-20-cloud-it-as-a-service-an-architectural-parfait>
¿Te suena? Ya no lo llamamos Infraestructura 2.0, sino «despliegue continuo», «automatización» y otros términos propios de DevOps. Pero el concepto es el mismo. Esta idea encierra la razón por la que nunca se ha materializado un «panel único». Para que una solución tan mítica pudiera existir, tendría que incorporar (integrar mediante métodos manuales) una amplia variedad de soluciones de red, servicios de aplicaciones y seguridad.
Eso nunca iba a suceder.
A decir verdad, nunca iba a suceder, pese a que la mayor parte de esa infraestructura estuviera habilitada mediante API. ¿Por qué? Porque todas esas API eran imperativas y estaban tan estrechamente vinculadas al modelo de objetos de cada dispositivo como sus interfaces gráficas. Las API imperativas están intrínsecamente ligadas a modelos de objetos específicos de cada dispositivo o servicio, lo que exige amplios conocimientos operativos a quienes intentan utilizarlas. Ahora piense en esa persona polivalente de su organización de TI en quien confía para gestionar operativamente routers, switches, dispositivos de seguridad y cinco categorías distintas de servicios de aplicaciones de varios proveedores.
Exacto. Una criatura así es como Bigfoot: se oye hablar de ella a menudo, pero nunca se ha demostrado que exista.
¿Qué quiero decir con eso? Me refiero a lo siguiente:
La forma en que, por ejemplo, representamos un pool, una VIP (dirección IP virtual) o una VLAN (red de área local virtual) no es la misma que la forma en que Cisco, Citrix o Juniper representan esos mismos objetos de red. De hecho, puede que incluso nuestra terminología sea diferente: nosotros usamos «pool», mientras que otros proveedores de ADC utilizan «granja» o «clúster» para representar el mismo concepto. Si añadimos la virtualización, entra en juego otro conjunto de términos que a menudo entran en conflicto con los utilizados por los proveedores de infraestructura de red. «Servidor virtual» significa algo completamente distinto para un proveedor de entrega de aplicaciones que para un proveedor de virtualización como VMWare o Microsoft.
De <https://devcentral.f5.com/articles/making-infrastructure-20-reality-may-require-new-standards>
ESTA es la razón por la que no podemos tener cosas buenas, como un panel único. Porque el sector no dispone de un panel único desde el que él mismo pueda visualizar la infraestructura.
Pero esta publicación no pretende deprimirte ni conducirte hacia una existencia en el ámbito de las TI marcada para siempre por la gestión individual de cada dispositivo. Al contrario. Las API declarativas —verdaderamente declarativas— pueden dar lugar a un único plano de control.
Pero, para lograrlo, debemos dejar atrás la idea de que un enfoque declarativo consiste en codificar las configuraciones de nuestros dispositivos en JSON o YAML. Esto no es realmente declarativo, porque sigue dependiendo de conocimientos especializados del ámbito operativo vinculados a modelos de objetos específicos de cada dispositivo, que nadie más puede procesar ni utilizar.
Permítanme utilizar las descripciones de recursos Service y Endpoint de Kubernetes como ejemplo de un modelo declarativo:
DECLARATIVO - SERVICIO | DECLARATIVO - PUNTOS DE CONEXIÓN |
kind: Service | kind: Endpoints |
Todo lo que necesito para configurar un servidor virtual está aquí mismo en estas definiciones tan concisas e independientes de la implementación. La externalIP es la dirección IP virtual, es decir, la dirección con la que se comunicará el usuario o la aplicación móvil. El nombre «my-Service» describe un servidor virtual, mientras que spec proporciona los detalles de red, como qué puertos utilizar y qué grupo («MyApp»). Los recursos Endpoint describen cada uno de los nodos que componen «my-service» y proporcionan los miembros del grupo «MyApp». Lo único que falta aquí es una forma de seleccionar un algoritmo de balanceo de carga para aquellos servicios capaces de hacer algo más que una distribución por turnos. Además, podríamos ampliar fácilmente la sección «spec» de la descripción del servicio para incluir una opción «algorithm: RR | WRR | LC | FR» aplicable universalmente a todas las soluciones de balanceo de carga. Ya está. Listo.
En teoría, puedo proporcionar este mismo recurso a cualquiera de diez soluciones de balanceo de carga diferentes, y cada una determinaría cómo modelar e implementar la intención de la descripción: configurar un servicio virtual ubicado en 80.11.12.10, puerto 80, que distribuya las solicitudes HTTP entre dos instancias de la aplicación ubicadas en 1.2.3.4 y 2.3.4.5, en el puerto 80.
Otra forma de verlo es pensar en la diferencia entre «Quiero una pizza de pepperoni» y la opción más tediosa: «Quiero que prepares masa de pizza y luego la extiendas formando un círculo de 10 pulgadas de diámetro. Cúbrela con salsa de tomate. Añade encima queso mozzarella. Ahora reparte el pepperoni por toda la superficie. Hornéala a 425 grados durante 15 minutos».
Una de estas opciones es más sencilla y te evita tener que conocer los detalles. La otra te obliga no solo a saber qué quieres —una pizza de pepperoni—, sino también cómo prepararla. Eso es precisamente la experiencia operativa.
Al igual que al pedir una pizza, la descripción del recurso de Kubernetes es genérica. No obliga al dispositivo que recibe este recurso a utilizar ningún modelo de objetos ni método de implementación concretos. Describe qué debe estar presente, pero no condiciona en modo alguno cómo podría implementarlo.
Ser verdaderamente declarativo implica proporcionar los medios para comunicar la intención y el estado final deseado. En algún momento del futuro, bastará con decir: «Configura un servicio virtual para 'my-app'» y ¡voilà! Mediante metadatos, etiquetas de aplicaciones y un descubrimiento automatizado e inteligente, el servicio se configurará por completo de forma autónoma*.
Si alguna vez queremos alcanzar ese nirvana de un único plano de control, tendremos que ponernos manos a la obra y crear especificaciones declarativas neutrales que eliminen la necesidad de integrar cada dispositivo del centro de datos mediante una API imperativa. Porque la integración de API dispositivo por dispositivo no es, en realidad, muy distinta de la gestión dispositivo por dispositivo.
Queremos cosas buenas. Queremos un plano de control único y unificado. Pero, para conseguirlo, el sector tendrá que hacer algo más que asentir ante el enfoque declarativo y reconocer que si nadie más puede interpretar y utilizar tu interfaz declarativa, en realidad no es declarativa.
*Una chica puede soñar, ¿no?
Sobre el autor
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 VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.