Raming van de vervanging van een API van een derde partij

De API van de nieuwe leverancier lijkt identiek, totdat u begint met het migreren van de gegevens.

Het argument 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 van essentieel belang zijn. De codebase bevat twee jaar aan voorbeelden als „dit is een tekenreeks, maar het is in feite een datum in hun formaat”, „dit retourneert null terwijl het nul betekent” en „dit past stilzwijgend een verwerkingslimiet toe”. Een volledige overstap betekent dat al deze eigenaardigheden moeten worden nagebootst in het gedrag van de nieuwe leverancier, dat op manieren afwijkt die door niemand zijn gedocumenteerd.

In de raming moet rekening worden gehouden met de periode waarin beide systemen naast elkaar draaien: de oude en de nieuwe leverancier draaien parallel, waarbij de output wordt 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 wanneer de gegevens van een klant voor het eerst in een uitzonderingsgeval 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 wij of de resultaten gelijkwaardig zijn — door de antwoorden gedurende een week te vergelijken?”

Vragen die het waard zijn om te stellen voordat u gaat stemmen

• Zijn er bij de vorige leverancier historische gegevens die wij moeten meenemen?
• 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 wij terugkeren naar de oude situatie indien de nieuwe leverancier slechter blijkt te zijn?

De basisaanroepen zijn eenvoudig; het bewijs van gelijkwaardigheid is het echte 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.