BT

Os custos para versionamento de uma API

por Mark Little , traduzido por Diogo Carleto em 27 Dez 2013 |

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?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Versões compatíveis, ou poucas versões by Maluko .

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

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.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT