KVK werkt aan een schaalbaar fundament waarmee het straks mogelijk is gegevens uit het Handelsregister sneller en beter te ontsluiten. Dit moet gebeuren met een tweede, gesynchroniseerde database die draait op de Docker-Rancher stack met een NoSQL-databaseopslag. Een flinke uitdaging, waarbij 2021 in het teken zal staan van de eerste livegang.
Gegevens van bedrijven, rechtspersonen en andere organisaties worden in het Handelsregister door KVK op een juridisch juiste manier opgeslagen. Begrijpelijk, maar de transactionele, objectgeoriënteerde wijze van opslaan maakt het de organisatie lastig gegevens snel uit te leveren, onder meer via API’s voor intern en extern gebruik. IT-architect Marcel van den Brink schetst de uitdaging. “Er is ons veel aan gelegen dat elke transactie goed wordt opgeslagen, waarbij telkens veel informatie wordt opgehaald om te beoordelen of wijzigingen voldoen aan wet- en regelgeving. Maar doordat je steeds het hele object met alle verwante informatie, waaronder de historie, ophaalt, ontstaan er knelpunten als het gaat om performance.”
Scheiding van modellen
Met het GegevensLeveringsPlatform (GLP) heeft KVK nu een technische oplossing ontwikkeld die gebaseerd is op Docker, Kubernetes, Kafka en een NoSQL-databaseopslag (MongoDB, Cassandra) waarbij vervangbaarheid van de componenten een uitgangspunt is. Ontwikkelaars zitten hierdoor niet vast aan één techniek. GLP scheidt het transactionele model van een lees-model volgens het CQRS-concept (Command Query Responsibility Segregation) waarbij KVK de informatie uit onder meer juridische overwegingen zo volledig mogelijk opslaat in de bestaande database en voldoet aan de behoefte van klanten die gegevens nodig hebben voor hun processen. Marcel: “Denk hierbij aan de vele gemeentes, banken, verzekeraars, leasemaatschappijen die vanuit wetgeving moeten weten met wie ze zaken doen en dit ieder jaar met een check-up moeten controleren.”
“Het huidige handelsregister is een traditionele multitierapplicatie, met een applicatielaag en een relationele database als opslagmedium”, zegt Marcel. “Dat model was tien, vijftien jaar geleden heel populair, maar de relationele database blijft de bottleneck. Je kunt de applicatielaag wel schalen, maar de database blijft in de huidige opzet een single node. Daarnaast is het probleem dat er een objectenmodel opgehaald wordt door de softwarelaag en de database zonder de softwarelaag niet leesbaar is. De combinatie van applicatielaag, objectenmodel en relationele database is niet schaalbaar”.
Containeromgeving
De oplossing lag in de al door KVK gebruikte private cloudomgeving, gebaseerd op Docker met Rancher en Kubernetes. Een volledige self-service containeromgeving waarin ontwikkelteams hun eigen deployments en scaling kunnen uitvoeren. Marcel: “Daarnaast zochten we naar een oplossing voor opslag waarbij we deze als component konden gebruiken. We zijn nu veel API’s aan het bouwen die werken met JSON wat in veel NoSQL-databases gebruikt wordt. Als je dan kijkt naar waar veel marktpartijen mee bezig zijn, kwam MongoDB al snel naar boven. Schaalbaar aan alle kanten, met volop mogelijkheden om loads over servers te verdelen. Maar we hebben ook Cassandra en andere NoSQL- databases opgenomen in onze plannen, omdat we daarmee o.a. hiërarchische relaties tussen bedrijven nog beter kunnen opslaan.”
Door in bouwblokken te gaan denken in de opslaglaag, met als basis een schaalbare infrastructuur met Docker en Kubernetes, wordt het mogelijk steeds de juiste technologie te gebruiken. “Daarnaast hadden we nog een omgeving nodig voor het publiceren van events bij het opslaan van gegevens in het Handelsregister. Dan kun je kiezen voor publish & subscribe-patronen waarbij je messagequeuing-oplossingen gaat gebruiken, of een streaming-oplossing zoals Kafka dat aanbiedt. Ook daar wilden we flexibel in zijn. We zijn uiteindelijk verder gegaan met Kafka.”
Rest-endpoints blijven onveranderd
Voor het ontsluiten van de data is een queryhandler nodig. “Deze hebben wij nu gebouwd op basis van het relationele, objectgeoriënteerde model. Het API-contract dat straks op het GLP draait is hetzelfde als het API-contract dat nu op het relationele model is gebouwd. Gebruikers, intern of extern, gaan hierdoor niks merken van de invoering van het platform, behalve een veel betere performance dan zij gewend waren.” Bij de keuze voor de architectuur en componenten ging KVK overigens zeker niet over één nacht ijs, merkt Marcel op. “De validatie hebben we laten uitvoeren door een erkende externe partij om te kijken of de gekozen architectuur bij andere organisaties gebruikt wordt voor het oplossen van het probleem dat wij hebben. Het betreft inderdaad veel gebruikte technologie, het is dus zeker een goed doordachte oplossingsrichting geweest.”
Er waren verschillende uitdagingen bij het bouwen van de oplossing. “Een daarvan was hoe wij het juiste moment moesten kiezen om de mutatie af te vangen”, vertelt Marcel. “Een mogelijkheid daarvoor was om direct ‘in te prikken’ op de database zelf, bijvoorbeeld met Change Data Capture, waarmee je low-level met bepaalde plugins heel snel data kunt ontsluiten met Kafka als event datastream. Alleen is het Handelsregister een monoliet met meer dan 160 tabellen die betrokken zijn bij het opslaan van gegevens, met daarbovenop een historieprotocol waarin we in verschillende tijdslijnen acties moeten kunnen reconstrueren. Die combinatie maakt het zo complex dat je data niet zomaar low-level kunt ontsluiten. Daarom zijn we naar een andere optie gegaan: inprikken op de applicatielaag van het Handelsregister. De aanpassingen hiervoor hebben we netjes geïsoleerd in de codebase in aparte modules. De rest van de Handelsregister-codebase wordt door een ander team beheerd, in de CI/CD-pipeline zijn er goede afspraken gemaakt zodat wijzigingen elkaar niet in de weg zitten.”
Steeds meer oplossingen voor persistency
Een andere uitdaging lag op het gebied van infrastructuur. “Kubernetes met Rancher is vooral gemaakt voor stateless applicaties die geen persistent opslag nodig hebben en waarop je heel gemakkelijk pods kunt spinnen.” De afgelopen jaren hebben verschillende makers van oplossingen, zoals Kafka, MongoDB en Cassandra hiervoor standaardcomponenten ontwikkeld die helpen met het beheer van zulke oplossingen in containerised omgevingen. “We hebben een aantal van deze operators, voor onder meer Kafka en MongoDB, geprobeerd om testen of we de juiste keuzes hebben gemaakt. Dat is gelukt, we hebben nu applicaties die in een Kubernetes-landschap draaien en die met persistent data om kunnen gaan.”
De verdere doorontwikkeling van het GLP is gebaseerd op een microservices-architectuur, waarbij de gelaagdheid in de architectuur en het opdelen in componenten het uitgangspunt is. “We hebben de les wel geleerd van die grote monolieten, niet alleen als KVK maar volgens mij wel in het hele IT-landschap”, zegt Marcel. “Wij gaan uit van de clean-architectuurprincipes van Robert C. Martin, die onder meer staan op zijn Agile Manifesto.”
Eat your own dogfood
Ondertussen groeit het aantal interne en externe API-bevragingen van het Handelsregister ieder jaar sterk. De verwachting van KVK is dat als het de drempel hiervoor verlaagt, dit door kan groeien naar honderden miljoenen bevragingen op jaarbasis. Met een robuust en schaalbaar fundament moet dit mogelijk zijn. Marcel: “Begin 2021 starten we echt met het live zetten van een eerste resource, zoals we dat noemen. In eerste instantie gebruiken we het alleen intern voordat we het extern ook beschikbaar gaan stellen. Dit is deels vanuit het principe van ‘eat your own dogfood’, maar ook omdat andere teams hiervoor ruimte moeten vinden op hun ontwikkelkalender. Onze verwachting is dat dit in het tweede halfjaar van 2021 kan gebeuren.” Vanaf dat moment kan het snel gaan met het GLP, zegt Marcel. “Wij leveren Rest-endpoints, die applicatie-agnostisch zijn en die wij niet gaan veranderen. Alleen onder de motorkap zetten we een volledig andere architectuur waardoor onze afnemers er niks van merken.”
Het belang van de gegevens in het Handelsregister staat voorop, benadrukt Marcel. “De buitenwereld vertrouwt daarop. Als je twee databases aan het maken bent, moeten die wel zodanig gesynchroniseerd zijn dat we honderd procent zeker weten dat het dezelfde gegevens zijn. Daar moeten we scherp op zijn en dat is waarom we deze reis stap voor stap uitvoeren.” Ondernemingen en andere rechtspersonen in het register zullen straks profijt hebben van deze reis, denkt hij. “We willen het register straks een stuk toegankelijker maken zodat zij hun gegevens goed kunnen inzien. Een idee daarbij is dat zij sommige dingen die nu heel omslachtig zijn, zoals het uitwisselen van informatie met andere partijen, straks ook makkelijker kunnen regelen. Maar daarvoor hebben we wel een goede, echt schaalbare basis nodig. Dat is waar we nu hard aan werken.”
Hoge ambities, de focus op digitalisering, het interessante werkveld tussen privaat en publiek en de prettige werksfeer met behulpzame collega's maken KVK uniek als werkgever. Wil je meer weten waar je in deze organisatie als developer aan werkt? Bekijk dan ook de actuele vacatures.
Dit artikel is geen redactioneel artikel, maar een advertorial en tot stand gekomen dankzij KVK en Tweakers Partners. Dit is de afdeling binnen Tweakers die verantwoordelijk is voor commerciële samenwerkingen, winacties en Tweakers-events zoals Meet-ups, Developers Summit, Testfest en meer. Kijk hier voor een overzicht van alle acties en events. Mocht je ideeën met ons willen delen over deze vorm van adverteren, dan horen wij dat graag. Hierover kun je met ons in gesprek via [Discussie] Reclame algemeen].