As APIs são a nova CLI. Mas, quando se trata do tipo de API que você está criando, a abordagem declarativa é soberana.
Uma API — uma interface de programação de aplicações — é um recurso essencial atualmente. As organizações as utilizam na camada de negócios para promover a integração com parceiros e a inovação por parte dos chamados "desenvolvedores cidadãos". As aplicações as utilizam para facilitar a integração e desacoplar a lógica de negócios — que pode mudar com frequência — das interfaces — que não deveriam mudar com tanta frequência. E a infraestrutura também conta com elas. De switches a roteadores, de serviços de aplicações a middleware e bancos de dados, a infraestrutura que compõe os pipelines de entrega e implantação é habilitada por APIs.
Isso, por si só, já deveria ser motivo para parar e refletir sobre o que significa para a emergente comunidade de NetOps. Isso porque, embora as organizações tendam a padronizar alguns componentes essenciais da infraestrutura de aplicações, é menos provável que façam o mesmo com apenas alguns componentes essenciais da infraestrutura de rede e de serviços de aplicações.
Dos, em média, dezesseis serviços de aplicativos diferentes que as organizações usam para tornar seus aplicativos mais rápidos e seguros, é certo que eles são fornecidos por mais do que apenas alguns componentes de infraestrutura. Se assumirmos, de forma generosa, uma proporção de três serviços de aplicativos por componente, ainda teremos cinco dispositivos diferentes — com cinco APIs diferentes.
O problema é que, muitas vezes, os provedores de infraestrutura interpretaram a afirmação "A API é a nova CLI" de forma literal demais. Ou seja, a API é apenas um reflexo da CLI com suporte a REST.
Qualquer pessoa que já tenha trabalhado com CLIs em diferentes componentes de infraestrutura sabe que a navegação pela CLI corresponde de forma muito próxima ao modelo de objetos da infraestrutura. Muitas vezes, as APIs não fazem mais do que simplesmente transferir esse design para HTTP. Isso significa que quem tenta aproveitar a API também precisa, necessariamente, aprender o modelo de objetos do dispositivo em questão.
Esse nível de abstração está dificultando o avanço da automação e da orquestração, pois agora precisamos encontrar não apenas profissionais de automação, mas profissionais que também tenham algum grau de experiência em cinco ou mais modelos distintos de infraestrutura de rede. O nível de especialização exigido muitas vezes também requer conhecimento do domínio, abrangendo desde noções básicas de configuração de VLAN e roteamento até as relações entre servidores virtuais, endereços IP virtuais, nós, membros e pools.
Expor a complexidade subjacente da infraestrutura prejudica a adoção e a viabilização da automação. O objetivo das interfaces deve ser abstrair os modelos e a lógica para proteger usuários e operadores dessa complexidade. A interface gráfica faz isso ao eliminar 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 de aplicações. Por exemplo, a MuleSoft, em sua pesquisa "O valor crescente das APIs", constatou que a principal demanda — apontada por 47% dos entrevistados — de clientes e parceiros em relação à integração de APIs era por "APIs personalizadas que atendam a uma necessidade específica do negócio". Em seguida, vieram uma documentação melhor (19%), modelos de integração "sem código" (19%) e wrappers de SDK para as APIs de que precisam e que utilizam (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 central deste post: as interfaces declarativas são essa abstração. Ao simplificar as interfaces usadas atualmente para provisionar, configurar, gerenciar e integrar a infraestrutura, as interfaces declarativas democratizam a infraestrutura e criam novas oportunidades.
Declarativo versus imperativo
De modo geral, tanto as APIs declarativas quanto as imperativas podem ser consideradas tipos de API. As APIs imperativas são aquelas em que você pensa quando alguém fala em API. Elas informam ao sistema de destino exatamente como fazer algo. Se você pretende adicionar um servidor virtual, deverá informar exatamente como fazer isso — mesmo que sejam necessárias cinco, dez ou mais chamadas de API separadas.
Isso significa instruí-lo a criar um objeto específico com os atributos apropriados, como um nó com um endereço IP. Depois, você precisa instruir separadamente o sistema a criar, com um nome, o pool ao qual ele será atribuído. Em seguida, você precisa... bem, a esta altura já deu para entender. As APIs imperativas exigem que o usuário compreenda não apenas o sistema e seu modelo de objetos, mas também as etapas necessárias para alcançar os resultados pretendidos.
Esse é o preço que se paga por usar uma API imperativa.
De modo geral, APIs imperativas não são algo ruim. Elas são muito importantes quando você está criando uma interface gráfica ou fazendo a integração com outros sistemas que precisam do nível de granularidade oferecido por uma API imperativa. Também precisamos de APIs imperativas, mas não para automação e integração voltadas a NetOps e DevOps.
Mas, para o restante de nós, não é necessário conhecer esse nível de detalhe. Na verdade, exigir um conhecimento tão aprofundado pode ser desestimulante e atrasar os esforços de automação e orquestração. Isso certamente não contribui para democratizar a infraestrutura nem para viabilizar modelos de autoatendimento para DevOps e desenvolvedores, muito menos para NetOps fora do domínio específico da infraestrutura.
É aí que entram as APIs declarativas.
As interfaces declarativas especificam o que você deseja fazer e deixam que o sistema determine a lógica e o fluxo de trabalho. Portanto, em vez de instruir especificamente o sistema a criar um nó e um pool e executar toda a lógica adequada nos objetos necessários, você descreve esses objetos e as relações entre eles.
Algumas interfaces declarativas usam JSON, outras usam XML, e algumas ainda recorrem a simples dados de formulário. O que todas elas têm em comum é a premissa de que os dados descrevem os objetos de maneira simples e direta, exigindo pouquíssimo conhecimento sobre modelos de objetos e hierarquias de sistemas.
Por exemplo, esta declaração é bastante legível para seres humanos. Ela pressupõe um nível básico de compreensão do modelo de objetos, mas não a ponto de exigir uma certificação em um produto específico para escrevê-la:
"web_pool": { "class": "Pool", "monitors": [ "http" ], "members": [ { "servicePort": 80, "serverAddresses": [ "192.0.1.10", "192.0.1.11" ] } ] }
É aqui que o valor das interfaces declarativas se torna evidente: na redução do conhecimento específico necessário e da complexidade do provisionamento e da configuração da infraestrutura. Ao reduzir o nível de especialização exigido, as equipes de NetOps não só podem trabalhar com mais rapidez e eficiência, como também podem incentivar as equipes de DevOps e os desenvolvedores a aproveitar esse recurso.
A adoção de interfaces declarativas como método padrão de gerenciamento da infraestrutura amplia imediatamente o conjunto de talentos com os quais você pode contar para oferecer recursos de autoatendimento e automação avançada. A interface declarativa acima requer pouquíssima explicação para que as equipes de DevOps e os desenvolvedores possam compreendê-la e utilizá-la. Por outro lado, uma interface imperativa exigiria muito mais dedicação ao aprendizado do modelo e dos fluxos de trabalho específicos da infraestrutura antes que fosse possível obter resultados.
As 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 a outros serviços de infraestrutura. E democratizar a infraestrutura significa uma automação mais rápida e inteligente, além da capacidade de incentivar a colaboração e a cooperação entre domínios operacionais, necessárias para aproveitar os benefícios dos movimentos de NetOps e DevOps.
Sobre o autor
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 VittiePublicações relacionadas no blog
O estado da maturidade digital empresarial: a transformação digital ainda não terminou
Explore como a IA impacta as empresas, as aplicações da IA generativa, as estratégias para modernizar as operações de TI e os benefícios da maturidade digital com a F5.
Como a IA generativa acelera a transformação digital
Veja como a IA generativa impulsiona a transformação digital nas empresas, acelerando tendências como a integração de APIs, os desafios dos modelos operacionais de TI híbrida e a adoção de AIOps.
Seis capacidades técnicas para acelerar a transformação digital
As arquiteturas empresariais atuais carecem dos fatores necessários de agilidade, escalabilidade, segurança e observabilidade, essenciais para impulsionar a mudança tecnológica. No entanto, estas seis capacidades fundamentais ajudarão as empresas a gerenciar riscos e desafios ao longo de sua transformação digital.
Inverter a API é a transformação digital de que as empresas precisam para participar e competir em uma economia de APIs
As organizações detêm um valor latente — na forma de APIs internas — que precisam explorar para competir em uma economia de APIs. Embora os desafios técnicos e de segurança possam desestimular algumas delas, as empresas precisam reconhecer que inverter suas APIs permitirá liberar o valor da organização como plataforma.
A modernização da TI começa pela infraestrutura
O hardware e o software evoluíram rapidamente desde os primórdios da internet, mas, para aproveitar ao máximo os benefícios resultantes dessa evolução, as organizações precisam avaliar e modernizar sua infraestrutura e a entrega de aplicativos. Acelere os esforços de modernização com a nova F5 rSeries.