De functionaliteiten van cloudapplicaties worden in toenemende mate via Application Programming Interfaces (API's) ontsloten, veelal REST API's. In het geval van een cloud banking platform is er bijvoorbeeld een API om klanten op te voeren, rekeningen toe te voegen en transacties uit te voeren. Bij de implementatie van een cloudapplicatie is het migreren van data vanuit de bestaande (on-premise en/of cloud) systemen een belangrijk onderdeel. API's bieden een effectieve manier om gemigreerde data in de nieuwe cloudapplicatie te laden. Echter, een datamigratie naar de cloud met een API laadstrategie kent een aantal specifieke eigenschappen en aandachtspunten waar rekening mee moet worden gehouden.

Marco Stuit
Senior Consultant

Laden via API's & Volgordelijkheid
In het laadproces via APIs speelt volgordelijkheid een belangrijke rol. Eerst worden de klanten geladen, vervolgens de rekeningen van de succesvol opgevoerde klanten en vervolgens de bijbehorende transacties. Naast de mapping naar de doel-dataset is het definiëren van een herhaalbaar migratieproces (bestaande uit meerdere stappen) daarom een belangrijke activiteit in de datamigratie. De migratie-oplossing moet de mogelijkheid bieden om de bijbehorende workflow in te richten.

Verwerking Responses & Logging
Logging van het volledige berichtenverkeer (API requests en responses) en een robuuste foutafhandeling is van belang om de migratie workflow te faciliteren. Via de response-berichten wordt vastgesteld of een specifiek object succesvol is opgevoerd. Indien het opvoeren van bepaalde klanten een foutbericht oplevert dan dienen de rekeningen van die klanten niet te worden opgevoerd. Dikwijls bevat het response-bericht tevens een nieuwe uitgegeven identificatie (bijvoorbeeld een klantnummer) dat verderop in de workflow nodig is om de gerelateerde gegevens te koppelen. Zoals het koppelen van een rekening aan het juiste klantnummer. Alle foutberichten worden geregistreerd als onderdeel van de logging. Zo kan achteraf worden vastgesteld welke klanten niet zijn opgevoerd en kunnen deze opnieuw worden aangeboden als de oorzaak is weggenomen.

Volledigheid & Historie
Indien het niet lukt om bepaalde rekeningen en transacties met een foutmelding opnieuw op te voeren - terwijl wel alle klanten zijn opgevoerd - dan is er sprake van een onvolledige situatie. Volledigheid is daarom een aandachtspunt. Het moet mogelijk zijn de reeds opgevoerde data te verwijderen. Dit kan handmatig of via API's, afhankelijk van de geboden functionaliteit van de cloudapplicatie. In de praktijk is gebleken dat het effectief is om een back-up te maken van de cloud-database voordat het laadproces start. Deze kan dan teruggezet worden indien men terug wil naar een pre-migratie status.

Naast volledigheid is ook historie een aandachtspunt. In voorkomende gevallen zijn API's namelijk alleen geschikt om actuele gegevens te migreren. Het is daarom van belang om samen met de leverancier van de cloudapplicatie vooraf vast te stellen of de beschikbare API's geschikt zijn om historische gegevens te verwerken.

Architectuur & Connectiviteit
De migratie-oplossing moet in staat zijn om het berichtenverkeer richting de cloudapplicatie via verschillende API calls te organiseren zodat de gemigreerde data in de juiste volgorde en met de juiste snelheid in de doelomgeving wordt geladen. Een API Dispatcher - als centrale component van de migratie-oplossing - is hiervoor geschikt. De dispatcher fungeert als client dat via het HTTP protocol communiceert met de API endpoints op de server van de cloudapplicatie. Een essentieel aspect hierbij is het opzetten en testen van de connectiviteit van de migratie-oplossing richting de API endpoints. De migratie-oplossing dient hierbij te beschikken over een authenticatie-mechanisme waarmee met de juiste credentials en/of tokens toegang wordt verkregen tot de API endpoints.

Figuur 1. Architectuur van een datamigratiesysteem met een cloudoplossing als doelomgeving.

Performance
Het succesvol migreren van data via API's is mede afhankelijk van de geboden performance. Bij grote hoeveelheden data worden de API calls parallel uitgevoerd (multi-threading). Omdat de API's van de cloudapplicatie veelal beperkt mogen worden belast, dient de migratie-oplossing over een throttle mechanisme te beschikken, waarmee de load op de API endpoints kan worden gedoseerd.

Past het in de beschikbare tijd?
Met name als er grote hoeveelheden data worden gemigreerd, is het van belang om in een vroeg stadium zowel de connectiviteit en de performance te testen in samenwerking met de pakketleverancier of implementatiepartner. Om zo snel mogelijk inzichtelijk te maken hoeveel berichten in parallel kunnen worden verwerkt en of de doorlooptijd van het migratieproces binnen de gewenste marges valt. Afhankelijk van de hoeveelheid data, is de ervaring dat een datamigratie via API's binnen een beperkt time window van 1 of 2 dagen kan plaatsvinden.

Single vs. bulk API's
Naast het uitvoeren van meerdere parallelle synchrone (single) API calls kan de migratie-oplossing tevens worden geconfigureerd om a-synchroon te laden via een bulk API. Bijvoorbeeld als het grote aantal netwerk round-trips een bottleneck vormt. In de praktijk is de keuze voor een single of bulk API laadstrategie afhankelijk van de (on)mogelijkheden van de cloudapplicatie en de voorkeuren van de betrokken partijen.

Het voordeel van single API calls is dat de gemigreerde data dezelfde route volgt als het reguliere (werk)proces. Er hoeven geen migratie-specifieke (bulk) services te worden gebruikt en/of ontwikkeld. De data wordt onderworpen aan de reeds bestaande en bewezen validatieregels van de cloudapplicatie. Daarnaast kan de verwerking van elk bericht in de doelomgeving individueel worden gevolgd (bijvoorbeeld via track-and-trace id’s). Dit maakt rollback of herstart van individuele instances eenvoudiger.

Verschuiving van verantwoordelijkheden
Bij een datamigratie naar de cloud met een API laadstrategie maakt het laden van de data integraal onderdeel uit van de migratie-oplossing. De migratiepartij is - naast het ontwerpen en implementeren van een accurate mapping van bron naar doel – ook verantwoordelijk voor het laden van de data via de API endpoints van de cloudapplicatie. En hierin ook verantwoordelijk voor het inrichten en configureren van een laadproces waarbij een stuk data (lees: object) wordt aangeboden. Het resulterende object dat direct beschikbaar is via de API response, wordt meteen gebruikt in de volgende stap van het laadproces.

Dit in tegenstelling tot een klassieke datamigratie waarbij een overdracht plaatsvindt van de gegenereerde bestanden met gemigreerde data naar de klant of leverancier die vervolgens verantwoordelijk is voor het verwerken en laden van de bestanden in de doelomgeving. Dit betreft een verschuiving in de verantwoordelijkheden en aanpak van datamigraties.

Eenmaal ingericht is een datamigratie via API's een volledig online en synchroon proces. Zowel de extractie, de transformatie als het laadproces richting de cloudapplicatie kan door één partij worden uitgevoerd. Het grootste voordeel hiervan is dat de datamigratie volledig geautomatiseerd plaatsvindt waardoor de klant en/of leverancier zich kan focussen op de bedrijfsmatige aspecten van de datamigratie zoals de inrichting van de applicatie, het uitvoeren van gebruikerstesten en de acceptatie van het eindresultaat.

Tot slot
Bij alle soorten datamigraties is het van belang dat de datamigratie plaatsvindt zonder dataverlies: alle data moet worden verantwoord ten behoeve van de acceptatie van de datamigratie. Het belang van het uitvoeren van een gedegen migratiecontrole via bron-doel vergelijkingen is bij een datamigratie naar de cloud daarom net zo groot als bij een klassieke datamigratie.

 

Ook migreren naar de cloud?