En el mundo de los contenedores, la configuración declarativa es la reina

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

La transformación digital interna es fundamental para hacer posible la transformación digital externa. Uno de los componentes esenciales de la transformación digital interna es la automatización, que depende en gran medida del plano de control. El plano de control es donde se lleva a cabo la automatización. En los primeros tiempos de la informática, lo denominábamos «red de gestión» y utilizábamos protocolos como SNMP para realizar tareas de supervisión, configuración y control.

Hoy en día, la red de gestión sigue existiendo, al menos en teoría, como el medio a través del cual realizamos las mismas tareas mediante el plano de control. El plano de control es un entorno complejo de API, nodos maestros e incluso colas de mensajes que permiten que los componentes individuales de un sistema distribuido complejo se gestionen a sí mismos de forma (casi) automática. Cada vez está más orientado a eventos, lo que exige un cambio de mentalidad con respecto a los modelos centralizados de mando y control del pasado, que se basaban principalmente en modelos de gestión imperativos. Es decir, un sistema central da instrucciones implícitas a los componentes mediante llamadas específicas a API que provocan cambios. Los entornos actuales, en cambio, se basan en modelos declarativos que distribuyen entre los componentes la responsabilidad de modificarse a sí mismos.

En ningún sistema resulta esto más evidente que en los entornos de contenedores. Vistos desde fuera, estos sistemas parecen funcionar casi por libre: los mensajes y eventos se publican y se lanzan sin orden ni concierto, sin una autoridad superior que determine quién o qué debe reaccionar ante ellos. El plano de control ya no tiene tanto que ver con el control como con la distribución a través de un plano que se asemeja más a una malla que a las arquitecturas radiales de los sistemas de gestión obsoletos. En el mundo tradicional utilizábamos APIs y protocolos para enviar cambios a los componentes. En el mundo digital y basado en contenedores, utilizamos APIs para obtener la información necesaria para que un componente se modifique a sí mismo.

Este nuevo mundo es reactivo y prescinde del modelo imperativo (basado en API) del plano de control tradicional, apostando en su lugar por un modelo declarativo y más abierto para alcanzar el estado final automatizado deseado.

No es de extrañar. A medida que hemos ido adoptando cada vez más un enfoque basado en software para todo (bajo el paraguas de DevOps, la nube y la NFV), también hemos tenido que hacer frente a una enorme escala operativa. Un modelo de gestión imperativo de tipo hub-and-spoke no escala de forma eficiente, ya que la responsabilidad de todos los cambios recae en un controlador central capaz de comunicarse, mediante un desconcertante conjunto de API, con un grupo prácticamente ilimitado de componentes. Se trata de un modelo «push», en el que el gestor (controlador) envía los cambios a cada componente afectado. Este se convierte en el cuello de botella que determina el éxito o el fracaso de todo el sistema.

Para poder escalar y aliviar la carga del controlador, es necesario un modelo basado en eventos en el que los componentes obtengan los cambios. Esto, a su vez, exige que los componentes que deseen participar en este plano de control sean compatibles con un modelo de configuración declarativa. En lugar de enviar los cambios mediante una API (modelo imperativo), los contenedores nos llevan a obtenerlos mediante configuraciones declarativas. Corresponde a los proveedores de componentes (ya sean de código abierto o comerciales) suscribirse correctamente a los cambios y obtener después la información necesaria para aplicarlos de inmediato.

Si esto suena a infraestructura como código, es porque así debe ser. Las configuraciones declarativas son básicamente código o, al menos, artefactos de código. La automatización depende cada vez más de esta premisa, que desvincula la configuración del servicio. En un modelo utópico ideal, estas configuraciones declarativas serían completamente independientes. Es decir, cualquier producto de cualquier proveedor (comercial o de código abierto) compatible con ese servicio podría interpretarlas. Por ejemplo, una configuración declarativa que describiera el servicio adecuado (servidor virtual) y las aplicaciones que componen su conjunto de recursos podría ser procesada e implementada por el servicio X o el servicio Y.

Los archivos de recursos de Kubernetes son un buen ejemplo de un modelo de configuración declarativa en el que se describe qué se desea, pero en ningún momento se especifica cómo conseguirlo. Esto difiere notablemente de los sistemas que dependen de API de infraestructura y que requieren que la implementación conozca —a veces en profundidad— cómo lograr los resultados deseados.

El modelo declarativo también permite tratar la infraestructura como ganado. Si un elemento falla, basta con eliminarlo e iniciar una nueva instancia. Toda la configuración que necesita se encuentra en el archivo de recursos; no hay ningún botón de «guarda tu trabajo o se perderá», porque no hay ningún trabajo que perder. Se trata de una infraestructura prácticamente inmutable y, sin duda, desechable, algo imprescindible en sistemas que cambian cada minuto, si no cada segundo, para minimizar el impacto de los fallos.

A medida que avanzamos cada vez más hacia sistemas automatizados a gran escala y —¿me atrevo a sugerirlo?— seguros, tendremos que adoptar modelos declarativos para gestionar la infinidad de dispositivos y servicios que conforman la ruta de datos de las aplicaciones, o correremos el riesgo de quedar sepultados bajo una avalancha de deuda operativa derivada de métodos manuales de integración y automatización.

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