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?
Versões compatíveis, ou poucas versões
by Anna Allen,
Interessante.
by Gabriel RB,
Versões compatíveis, ou poucas versões
by Anna Allen,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
A meu ver, ao mesmo tempo que é preciso lançar novas features, também é necessário dar um tempo para a migração de versão. Manter compatibilidade com todas as versões antigas até hoje não me pareceu compensar o custo.
Interessante.
by Gabriel RB,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Pra mim q não tenho experiência com desenvolvimento de APIs, foi muito construtivo o artigo!
Não sei qual abordagem se adaptaria melhor a minha realidade. Mas gostei da abordagem de versões diferentes rodando em produção.