Raming van de vervanging van een API van een derde partij
Hoe u de impact van een API-overstap naar een derde partij kunt inschatten: semantische verschillen, gelijktijdige werking en de aannames die verweven zijn met de eigenaardigheden van de oude leverancier. De nieuwe API lijkt slechts identiek.
De API van de nieuwe leverancier lijkt identiek, totdat u begint met het migreren van de gegevens.
Het verkoopargument om van leverancier te wisselen is altijd hetzelfde: de nieuwe API is overzichtelijker, sneller en goedkoper. De valkuil is dat de eigenaardigheden van de oude API een dragende rol spelen. De codebase bevat twee jaar aan gevallen als „dit is een tekenreeks, maar het is in feite een datum in hun formaat”, „dit retourneert null terwijl het nul betekent”, “dit past stilzwijgend een verwerkingslimiet toe” — en een volledige overstap betekent dat al deze eigenaardigheden moeten worden nagebootst in het gedrag van de nieuwe leverancier, dat op manieren verschilt die door niemand zijn gedocumenteerd.
In de begroting moet rekening worden gehouden met de periode waarin beide systemen naast elkaar draaien: de oude en de nieuwe leverancier draaien parallel, waarbij de resultaten worden vergeleken, totdat het team er zeker van is dat de nieuwe leverancier aan de verwachtingen voldoet. Die fase duurt vaak langer dan de implementatie zelf. Bij projecten waarin hier geen rekening mee wordt gehouden, wordt de nieuwe leverancier in gebruik genomen, waarna de tekortkomingen pas aan het licht komen zodra de gegevens van een klant in een randgeval terechtkomen.
Wat er in de kamer wordt gezegd
Backend: “De nieuwe SDK is beter. De basisaanroepen kosten elk een dag.”
Inleiding: “Hoe zit het met de historische gegevens die zij voor ons bewaren?”
SRE: “Gaan we beide leveranciers tegelijkertijd gebruiken, of schakelen we over?”
Backend: “Hun webhook-formaat is anders. Dat geldt ook voor de authenticatie.”
Vraag: „Hoe controleren we of de resultaten gelijkwaardig zijn — door de antwoorden een week lang te vergelijken?”
Vragen die u zich het beste kunt stellen voordat u gaat stemmen
- Zijn er historische gegevens bij de vorige leverancier die wij moeten overnemen?
- Verschillen in authenticatie — API-sleutels, OAuth, ondertekende verzoeken?
- Webhooks: komen de gebeurtenissen naadloos overeen, of moeten we ze omzetten?
- Periode van gelijktijdige uitvoering: hoe lang duurt deze, en wat is „goed genoeg“ om over te schakelen?
- Rate limits en prijsmodel bij de nieuwe leverancier — hetzelfde of anders?
- Terugdraaien: kunnen we terugkeren naar de oude situatie als de nieuwe leverancier slechter blijkt te zijn?
De basisaanroepen zijn eenvoudig; het bewijs van gelijkwaardigheid is het lastige werk. Als zowel de duale uitvoering als de gegevensverplaatsing daadwerkelijk plaatsvinden, is dat meer dan één verhaal — splits ze en beoordeel de verificatie los van de implementatie.
Maak een begroting voor de dubbele uitvoering en de gelijkwaardigheidscontrole. De overzichtelijke API is het goedkope deel.
Net als bij het inschatten van een databasemigratie is de code snel klaar; het echte werk zit hem in de implementatie. Bekijk de andere praktijkvoorbeelden van schattingen, of start een gratis planning poker-sessie zodra het plan voor de dubbele uitvoering in grote lijnen is uitgewerkt.