My Geocode

Migração

O que depender de um único provedor pequeno ensina sobre risco de fornecedor

· 3 min de leitura · My Geocode · #risco-de-fornecedor#planejamento-de-migração#geocodificação#arquitetura#resiliência

Uma dependência de uma única API é fácil de ignorar justamente porque funciona em silêncio por muito tempo. Uma chamada de geocodificação que retornou resultados corretos todos os dias por dois anos não parece um risco; parece um problema resolvido. O risco só fica visível no dia em que algo muda do lado do provedor, um endpoint descontinuado, uma reestruturação de preços, a aquisição da empresa ou simplesmente uma queda do serviço, e a essa altura o custo de não ter nenhuma alternativa pronta já está sendo pago na correria, em vez de em uma migração planejada.

Os provedores menores carregam esse risco de forma mais aguda do que os maiores, não porque sejam menos confiáveis no dia a dia, mas porque normalmente têm menos redundância nas próprias operações e um modelo de negócio mais sensível à saída de um único grande cliente ou a qualquer mudança de financiamento. Isso não é uma crítica a nenhum provedor menor específico; é um fato estrutural sobre o tamanho das empresas que se aplica a muitos serviços que, de resto, são excelentes.

A lição prática não é necessariamente evitar provedores menores. É construir uma arquitetura que não suponha que algum provedor é permanente, seja qual for o tamanho dele. Alguns hábitos concretos ajudam:

  • Mantenha a lógica específica de cada provedor atrás de uma interface interna no seu próprio código, para que uma função de leitura trabalhe com a sua própria estrutura de dados normalizada, e não diretamente com os nomes de campos de um provedor específico espalhados pela base de código
  • Teste periodicamente se a sua integração realmente conseguiria migrar, mesmo que você não tenha nenhum plano de migrar em breve, já que uma suposição de portabilidade não testada não é o mesmo que portabilidade real
  • Mantenha registrado quanto uma migração completa custaria em tempo de engenharia, como conhecimento permanente da organização, e não como algo calculado pela primeira vez no meio de uma crise

Uma abordagem baseada em compatibilidade muda um pouco essa conta, porque reduz a parte do custo de migração que fica no seu próprio código de leitura. A My Geocode mantém 17 hosts de compatibilidade que reproduzem o formato exato de requisição e resposta dos principais provedores, incluindo Google Maps Platform, Mapbox, HERE, ipstack e outros, documentados em /compatibility/, o que significa que a parte mais arriscada de uma migração forçada, reescrever a lógica de leitura sob pressão de tempo, muitas vezes pode ser evitada se o provedor que você está deixando já tiver um host de compatibilidade correspondente disponível.

Dito isso, a lição mais profunda sobre o risco de fornecedor vale seja qual for o provedor ou a plataforma que você usa, incluindo esta: a posição mais saudável é aquela em que trocar de provedor é uma opção real e testada, e não teórica. Fazer um pequeno teste com um provedor alternativo antes de precisar, mesmo com uma fração do seu tráfego, transforma o risco de fornecedor de uma preocupação abstrata em uma capacidade concreta e ensaiada. Testar custa relativamente pouco, e o retorno só aparece no dia em que você realmente precisa.

Mais em Migração