É época de impostos nos EUA, e você sabe o que isso significa, não é? Sim, todos nós estamos procurando maneiras de reduzir esse fardo.
Lamento dizer que, embora eu já tenha trabalhado como desenvolvedor para uma empresa de software tributário, não estou realmente qualificado para lhe dar conselhos sobre isso. Mas se você está procurando conselhos sobre como evitar pagar impostos de API neste ano (ou no próximo), então você carregou a página certa na Internet.
Um imposto de API é a sobrecarga que você paga ao usar APIs para automatizar o provisionamento e a configuração de infraestrutura como parte do processo de implantação. O imposto API (como todos os impostos) não é simples de calcular porque, na verdade, é duplo: operacional e técnico.
Operacionalmente, o imposto de API incorre em custos em termos de recursos e tempo consumidos por chamadas excessivas de API. Mesmo algo tão conceitualmente simples como um serviço de balanceamento de carga requer a criação, configuração e ativação de múltiplos objetos. Monitoramento, pools, algoritmos, endereços IP e atributos de rede devem ser configurados, e cada um desses objetos requer várias etapas (chamadas de API) para isso. Some tudo isso e até mesmo um serviço simples de balanceamento de carga exigirá diversas chamadas de API para funcionar. Chamadas que demoram 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. Mudar a tarefa requer mudar o código (porque scripts são códigos, quer queiramos admitir ou não) e testá-lo, o que leva tempo e recursos que somam dólares reais no resultado final.
Esses custos – para desenvolver, testar e manter os sistemas e scripts – são os impostos técnicos sobre o uso dessa API. O que isso significa é que os scripts incorrem em custos de longo prazo na forma de dívida técnica, que se relaciona aos custos associados à manutenção do código necessário para automatizar por meio dessas APIs e ao custo para alterar não apenas a automação, mas talvez a infraestrutura.
Tudo isso resulta numa conta e tanto que, assim como os impostos “reais”, é praticamente inevitável. Se você quiser os benefícios de um processo de implantação mais fluido e automatizado, você terá que incluir a infraestrutura, e isso significa tudo o que fica entre o usuário e o aplicativo e garante que os dois possam se comunicar de forma integrada e segura.
Certo, dito isso, prometi explicar como você pode evitar pagar esses impostos, então vamos lá.
Se você tem observado o espaço de orquestração (e isso inclui os players SDx como VMware, Cisco e OpenStack), notará que há uma ênfase crescente no uso de modelos. Os modelos são muito parecidos com 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, você pode reduzir ostensivamente as chamadas de API necessárias para apenas uma — aquela para enviar o modelo para o qual esse serviço irá residir.
Usar apenas uma chamada de API em vez de, bem, muita coisa simplifica a automação e permite que você reutilize o script ou sistema que está enviando o modelo. Isso é importante porque, quando você usa APIs, precisa escrever scripts que não sejam apenas específicos para o serviço, mas também específicos para o aplicativo que está sendo implantado. Isso significaria que para cada aplicativo que você implantar, você teria que escrever outro script para automatizar a implantação dos serviços de que ele precisa, como 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 esqueceu de alterar a linha 33.
Os modelos 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 você puder evitar isso, usando modelos, você poderá evitar pagar os impostos associados a eles e transferir essas economias para outro lugar.