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

Se você vai automatizar todas as coisas, você vai querer ser declarativo. Aqui está o porquê.

Já faz algum tempo que falamos sobre automação, principalmente com relação a NetOps e serviços de aplicativos. Mas realmente não investigamos por que isso é importante e quais são os benefícios. Pretendo corrigir isso agora mesmo.

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

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

O segundo (e preferido) é declarativo, no qual dizemos ao sistema de destino o que fazer, mas não como. Este é o modelo adotado pela maioria das soluções de automação de rede por uma série de razões, sendo a mais importante o alto custo e o tempo necessários para aprender e integrar as centenas de possíveis dispositivos e sistemas que podem estar em um determinado ambiente.

Então, em um modelo imperativo, temos que especificar cada comando (ou chamada de API) necessária para configurar um sistema. Em um modelo declarativo, nós apenas especificamos pares chave-valor (geralmente) que descrevem o que queremos e deixamos outro sistema se preocupar com os comandos para fazer isso acontecer.

Fácil, fácil como um limão.

Agora vamos responder à pergunta sobre por que isso é importante. Há quatro benefícios principais em adotar um modelo declarativo quando você está migrando para automatizar todas as coisas.

1. Reduzir o erro humano

Sabemos que cerca de 22% dos incidentes de interrupção na produção ocorrem devido a erro humano. Alguns incidentes de grande repercussão, que não vou discutir novamente, foram diretamente atribuídos a simples erro humano. Em um modelo imperativo, baseado em chamadas de API, cada uma delas é um incidente potencial esperando para acontecer. Se você não verificou uma variável, ou esqueceu de verificar um código de erro, ou uma centena de outros cenários possíveis, você pode experimentar um evento gerador de currículo. Isso é uma coisa ruim.

Um modelo declarativo é baseado em um modelo ou arquivo de configuração de algum tipo que será analisado e validado antes que chamadas de API sejam usadas para execução nele. Embora você certamente ainda possa bagunçar um arquivo de configuração ou modelo, as oportunidades de fazer isso são limitadas porque você está reduzindo o código necessário. E menos código geralmente significa menos oportunidades de cometer erros.

2. Reduzir a dívida técnica

Dívida técnica é aquela metáfora divertida que aprendemos no desenvolvimento e que nos lembra do custo de longo prazo de nossas escolhas. A dívida técnica aumenta com modelos imperativos de diversas maneiras. Primeiro, há o acoplamento dos scripts à API do nosso sistema de destino. É improvável que essa API suporte mais nada , o que significa que estamos desenvolvendo scripts por sistema. As etapas de configuração também provavelmente variam de aplicativo para aplicativo – nem tudo é HTTP, e nem todo aplicativo baseado em HTTP requer exatamente a mesma configuração de serviço. Então agora estamos criando scripts por aplicativo e por sistema. São muitos roteiros e muitas dívidas se acumulando com base nessa escolha.

Por outro lado, um método declarativo pode usar o mesmo script e sistema de processo de implantação. Embora o modelo/configuração provavelmente ainda seja específico do aplicativo e do sistema, é um único arquivo. Ele elimina a complexidade e o número de scripts e, portanto, reduz drasticamente a dívida técnica. A realidade é que sempre haverá alguma dívida contraída por nossas escolhas; minimizá-la é o objetivo. 

3. Elimine conflitos de versão

Quando você vincula seus processos de configuração e implantação a uma API, você está vinculado a essa versão da API. Há muitas comunidades na Internet com desenvolvedores hostis e irritados falando sobre mudanças em uma API e o trabalho necessário para alterar seu aplicativo. A mesma coisa pode (e vai) acontecer com serviços de rede e aplicativos. Então, se você estiver vinculado a uma versão da API e algo mudar, adivinhe? Você vai atualizar (ou talvez reescrever) roteiros até cansar*.

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

4. Reduzir os requisitos de especialização em domínio

Sejamos realistas, se vou usar uma API para um serviço de rede ou aplicativo, preciso entender o sistema. Se você não sabe a diferença entre um IP virtual e um servidor virtual, bem, você já está em apuros e mal chegamos à questão de nós versus membros. Métodos imperativos baseados em API exigem que você entenda o sistema de destino bem o suficiente para navegar em sua configuração.

Usando um modelo declarativo, você precisa de menos experiência no sistema de destino, o que significa que tanto os desenvolvedores quanto os DevOps têm mais probabilidade de usar o método para aplicativos de autoatendimento. Você ainda precisará de especialistas, é claro, mas as demandas sobre os consumidores dos serviços são reduzidas e distribuem o fardo do provisionamento e da implantação entre um conjunto mais amplo de constituintes.

Existem outros motivos pelos quais você deseja adotar um modelo declarativo para seus esforços de automação de NetOps, mas esses quatro são os mais atraentes. Isso ocorre porque eles beneficiam a NetOps, os negócios e os constituintes em expansão que precisam de acesso self-service à rede e aos serviços de aplicativos que tornam os aplicativos mais rápidos e seguros.