Changer de fournisseur en une ligne, la moitié facile

HERE implémente les dix domaines géospatiaux que notre client Rust modélise, du géocodage à la planification de tournées. Radar en implémente quatre. Les deux passent derrière le même trait dans notre code, et l'écart entre eux est la chose la plus honnête de ce billet.

Le conseil habituel prend l'une de deux formes : engagez-vous sur un seul fournisseur et cessez de vous inquiéter, ou emballez chaque appel dans une couche d'abstraction et dormez mieux. Les deux ont raison à moitié, ce qui est une autre façon de dire que les deux se trompent sur la moitié qui compte. Notre position, affûtée par la maintenance de 35 implémentations de fournisseurs chez HERE, Google, TomTom, Mapbox et Radar : abstrayez la forme de l'appel, et ne prétendez jamais avoir abstrait la substance des données. Le trait vous apporte le benchmarking et une solution de repli dans le travail de tous les jours, plus une issue de secours que vous espérez ne jamais utiliser. Il ne peut pas vous apporter le modèle de trafic d'un fournisseur, et prétendre le contraire, c'est le verrouillage qui fait mal plus tard.

La taxe s'applique même si vous ne changez jamais de fournisseur

Le verrouillage sur une seule API géospatiale est discret parce que la facture n'a qu'une seule ligne. Vous la payez de quatre façons. Les changements de tarifs tombent sur le calendrier du fournisseur, pas sur le vôtre, et les API géospatiales facturent à l'appel, à des volumes qui croissent avec vos utilisateurs que vos revenus suivent ou non. Les dépréciations arrivent avec des délais de préavis que la migration peut dépasser sans avoir eu le temps de se terminer. La couverture se déplace : une région qui répondait admirablement peut se dégrader en silence après un rafraîchissement des données, et votre boîte de réception du support s'en aperçoit avant votre SLA. Et puis il y a la sortie elle-même, la réécriture que vous paierez peut-être dans deux ans, déjà inscrite dans le contrat de cette année parce que personne n'a construit la couture.

Concrètement, voici sa tête : le répartiteur dont la carte devient soudain fausse pour un seul comté après une mise à jour de fournisseur par ailleurs banale, pendant que votre code, qui n'a jamais changé, ramasse la faute.

Il y a aussi une taxe à l'intérieur du contrat. Une renégociation se gagne avec des preuves, et la seule preuve qu'un atelier mono-fournisseur peut sortir de sa poche est une menace à laquelle personne ne croit. Le prix que vous paierez l'année prochaine dépend en partie de votre crédibilité à vous en aller, cette année.

L'asymétrie des fournisseurs est réelle, et le plus étroit fixe votre plancher

Une couche d'abstraction n'est pas gratuite, et son coût porte un nom. Une interface commune est toujours un peu plus petite que n'importe quel fournisseur, et le plancher est fixé par le fournisseur le plus étroit que vous soutenez. Parmi les dix domaines que everymap-core modélise, HERE répond aux dix, TomTom à huit, Mapbox à sept, Google à six, Radar à quatre. Un trait ne peut pas donner à Radar les six autres. Quiconque prétend à l'équivalence complète ment, ou rétrécit l'interface jusqu'à la hauteur de Radar, et la seconde option fait payer discrètement aux quatre autres fournisseurs leur profondeur.

Alors nous avons rendu l'échec bruyant au lieu d'élégant. Demandez à un fournisseur une capacité qu'il n'a pas et les macros unsupported_* d'everymap lèvent une erreur qui dit google does not support traffic, mot pour mot, avant que la production ne s'en inquiète. Le design paresseux renvoie une réponse vide et transforme une limite du fournisseur en enquête qualité le trimestre suivant. Un résultat vide et un jeu de données défectueux sont indiscernables dans vos tableaux de bord, et c'est précisément l'échange que l'erreur refuse de faire.

Une chose que nous ne prétendrons pas : notre interface, comme toute interface commune, est plus petite que la somme de ses parties. Ce qui est abandonné est documenté dans le dépôt plutôt qu'enterré dans ce paragraphe.

Ce que le trait vous apporte : le benchmarking d'abord, la sortie ensuite

La contrepartie d'une interface plus petite, c'est que les cinq fournisseurs deviennent testables depuis un seul siège. C'est tout l'argument de vente de la bibliothèque, en ligne de commande ou en code :

everymap --provider google --api-key $GOOGLE_KEY geocode "Brandenburg Gate, Berlin"

Remplacez google par tomtom et la même question part vers un autre fournisseur, même entrée, preuve différente. Voilà l'interrupteur d'une ligne. Ce qu'il achète vraiment se passe à trois endroits.

Le benchmarking vient d'abord, et c'est le plus sous-estimé. Un harnais everymap-bench, en cours de développement au moment où ce billet est écrit, pose la même question de routage ou de géocodage à plusieurs fournisseurs et imprime un tableau de comparaison. Vous pouvez arriver à la renégociation avec l'exactitude et la latence mesurées des appels que vous passez réellement, au lieu de présentations commerciales. Le benchmarking est aussi le moyen d'apprendre que le fournisseur au nom célèbre répond moins bien que le petit économique aux adresses de votre région précise, et c'est une conversation à avoir avant le contrat, pas après.

La solution de repli vient ensuite : quand votre géocodeur principal bride ses requêtes pendant un pic de trafic, un second fournisseur derrière le même trait vaut une réponse dégradée au lieu d'une page blanche. La sortie vient en dernier et compte le plus. La migration que vous ne lancerez peut-être jamais est bon marché à garder possible, et une sortie bon marché change les conversations que vous avez sur les prix et les dépréciations. C'est la taxe de la première section qui se rembourse.

Ce que le trait ne peut jamais porter : la partie pour laquelle vous avez choisi le fournisseur

Un appel basculé garde la même syntaxe et change de substance. Le modèle de trafic de HERE, la fraîcheur de ses données, sa manière particulière de deviner qu'un chantier sera dégagé avant jeudi : rien de tout cela ne survit au trait. Lancez le même itinéraire chez deux fournisseurs pour le même mardi à 17 h et vous obtiendrez deux réponses honnêtes qui se contredisent, chacune correcte dans sa propre image de la route.

C'est là que l'abstraction tourne à la superstition. Si la qualité de votre produit est celle du fournisseur, si vos chauffeurs recalculent quelques minutes plus vite grâce au flux de trafic d'un seul fournisseur, alors le trait vous flatte. Le comportement que vivent vos utilisateurs a des hypothèses de fournisseur incrustées dans la logique produit : comment s'affichent les heures d'arrivée estimées, à quel moment un réordonnancement se déclenche. Changer de fournisseur coûte alors un audit produit, pas un audit de code. Croire le contraire est le verrouillage le plus profond, parce que vous pouvez quitter le fournisseur à tout moment et rester écrit contre sa vision du monde.

Quand abstraire, et quand rester absolument immobile

Abstrayez quand la capacité est banalisée et que votre position de négociation dépend de preuves. Le géocodage et les isochrones sont les cas classiques : assez interchangeables pour être comparés, assez coûteux en volume pour que la comparaison se rembourse toute seule. Les projets jeunes ont aussi leur place ici, puisque le second fournisseur ne vous coûte aujourd'hui qu'un simple drapeau de configuration, et plus tard une négociation.

Restez immobile quand la valeur de votre produit est la force distinctive d'un seul fournisseur. Achetez le flux de trafic pour ce qu'il est, une dépendance entourée d'un fossé, et dépensez le budget d'abstraction là où c'est honnête.

Et n'abstrayez jamais en miroir de la surface complète d'un seul fournisseur. Un client qui reproduit chaque paramètre d'une API est cette API traduite, et la traduction n'est qu'une réécriture programmée pour plus tard, avec des étapes en plus.

Notre propre comptabilité honnête : les 35 implémentations sont du code jeune, et le compte de 654 tests est celui du README plutôt qu'une chose que nous aurions auditée en conditions adversaires. Une interface commune vaut son plancher, pas plus, et votre plancher, ce sont les fournisseurs que vous soutenez réellement.

La décision en une ligne : payez la prime du trait tant que les appels se ressemblent encore, laissez le modèle de trafic là où il vit, et laissez le benchmark vous dire quand la prime cesse d'être rentable.