O versionamento de contrato e o versionamento de API/Serviços sempre foram motivos de preocupação em sistemas baseados em SOA. Seja devido ao impacto que existe sobre a modularidade, ou a governança cliente-serviço. Neste cenário, versionamento ainda é uma espécie de arte mais do que uma ciência. Há muitos exemplos de grupos publicando o benefício de suas experiências (por exemplo, o REST é extremamente popular). Entretanto, Jean-Jacques Dubray escreveu um artigo recentemente que tenta injetar algum objetivo científico nesse domínio de problema.
Pediram-me recentemente para criar uma estimativa dos custos de versionamento de APIs (ou WebServices). Gostaria de compartilhar essa estimativa porque sinto que muitas pessoas continuam não entendendo o custo e as implicações ao se versionar uma API/Serviço.
De acordo com Jean-Jacques Dubray, durante o trabalho, foi descoberto que o custo de construção de APIs dependia da abordagem a ser utilizada posteriormente para o versionamento dessas APIs.
A parte mais importante a entender é, mesmo que o custo para os consumidores pareça pequeno para você, não se trata de apenas um custo puro, isso é risco, interrupção em planos de projetos, orçamentos indisponíveis… com mudanças que não tem valor de negócio imediato para um cliente real que não espera nenhuma mudança na API.
O artigo então passa a classificar três diferentes abordagens para o controle de versão de uma API (veja o artigo completo para se aprofundar em cada assunto, incluindo como o autor define uma maneira para mensurar custos):
- O Nó - "Todos os consumidores estão vinculados a uma única versão da API, quando a API muda, todos consumidores tem que mudar, basicamente criando um massivo efeito em cascata em todo o conjunto de consumidores / ecossistemas."
- Ponto a Ponto - "Cada versão do serviço é deixada em execução e em produção e os consumidores são obrigados a mudar por conta própria, quando eles desejarem. O custo de manutenção aumenta conforme o número de versões em produção aumenta."
- Versionamento Compatível - "Todos clientes conversam com a mesma versão de API/Serviço compatível."
Dadas essas definições e os custos associados computados utilizando as equações que Jean-Jacques Dubray descreve, é possível traçar os custos relativos como mostrado abaixo (o eixo y é o custo, o eixo x é o número da versão):
Sobre os custos relativos, o autor escreveu que:
[...] uma única versão forçando cada consumidor a migrar quando a API muda é o custo mais caro para o ecossistema. A multiplicidade de versões que precisam ser mantidas é melhor, mas ainda muito caro quando você tenta manter atualizada cada versão, ou alternativamente, funcionando em versões mais antigas. A estratégia de versão compatível parece oferecer a melhor eficiência.
Então o que os outros acham dessa abordagem? É esta a maneira que Jean-Jacques Dubray e sua equipe calculam o custo de versionar APIs aplicados além dos ambientes no qual eles foram desenvolvidos? A explicação relativa dos custos faz sentido dado sua própria experiência? Existem outras categorias que Jean-Jacques Dubray e sua equipe não cobriram?