Fluxos de trabalho versus APIs

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Hoje tenho uma tarefa para você. Quero que você — sim, você aí mesmo — deposite um cheque no banco. Você precisa entrar no carro, dirigir até o banco, entrar, fazer o depósito com o caixa e depois voltar para casa.

Irritado? É para ficar mesmo, especialmente quando você poderia simplesmente usar o aplicativo do seu banco para fazer isso sem todas essas etapas extras.

E essa, meus amigos, é a diferença entre um fluxo de trabalho (um processo) e uma API.

Existe algo muito real (eu inventei o nome, mas não sua existência) chamado imposto de API. Trata-se do tempo e da dívida técnica gerados pela execução de processos complexos por meio de chamadas individuais de API. É como ir pessoalmente ao banco em vez de usar o aplicativo no celular para fazer esse depósito.

Esse imposto aumenta à medida que os processos se expandem. Se você tem um processo longo que exige dez ou vinte chamadas de API diferentes, o código (scripts também são código) fica cada vez mais complicado, o que dificulta a solução de problemas e torna futuras alterações mais difíceis. Engessar processos por meio de chamadas de API individuais é o oposto de agilidade. É uma fragilidade que elimina a oportunidade de aumentar a eficiência por meio da otimização.

Os fluxos de trabalho são, basicamente, processos predefinidos para tarefas executadas com frequência. A maioria dos processos de negócios (e até mesmo operacionais) se enquadra nessa categoria. São os comandos usados para fazer login, navegar até a área correta do sistema, alterar o controle de acesso na porta e, em seguida, confirmar a alteração. Sempre que essa tarefa é realizada, o procedimento é o mesmo. Trata-se de um processo executado com frequência que poderia ser facilmente codificado. Há muitos processos desse tipo nas operações e, ao encapsulá-los em um fluxo de trabalho, podemos não apenas eliminar o custo adicional das APIs, mas também melhorar a qualidade e a sustentabilidade dos scripts que os invocam.

Isso acontece porque usar fluxos de trabalho em vez de APIs resulta em um código menos complexo, mais fácil de gerenciar e de alterar. Eles são mais ágeis e menos frágeis.

Considere este exemplo totalmente fictício. No primeiro caso, temos uma abordagem baseada em API. Cada etapa desse processo representa uma chamada de API. Isso significa que um script com quase vinte chamadas diferentes precisa ser desenvolvido, testado e mantido ao longo do tempo. Isso é dívida técnica. Ele fica vinculado à versão da API do sistema com o qual interagia quando foi escrito. Se uma dessas chamadas mudar, o script também precisará mudar.

À direita, temos uma abordagem baseada em fluxo de trabalho. Ainda é possível iniciar o processo por meio de uma chamada de API (provavelmente a opção preferível em muitas organizações), mas as etapas propriamente ditas são executadas com base nos parâmetros (variáveis) enviados na chamada inicial. Talvez seja necessário fazer uma limpeza e um commit, mas, ainda assim, você reduziu o código necessário a duas interações ou menos.

Isso não quer dizer que usar APIs e modelos seja algo ruim. Não é. Mas muitas vezes — especialmente no mundo das redes — o uso de APIs exige conhecimentos específicos sobre o sistema e sobre redes em geral. Isso dificulta o trabalho de DevOps ou desenvolvedores com as APIs. Uma abordagem baseada em fluxos de trabalho elimina a necessidade de conhecimento ou experiência prévia, o que significa que a equipe de DevOps se sentirá à vontade para usá-los, enquanto a equipe de NetOps mantém sua segurança no emprego.

Em ambientes onde a automação está ganhando espaço (e talvez até assumindo o controle), uma abordagem baseada em fluxos de trabalho pode proporcionar um alívio significativo para as equipes de NetOps, permitindo que as equipes de DevOps executem tarefas sem precisar de um vasto conhecimento específico do domínio.

E, de quebra, eles também podem evitar aquelas incômodas taxas de API. E quem não gosta de evitar taxas?

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

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 Vittie