
É época de declarar o imposto de renda nos EUA, e você sabe o que isso significa, não é? Sim, todos estamos procurando maneiras de reduzir esse peso.
Lamento dizer que, embora eu já tenha trabalhado como desenvolvedor em uma empresa de software tributário, não tenho qualificação para dar conselhos sobre esse assunto. Mas, se você está procurando dicas sobre como evitar pagar os impostos das APIs neste ano (ou no próximo), então chegou à página certa da Internet.
Um imposto de API é o custo adicional que você paga ao usar APIs para automatizar o provisionamento e a configuração da infraestrutura como parte do processo de implantação. O imposto de API (como todos os impostos) não é simples de calcular, pois, na verdade, tem duas dimensões: operacional e técnica.
Do ponto de vista operacional, o imposto de API gera custos em termos de recursos e tempo consumidos por chamadas excessivas à API. Até mesmo algo conceitualmente simples, como um serviço de balanceamento de carga, exige a criação, a configuração e a habilitação de vários objetos. Monitoramento, pools, algoritmos, endereços IP e atributos de rede precisam ser configurados, e cada um desses objetos requer várias etapas (chamadas à API) para isso. Somando tudo, até mesmo um serviço simples de balanceamento de carga exige várias chamadas à API para começar a funcionar. Chamadas que levam tempo para serem executadas. Chamadas que consomem recursos de rede.
Essas chamadas de API são usadas por arquitetos e engenheiros que escrevem scripts (usando Python, PowerShell etc.) para automatizar essas tarefas comuns de implantação. Isso gera uma dívida técnica inevitável. Qualquer alteração na tarefa exige modificar o código (porque scripts são código, quer gostemos de admitir ou não) e testá-lo, o que demanda tempo e recursos que se traduzem em custos reais para o resultado financeiro.
Esses custos — para desenvolver, testar e manter os sistemas e scripts — são os encargos técnicos decorrentes do uso dessa API. Isso significa que os scripts geram custos de longo prazo na forma de dívida técnica, que está relacionada aos custos associados à manutenção do código necessário para automatizar por meio dessas APIs e ao custo de alterar não apenas a automação, mas talvez também a infraestrutura.
Tudo isso acaba gerando uma conta considerável que, assim como os impostos “de verdade”, é praticamente inevitável. Se você quiser aproveitar os benefícios de um processo de implantação mais fluido e automatizado, terá que incluir a infraestrutura — ou seja, tudo o que fica entre o usuário e o aplicativo e garante que ambos possam se comunicar de forma integrada e segura.
Certo, dito tudo isso, prometi explicar como você pode evitar pagar esses impostos, então vamos lá.

Se você acompanha o setor de orquestração (incluindo os participantes de SDx, como VMware, Cisco e OpenStack), deve ter notado uma ênfase cada vez maior no uso de modelos. Os modelos se assemelham bastante a arquivos de configuração, pois codificam uma grande quantidade de informações necessárias para criar e configurar alguma “coisa”. Se você puder criar um único modelo que abranja a implantação desse serviço de balanceamento de carga, por exemplo, poderá, em tese, reduzir as chamadas de API necessárias a apenas uma: a chamada para enviar o modelo ao local em que esse serviço será executado.
Usar apenas uma chamada de API em vez de, bem, várias simplifica a automação e permite reutilizar o script ou sistema que envia o modelo. Isso é importante porque, ao usar APIs, você precisa escrever scripts que sejam específicos não apenas para o serviço, mas também para o aplicativo que está sendo implantado. Isso significa que, para cada aplicativo implantado, seria necessário escrever outro script para automatizar a implantação dos serviços de que ele precisa, como o balanceamento de carga.
Mas, se você usar modelos, poderá usar o mesmo script e apenas enviar um modelo diferente. Isso significa menos tempo esperando por um novo script para cada aplicativo e menos erros para procurar, como quando Bob copiou e colou pela décima quinta vez e se esqueceu de alterar a linha 33.
Templates são infraestrutura como código, o Santo Graal do DevOps.
Você ainda precisa de APIs, mas não precisa usá-las para tudo. E, se puder evitar isso usando templates, você não terá que arcar com os custos adicionais associados a elas e poderá direcionar essa economia para outra área.
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

Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...