Por que um modelo declarativo é importante para a automação de NetOps?

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

Se você pretende automatizar tudo, vai querer adotar uma abordagem declarativa. Veja por quê.

Já faz algum tempo que insistimos na abordagem declarativa sempre que falamos de automação, especialmente no que diz respeito a NetOps e serviços de aplicações. Mas ainda não nos aprofundamos de fato nos motivos de sua importância nem em seus benefícios. Pretendo corrigir isso agora mesmo.

Para refrescar a memória, atualmente há dois modelos usados para automatizar a configuração e a implantação de, bem, tudo.

O primeiro é o modelo imperativo, no qual dizemos ao sistema de destino exatamente como fazer o que queremos. Se você já abriu um túnel SSH para um sistema e digitou um conjunto específico de comandos na CLI, então já utilizou o modelo imperativo de configuração.

A segunda (e preferida) é a declarativa, na qual informamos ao sistema de destino o que fazer, mas não como. Esse é o modelo adotado pela maioria das soluções de automação de redes por diversos motivos, sendo o principal deles o enorme custo e o tempo necessários para conhecer e integrar as centenas de possíveis dispositivos e sistemas que podem existir em um determinado ambiente.

Portanto, em um modelo imperativo, precisamos especificar cada comando (ou chamada de API) necessário para configurar um sistema. Em um modelo declarativo, geralmente apenas especificamos pares de chave-valor que descrevem o que queremos e deixamos que outro sistema cuide dos comandos necessários para concretizar isso.

Facinho, facinho.

Agora, para responder à pergunta sobre por que isso é importante: há quatro benefícios principais em adotar um modelo declarativo ao começar a automatizar tudo.

1. Reduza o erro humano

Sabemos que cerca de 22% dos incidentes de indisponibilidade em produção ocorrem devido a erros humanos. Alguns incidentes de grande repercussão, que não vou abordar novamente, foram diretamente atribuídos a simples erros humanos. Em um modelo imperativo baseado em chamadas de API, cada uma delas representa um possível incidente prestes a acontecer. Se você não verificar uma variável, esquecer de conferir um código de erro ou deixar passar qualquer um de inúmeros outros cenários possíveis, poderá acabar tendo que procurar outro emprego. Isso é péssimo.

Um modelo declarativo se baseia em algum tipo de modelo ou arquivo de configuração, que será analisado e validado antes que chamadas de API sejam usadas para executá-lo. Embora ainda seja possível cometer erros em um arquivo de configuração ou modelo, as chances de isso acontecer são menores, pois você reduz a quantidade de código necessária. E menos código geralmente significa menos oportunidades de cometer erros.

2. Reduza a dívida técnica

Dívida técnica é aquela metáfora divertida que herdamos do desenvolvimento e que nos lembra do custo de longo prazo das nossas escolhas. A dívida técnica se acumula de várias maneiras com os modelos imperativos. Primeiro, há o acoplamento dos scripts à API do nosso sistema de destino. É pouco provável que essa API seja compatível com qualquer outra coisa, o que significa que estamos desenvolvendo scripts específicos para cada sistema. As etapas de configuração também provavelmente variam de um aplicativo para outro — nem tudo usa HTTP, e nem todo aplicativo baseado em HTTP exige exatamente a mesma configuração de serviço. Portanto, agora estamos criando scripts específicos para cada aplicativo e cada sistema. São muitos scripts e muita dívida acumulada em decorrência dessa escolha.

Por outro lado, um método declarativo pode usar o mesmo script e sistema para o processo de implantação. Embora o modelo ou a configuração provavelmente ainda sejam específicos para cada aplicação e sistema, trata-se de um único arquivo. Isso elimina a complexidade e reduz a quantidade de scripts, diminuindo drasticamente a dívida técnica. Na prática, nossas escolhas sempre gerarão algum nível de dívida; o objetivo é minimizá-la.

3. Elimine conflitos de versão

Quando você vincula seus processos de configuração e implantação a uma API, fica preso à versão específica dessa API. Há muitas comunidades na Internet repletas de desenvolvedores hostis e irritados reclamando das mudanças em uma API e do trabalho necessário para adaptar seus aplicativos. O mesmo pode (e vai) acontecer com serviços de rede e de aplicativos. Portanto, se você estiver preso a uma versão da API e algo mudar, adivinhe só? Você vai passar uma eternidade atualizando (ou talvez reescrevendo) scripts*.

Mas, se você adotou um modelo declarativo, provavelmente poderá ignorar quaisquer alterações na API. Afinal, você não está usando a API para dizer ao sistema como implantar um serviço; está apenas dizendo a ele o que precisa ser implantado.

4. Reduza os requisitos de conhecimento especializado no domínio

Vamos ser francos: se eu for usar uma API para um serviço de rede ou de aplicação, preciso entender o sistema. Se você não sabe a diferença entre um IP virtual e um servidor virtual, bem, já está em apuros — e mal começamos a falar sobre a diferença entre nós e membros. Métodos imperativos baseados em API exigem que você conheça o sistema de destino o suficiente para navegar por sua configuração.

Ao usar um modelo declarativo, é necessário ter menos conhecimento especializado sobre o sistema de destino, o que aumenta a probabilidade de que tanto os desenvolvedores quanto as equipes de DevOps consigam usar o método para disponibilizar aplicações por autoatendimento. É claro que especialistas ainda serão necessários, mas as exigências sobre os consumidores dos serviços são reduzidas, e a responsabilidade pelo provisionamento e pela implantação é distribuída entre um grupo mais amplo de partes interessadas.

Há outros motivos para adotar um modelo declarativo em suas iniciativas de automação de NetOps, mas esses quatro são os mais convincentes. Isso porque eles beneficiam as equipes de NetOps, a empresa e o número cada vez maior de usuários que precisam de acesso por autoatendimento aos serviços de rede e de aplicações que tornam os aplicativos mais rápidos e seguros.

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