Como as interfaces declarativas democratizam a infraestrutura

APIs são a nova CLI. Mas a declarativa manda quando se trata de que tipo de API você está construindo.

Uma API (interface de programação de aplicativos) é um recurso essencial hoje em dia. As organizações os têm na camada de negócios, para promover a integração de parceiros e a inovação pelos chamados "desenvolvedores cidadãos". Os aplicativos os possuem para facilitar a integração e desacoplar a lógica de negócios — que pode mudar com frequência — das interfaces — que não devem mudar com tanta frequência. E a infraestrutura os tem. De switches a roteadores, de serviços de aplicativos a middleware e bancos de dados, a infraestrutura que compõe os pipelines de entrega e implantação é habilitada com APIs.

Isso, por si só, deveria ser motivo para parar e refletir sobre o que isso significa para a comunidade NetOps emergente. Porque, embora as organizações tendam a padronizar alguns componentes-chave de infraestrutura de aplicativos, elas não têm tanta probabilidade de padronizar apenas alguns componentes-chave de infraestrutura de serviços de rede e aplicativos.

Dos dezesseis serviços de aplicativos diferentes que as organizações usam em média para tornar seus aplicativos mais rápidos e seguros, é certo que eles são fornecidos por mais do que um punhado de componentes de infraestrutura. Se assumirmos generosamente que a proporção é de três serviços de aplicativos por componente, ainda assim são cinco dispositivos diferentes, com cinco APIs diferentes.

O problema com isso é que muitas vezes os provedores de infraestrutura levam a afirmação "A API é a nova CLI" um pouco ao pé da letra. Ou seja, a API é apenas um reflexo da CLI habilitado para REST.

Qualquer pessoa que tenha trabalhado com CLIs em componentes de infraestrutura entende que a navegação CLI mapeia muito de perto o modelo de objeto da infraestrutura. As APIs muitas vezes não conseguem fazer mais do que migrar esse design para HTTP. O que significa que aqueles que tentam tirar proveito da API devem necessariamente aprender também o modelo de objeto do dispositivo em questão.

Esse nível de abstração está impedindo o avanço da automação e da orquestração, porque agora precisamos encontrar não apenas talentos em automação, mas talentos em automação com algum grau de especialização em cinco ou mais modelos diferentes de infraestrutura de rede. O nível de especialização exigido muitas vezes também exige conhecimento de domínio, abrangendo desde uma compreensão rudimentar da configuração e roteamento de VLAN até os relacionamentos entre servidores virtuais, endereços IP virtuais, nós, membros e pools.

Expor a complexidade subjacente da infraestrutura é prejudicial para incentivar a adoção e permitir a automação. O objetivo das interfaces deve ser abstrair os modelos e a lógica para proteger usuários e operadores de sua complexidade. A GUI faz isso eliminando a necessidade de navegar por hierarquias de objetos para configurar um serviço simples.

É por isso que muitas vezes é frustrante descobrir que a API reintroduziu esse pesadelo de navegação.

Esse problema não é exclusivo da infraestrutura de rede e aplicativos.  A saber, a MuleSoft, em sua pesquisa " O valor crescente das APIs ", descobriu que a maior demanda - 47% dos entrevistados - de clientes e parceiros para integração de API eram "APIs personalizadas que atendessem a uma necessidade comercial específica". Atrás disso, veio uma melhor documentação (19%), modelos de integração "sem código" (19%) e wrappers de SDK para APIs que eles precisam e usam (13%).

Tudo isso pode ser resumido como um apelo à simplificação. E em tecnologia, simplificação significa abstração.

E isso nos leva ao ponto deste post, que é que interfaces declarativas são essa abstração. Ao simplificar as interfaces usadas para provisionar, configurar, gerenciar e integrar a infraestrutura hoje, as interfaces declarativas democratizam a infraestrutura e abrem oportunidades. 

Declarativo versus Imperativo

Em termos gerais, tanto declarativas quanto imperativas podem ser consideradas tipos de APIs. APIs imperativas são aquelas que você pensa quando alguém diz API. Elas dizem ao sistema de destino exatamente como fazer algo. Se você for adicionar um servidor virtual, você dirá a ele exatamente como fazer isso, mesmo que isso exija cinco, dez ou mais chamadas de API separadas.

Isso significa dizer para ele criar um objeto específico com os atributos apropriados, digamos, um nó com um endereço IP. Depois, você precisa informar separadamente ao sistema para criar o pool ao qual ele será atribuído, com um nome. Então você tem que... bem, você já entendeu. APIs imperativas impõem ao usuário a responsabilidade não apenas de entender o sistema e seu modelo de objeto, mas também as etapas necessárias para atingir os resultados pretendidos.

Esse é o imposto da API que você paga com imperativo.

Agora, APIs imperativas não são algo ruim no geral. Elas são muito importantes quando você está construindo uma GUI ou integrando com outros sistemas que precisam do tipo de granularidade que você obtém com uma API imperativa. Precisamos de APIs imperativas também, mas não para NetOps e DevOps voltados para automação e integração.

Mas o resto de nós não precisa saber esse nível de detalhes. E, de fato, exigir essa profundidade de conhecimento pode ser desanimador e retardar os esforços de automação e orquestração. Certamente não se presta a democratizar a infraestrutura e habilitar modelos de autoatendimento para DevOps e desenvolvedores, muito menos NetOps fora do domínio específico da infraestrutura.

É aí que as APIs declarativas entram em cena.

Interfaces declarativas especificam o que você quer fazer e deixam a lógica e o fluxo de trabalho para o sistema descobrir. Então, em vez de dizer especificamente ao sistema para criar um nó e um pool e executar toda a lógica correta nos objetos necessários, você os descreve e seus relacionamentos.

Algumas interfaces declarativas usam JSON, outras XML e algumas ainda recorrem a dados de formulário simples. O que todos eles têm em comum é que assumem que os dados descrevem os objetos de uma forma simples e direta, que exige muito pouco entendimento de modelos de objetos e hierarquias de sistemas.

Por exemplo, esta declaração é bastante legível para humanos. Ele pressupõe um nível básico de compreensão do modelo de objeto, mas não tanto a ponto de exigir uma certificação em um produto específico para escrever a declaração: 

"web_pool": {
"classe": "Pool",
"monitores": [
"http"
],
"membros": [
{
"servicePort": 80,
"endereços do servidor": [
"192.0.1.10",
"192.0.1.11"
]
}
]
}

É aqui que o valor das interfaces declarativas se torna evidente: na redução do conhecimento de domínio e da complexidade do provisionamento e configuração da infraestrutura. Ao reduzir o nível de especialização necessário, o NetOps não só pode trabalhar de forma mais rápida e eficiente, como também pode incentivar o DevOps e os desenvolvedores a aproveitar essa capacidade.

Adotar interfaces declarativas como um método padrão de gerenciamento de infraestrutura amplia imediatamente o conjunto de talentos dos quais você pode tirar proveito para fornecer recursos de autoatendimento e automação avançada. A interface declarativa acima precisa de muito pouca explicação para que DevOps e desenvolvedores entendam e consigam usar. Por outro lado, uma interface imperativa exigiria muito mais atenção ao aprendizado do modelo e dos fluxos de trabalho específicos da infraestrutura antes que os resultados pudessem ser esperados.

Interfaces declarativas democratizam a infraestrutura ao simplificar o provisionamento, a configuração e o gerenciamento necessários para automatizar pipelines de implantação e integrar sistemas com outros serviços de infraestrutura. E democratizar a infraestrutura significa automação mais rápida e inteligente e a capacidade de incentivar a colaboração e a cooperação entre domínios operacionais necessários para obter benefícios dos movimentos NetOps e DevOps.