Segundo a Wikipedia, Infrastructure as Code ou IaC é o processo de gerenciamento e provisionamento de centros de processamentos de dados usando arquivos de configuração em vez de configurações físicas de hardware ou ferramentas de configuração interativas. Numa linguagem mais fácil, IaC é o processo de gerenciar configurações e provisionamento usando arquivos de configurações pré-definidos. Utilizando o método IaC, um operador não mais conecta no servidor para utilizar o cli e executar comandos. Todas as definições precisam ser declaradas em arquivos texto antes do provisionamento.

No mundo de telecomunicações, tratamos como infraestrutura, todo e qualquer nó de rede necessário para prover acesso de rede ao usuário final. Quando falamos de redes móveis, esses nós, seguindo a terminologia 5G podem ser o AMF, SMF, UPF entre outros elementos especificados no 3GPP 23.501.

Atualmente, nós, os engenheiros de rede, seguimos um padrão legado de configuração através de uma abordagem imperativa. São criados documentos que descrevem métodos de procedimentos (MoP) servindo de base para a criação de scripts de configuração. Para executar uma mudança de configuração no elemento de rede, o engenheiro precisa se conectar ao nó e através da API fornecida pelo cli executar estes scripts.

Este método de configuração traz alguns problemas:

  • Necessário conhecimento da API cli de cada equipamento na rede
  • Necessário uma execução de testes pelo engenheiro para garantir o bom funcionamento da mudança planejada na MoP
  • Versionamento de MoPs

Alguns desses problemas podem ser resolvidos com ferramentas de automação, como é o caso do PyATS, uma ferramenta de automação de testes de rede. Outros, porém, são um pouco mais difíceis de resolver, como o caso de versionamento de MoPs que muitas vezes são escritas em documentos como .docx e precisam ser versionados manualmente, aumentando o risco de erro humano.

Além disso, caso um laboratório não esteja disponível para o engenheiro testar a MoP desenvolvida, tem-se o risco do script criado conter erros que não poderão ser corrigidos pelo executor da atividade.

Declarativo vs Imperativo

Geralmente, há duas abordagens para IaC: declarativa (funcional) vs. imperativa (procedural). A diferença entre a abordagem declarativa e a imperativa é essencialmente 'o quê' versus 'como', respectivamente. A abordagem declarativa concentra-se em qual deve ser a configuração no estado final; o imperativo se concentra em como a infraestrutura deve ser alterada para atender a isso. A abordagem declarativa define o estado desejado e o sistema executa o que precisa acontecer para atingir esse estado desejado. Imperativo define comandos específicos que precisam ser executados na ordem apropriada para terminar com a conclusão desejada.

Modelo Declarativo nas Telecomunicações

Essa não é uma questão simples, elementos de rede dificilmente possuem lógica suficiente para implementarmos o modelo declarativo. É importante entender que para fazer uso do modelo declarativo, é preciso implementar um backend que vá interpretar os arquivos declarativos e configurar o equipamento em questão. Quando falamos de equipamentos de telecomunicação, é incomum termos os fornecedores oferencendo tal nível de abstração na configuração, portanto ficamos muito dependentes do cli.

Isso não quer dizer, porém que o modelo declarativo não possa ser implementado no contexto de telecomunicações. Aliás, um movimento que a indústria tem feito, é adaptar as aplicações de rede ao modelo Cloud Native.

Cloud Native Function

Para quem é do mundo de telecom, o termo VNF significa Virtual Network Function, o qual em resumo se refere à implementação de uma função de rede como um roteador, de forma virtualizada e não dependente de um servidor físico com hardware especializado.

No mundo de containers, temos outro nome, ou sigla, desta vez chamada de CNF ou Cloud Native Function. Em vez de utilizarmos os modelos de virtualização através de máquinas virtuais, utilizamos containers usando tecnologias como Docker e Kubernetes e implementamos nossas funções de rede neste modelo de infraestrutura.

A principal vantagem da CNF é que o mundo Cloud Native está baseado, fortemente, no modelo declarativo, portanto, uma vez que os fornecedores de equipamentos comecem a realizar a migração de suas VNFs para CNFs, é muito provável que tenhamos uma adequação do cli ao YAML.

Em vez de usarmos linhas de comandos para aplicarmos configurações, escrevemos alguns arquivos YAML onde declaramos alguns valores e parâmetros. A partir daí uma lógica de backend irá implementar aquilo que desejamos.

Exemplo Imperativo vs Declarativo

Para fins ilustrativos, podemos comparar como implementar o protocolo BGP no modelo imperativo e no modelo declarativo. A seguir, fazemos essa comparação usando comandos fictícios.

Basicamente queremos criar uma sessão iBGP com o nó de rede cujo endereço é 192.168.1.2/30 e o AS é 65001.

Modelo Imperativo

Percebam que no exemplo abaixo precisamos primeiro conhecer quais comandos precisamos utilizar para chegarmos ao resultado final.

configurar bgp tipo iBGP
configurar bgp endereço-local as-number 65001
configurar bgp endereço-local 192.168.1.1/30
configurar bgp endereço-remoto 192.168.1.2/30
configurar bgp endereço-remoto as-number 65001

Modelo Declarativo

A principal diferença aqui, é que podemos apenas declarar os valores que precisamos para criar uma sessão BGP, sem qualquer conhecimento da linha de comando.

bgp:
    tipo: iBGP
    endereço-local:
        as-number: 65001
        endereço: 192.168.1.1/30
    endereço-remoto:
        as-number: 65001
        endereço: 192.168.1.2/30

Com esse modelo, basta criarmos um backend para cada tipo de roteador que tenhamos em nossas redes para que se possa traduzir o que está declarado em configuração.

Concluindo

Em resumo, quando usamos um modelo declarativo estamos abstraindo do operador o conhecimento necessário de linha de comando para implementar certas funcionalidades de rede. Estamos forçando uma separação entre declarar o estado final de uma aplicação e como fazer para chegar até esse estado final.

Ao separar essas lógicas, ou seja, a declaração do estado final e sua implementação, ganhamos agilidade no desenho de rede pois podemos confiar que o modelo de configuração será implementado por aquele que mais conhece o equipamento, o próprio desenvolvedor.

É possível ainda, ter um modelo híbrido, o qual eu acredito que será muito necessário nessa transição de paradigmas, entre o mundo virtualizado e o mundo containerizado. A equipe de engenharia responsável pelo desenho de rede pode criar seu próprio modelo declarativo, assim como fizemos em nosso exemplo.

Enquanto isso, a equipe de integração pode implementar a lógica que irá traduzir a declaração em configuração.

Nos próximos artigos desta série vamos explorar as ferramentas que podem ser utilizadas para implementar este modelo híbrido.