Fluxos de trabalho versus APIs

Hoje tenho uma tarefa para você. Quero que você – sim, você aí – deposite um cheque no banco. Você tem que entrar no carro, dirigir até o banco, entrar, falar com o caixa e depois voltar para casa.

Irritado? Você deveria, principalmente quando pode simplesmente usar seu aplicativo de banco móvel para fazer isso sem todas as etapas extras.

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

Existe uma coisa muito real (eu inventei o nome, mas não a existência) chamada imposto API . Esse é o tempo e a dívida técnica incorridos na execução de processos complexos usando chamadas de API individuais. É como ir fisicamente ao banco em vez de usar seu aplicativo móvel para fazer o depósito.

Esse imposto cresce à medida que os processos se expandem. Se você tiver um processo longo que exija dez ou vinte chamadas de API diferentes, o código (scripts também são códigos) ficará cada vez mais complicado, o que impactará a solução de problemas e tornará mais difícil alterá-lo no futuro. Ossificar processos por meio de chamadas de API individuais é o oposto de agilidade. É a fragilidade que congela a oportunidade de melhorar a eficiência por meio da otimização.

Fluxos de trabalho são basicamente processos predefinidos para tarefas comumente executadas. A maioria dos processos empresariais (e até operacionais) se enquadram nessa categoria. Eles são os comandos que você usa para fazer login, navegar até a parte certa do sistema, alterar o controle de acesso na porta e, então, confirmar a alteração. Toda vez que você faz essa tarefa, é a mesma coisa. É um processo comumente executado que poderia ser facilmente codificado. Existem muitos processos desse tipo em operações e, ao agrupá-los como um fluxo de trabalho, podemos não apenas eliminar o imposto de API, mas também melhorar a qualidade e a sustentabilidade dos scripts que os invocam.

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

Considere este exemplo completamente inventado. No primeiro, você tem 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. Está vinculado à versão da API do sistema com o qual está trabalhando no momento em que foi escrito. Se uma dessas chamadas mudar, o script também terá que mudar.

À direita, você tem uma abordagem baseada no fluxo de trabalho. Você ainda pode iniciar o processo por meio de uma chamada de API (provavelmente preferível em muitas organizações), mas as etapas reais do processo são executadas com base nos parâmetros (variáveis) enviados com a chamada inicial. Talvez você tenha que limpar e fazer commit, mas ainda assim você reduziu o código necessário para duas ou menos interações.

Isso não quer dizer que usar APIs e modelos seja algo ruim. Não é. Mas muitas vezes acontece – especialmente no mundo das redes – que o uso de APIs exige conhecimento específico do sistema e da rede em geral. Isso dificulta que DevOps ou desenvolvedores trabalhem com as APIs. Uma abordagem de fluxo de trabalho remove a suposição de conhecimento ou experiência, o que significa que o DevOps se sentirá confortável ao usá-los e o NetOps mantém a segurança do emprego.  

Em ambientes onde a automação está se consolidando (e talvez até mesmo assumindo o controle), uma abordagem baseada em fluxo de trabalho pode oferecer um alívio substancial ao NetOps, permitindo que o DevOps invoque tarefas sem exigir muito conhecimento específico do domínio.

E eles também podem evitar aqueles irritantes impostos de API. E quem não gosta de fugir dos impostos?