In deze blog vertelt Ralph Hees -Java ontwikkelaar bij PinkRoccade Publiekzaken- meer over hoe wij connecties optimaliseren met iBurgerzaken. Lees snel verder.
In de laatste blog van Ron van den Enden spreekt Ron over de introductie van de API manager om informatie uit te wisselen met onze burgerzaken applicatie en deze te gebruiken in een apart Common Ground component.
In de komende jaren zullen er steeds meer verschillende componenten worden gemaakt door meerdere marktpartijen en moet er met steeds meer applicaties een verbinding worden gelegd.
Het Common Ground 5 lagen model bevat vele componenten en we gaan dus langzaam van 1 component per laag naar vele componenten per laag. Dit zorgt voor een steeds complexer wordend landschap. Elke verbinding heeft onder andere SSl certificaten, authenticatie, autorisatie en protocollering. Dit zijn enkele onderdelen die vallen in het security model, waar Ron eerder over sprak.
De eerste onderzoeken naar een gateway om alle verbindingen naar buiten te kunnen beheren zijn gedaan. Hierbij zijn de eenvoud van configuratie, (snelheid van)wijzigingen, uitrol, hoge uptime, gedetailleerde logging en notificaties van toekomstige problemen de belangrijkste eisen. De logging van alle componenten is voor alle afdelingen van ons bedrijf belangrijk om jullie incidenten en bugs snel te kunnen onderzoeken. Daarnaast willen wij de betrouwbaarheid van onze verbindingen omhoog brengen met notificaties naar beheerders als certificaten dreigen te verlopen.
De WSO2 micro integrator werd ook al gebruikt in andere businessunits van ons bedrijf. De eerste tests waren daarbij super. Alle functionaliteiten die wij erin wilden bouwen, waren mogelijk. De performance was veel sneller dan wat wij gewend waren én de integrator gebruikte minder resources van de computer.
Voor het minimum viable product (dit bevat alle functionaliteiten die nodig zijn om het product te kunnen gebruiken), hadden wij de iBrondocumenten koppeling, de JCC kassa koppeling en de SMS koppelingen uitgekozen. De bouw liep niet zo soepel want we liepen tegen veel problemen aan en dit kostte veel tijd. Net voordat wij naar de acceptatie omgeving wilden gaan is er een loadtest uitgevoerd. Een loadtest is een eigen gebouwde applicatie, die het product beproeft. Voor deze loadtest zijn aantallen van verzoeken van meerdere grote gemeenten bij elkaar opgeteld om per koppeling een representatief getal op te stellen. Na de uitvoer van de test, kwam naar voren dat het resource gebruik bij die aantallen toch sterk afweek van de eerste testen die zijn gedaan. Het geheugen gebruik liep op naar 2 gigabyte, in plaats van de 500MB die wij in gedachte hadden. Tijdens een overleg werd de keuze snel gemaakt; deze oplossing wordt 'on hold' gezet om andere mogelijkheden uit te proberen.
Een aantal weken geleden zijn wij gestart met de proberen van de 2e optie: de Spring Cloud Gateway. De bouw liep gestaag en binnen enkele uren stond er een basis waarop de loadtest uitgevoerd kon worden. Dit was al een zeer grote verbetering ten opzichte van de vorige proef. Voor de eerste proef is een loadtest gebouwd om de capaciteiten te testen. Deze kon zonder aanpassingen direct gebruikt worden om het nieuwe product te testen. Wij hadden op deze manier al snel vergelijkingsmateriaal. 200 MB geheugen, dan is een factor 10 beter dan in de eerste proef. Dus dat is een zeer succesvol proeftraject.
Het geheugengebruik van de tweede oplossing is dus 10 keer zo laag als van de eerste. Wij verwachten ongeveer 20 keer zo laag als het product dat nu op productie wordt toegepast. Door de overgang naar het nieuwe product kunnen wij dus geld en CO2-uitstoot besparen. En door proactieve monitoring en betere zoekmogelijkheden zijn wij in staat om onze gemeenten beter en sneller helpen. Een win-win situatie dus.
De komende maanden werken we hieraan verder en hopen we tegen het einde van het jaar het product klaar te hebben om te gaan gebruiken.
Heb je vragen naar aanleiding van mijn blog? Stuur mij dan een e-mail via: Ralph.Hees@PinkRoccade.nl.
