No mundo dos contêineres, a configuração declarativa é soberana

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

A transformação digital interna é essencial para viabilizar a transformação digital externa. Um dos componentes fundamentais da transformação digital interna é a automação, que depende fortemente do plano de controle. É no plano de controle que a automação acontece. Nos primórdios da computação, nós o chamávamos de “rede de gerenciamento” e usávamos protocolos como o SNMP para realizar monitoramento, configuração e controle.

Hoje, a rede de gerenciamento ainda existe, pelo menos em teoria, como o meio pelo qual realizamos as mesmas tarefas por meio do plano de controle. O plano de controle é um ambiente complexo, repleto de APIs, nós mestres e até mesmo filas de mensagens, que permitem que componentes individuais de um sistema distribuído complexo gerenciem a si próprios de forma (quase) automática. Ele é cada vez mais orientado a eventos, o que exige uma mudança de mentalidade em relação aos modelos centralizados de comando e controle do passado, que se baseavam principalmente em modelos imperativos de gerenciamento. Ou seja, um sistema central instrui implicitamente os componentes por meio de chamadas de API específicas que provocam mudanças. Os ambientes atuais, por outro lado, baseiam-se em modelos declarativos que distribuem a responsabilidade de realizar mudanças em si próprios.

Em nenhum sistema isso é mais evidente do que em ambientes conteinerizados. Vistos de fora, esses sistemas parecem operar quase sem controle: mensagens e eventos são publicados e disparados indiscriminadamente, sem uma autoridade central para determinar quem ou o que deve reagir a eles. O plano de controle já não diz respeito tanto ao controle, mas à distribuição por um plano que se assemelha mais a uma malha do que às arquiteturas hub-and-spoke dos sistemas de gerenciamento arcaicos. No mundo tradicional, usávamos APIs e protocolos para enviar alterações aos componentes. No mundo digital e conteinerizado, usamos APIs para obter as informações necessárias para que um componente se modifique por conta própria.

Esse novo mundo é reativo e deixa de lado o modelo imperativo (orientado por APIs) do plano de controle tradicional, adotando, em vez disso, um modelo declarativo e mais aberto para alcançar o estado final automatizado desejado.

Isso não é de surpreender. À medida que adotamos cada vez mais uma abordagem orientada por software para tudo (sob a égide de DevOps, Cloud e NFV), também tivemos que lidar com uma enorme escala operacional. Um modelo de gerenciamento imperativo do tipo hub-and-spoke não escala de forma eficiente, pois a responsabilidade por todas as alterações recai sobre um controlador central, capaz de se comunicar por meio de uma variedade confusa de APIs com um conjunto praticamente ilimitado de componentes. Esse é um modelo de “push”, no qual o gerenciador (controlador) envia alterações a cada componente afetado. Ele se torna o gargalo que determina o sucesso ou o fracasso de todo o sistema.

Um modelo orientado a eventos, baseado na obtenção de dados pelos componentes, é necessário para ganhar escala e aliviar a carga sobre o controlador. Isso, por sua vez, exige que os componentes que desejam participar desse plano de controle estejam preparados para trabalhar com um modelo de configuração declarativa. Isso porque, em vez de enviar alterações por meio de uma API (abordagem imperativa), os contêineres estão nos levando a obter as alterações por meio de configurações declarativas. Cabe aos fornecedores de componentes (sejam eles de código aberto ou comerciais) inscrever-se corretamente para receber as alterações e, em seguida, obter as informações necessárias para implementá-las imediatamente.

Se isso parece infraestrutura como código, é porque é mesmo. Configurações declarativas são basicamente código ou, pelo menos, artefatos de código. A automação depende cada vez mais da premissa de desacoplar a configuração do serviço. Em um modelo utópico ideal, essas configurações declarativas seriam completamente agnósticas. Ou seja, poderiam ser interpretadas por qualquer produto, de qualquer fornecedor (comercial ou de código aberto), que oferecesse suporte a esse serviço. Por exemplo, uma configuração declarativa que descrevesse o serviço apropriado (servidor virtual) e os aplicativos que compõem seu conjunto de recursos poderia ser processada e implementada pelo serviço X ou pelo serviço Y.

Os arquivos de recursos do Kubernetes são um bom exemplo de um modelo de configuração declarativa no qual se descreve o que se deseja, mas em nenhum momento se determina como fazê-lo. Isso é muito diferente dos sistemas que dependem de APIs de infraestrutura e exigem que a implementação conheça – às vezes profundamente – como alcançar os resultados desejados.

O modelo declarativo também permite tratar a infraestrutura como gado. Se uma instância falhar, basta eliminá-la e iniciar uma nova. Toda a configuração necessária está no arquivo de recursos; não há um botão “salve seu trabalho ou ele será perdido”, pois não há trabalho a perder. Isso é quase imutável e, sem dúvida, constitui uma infraestrutura descartável — algo essencial em sistemas que mudam a cada minuto, ou até mesmo a cada segundo, para minimizar o impacto de falhas.

À medida que avançamos cada vez mais em direção a sistemas automatizados de escala e — ouso dizer? — segurança, precisaremos adotar modelos declarativos para gerenciar a infinidade de dispositivos e serviços que compõem o caminho de dados da aplicação, sob o risco de sermos soterrados por uma avalanche de dívida operacional decorrente de métodos manuais de integração e automação.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie