Het ontwikkelen van software kan een complexe aangelegenheid zijn, zelfs als je alleen een feature of een bugfix wilt realiseren. Veel tijd, code en mankracht gaat zitten in algemene technologische problemen. Door microservices in te richten die onafhankelijk van elkaar werken, kun je veel sneller ontwikkelen. Lees hoe Portbase de monoliet heeft ontrafeld.
Portbase is de spin in het web van de Nederlandse logistiek. De non-profitorganisatie die in 2009 is opgericht verbindt alle partijen in de logistieke ketens van de Nederlandse havens. Portbase faciliteert het delen van data tussen bedrijven en informatie-uitwisseling met overheden om sneller, efficiënter en tegen lagere kosten te kunnen werken.
Zoals bij zo veel organisaties was de IT-architectuur van Portbase tot voor kort een echte monoliet: één kluwen van services die afhankelijk van elkaar waren. Dit oerwoud zorgde ervoor dat het ontwikkelen lang duurde en dat veel mensen tegelijkertijd de kar moesten trekken, waarbij gezamenlijke releases hooguit eens in de twee weken plaatsvonden. Portbase wilde hier verandering in brengen met autonome teams die verantwoordelijk waren voor bepaalde functionaliteiten zonder afhankelijk te zijn van andere teams, andere infrastructuur en de monoliet.
Eenvoudig services lanceren
René de Waele ging als Lead Software Engineer in 2018 met zijn team (en later met andere teams) aan de slag om deze transitie te realiseren. "Het uitgangspunt daarbij was dat we niet alleen de software schaalbaar maakten maar ook dat iedere afdeling kon focussen op domeinaspecten, ofwel business rules in plaats van puur met de techniek bezig te zijn in de code. Kortom, in je code alleen zaken opschrijven zoals je ze wilt hebben."
De basis voor de oplossing was een tool die De Waele eerder had ontwikkeld: Flux Capacitor. "Een monoliet inruilen voor microservices is aantrekkelijk, maar de communicatie tussen de services is een flinke uitdaging," vertelt hij. "Dankzij Flux Capacitor is het uitwisselen van berichten tussen applicaties en het lanceren van nieuwe services een stuk eenvoudiger. Heb je een service gelanceerd, dan kan die met iedere andere service communiceren die verbonden is."
Oerwoud van end points
Hoe hebben René en zijn team dit gerealiseerd? "Als je teruggaat naar de basis en bekijkt wat een applicatie nu echt doet, kun je drie zaken onderscheiden. Commands zijn de verzoeken aan de applicatie, bijvoorbeeld: ik wil een nieuw bezoek van een schip aanmelden. Queries zijn vragen, in dit geval bijvoorbeeld: geef me alle bezoeken van dit ene schip. Vervolgens zijn er Side effects, bijvoorbeeld het op de hoogte stellen van de haven of de douane dat het schip is aangemeld. In een dynamische omgeving waarin dit soort berichten in grote aantallen worden uitgewisseld en waarin betrouwbaarheid essentieel is, werkt de traditionele manier omslachtig. Zo worden services vaak meerdere keren aangeroepen, waardoor een load balancer nodig is om de zaak in goede banen te leiden. Doordat je steeds meer end points hebt, wordt de infrastructuur nodeloos ingewikkeld, waarbij al die end points ook nog eens beveiligd moeten worden. Een gespecialiseerd team van cloud engineers moet zich met deze zaken bezighouden en dan moet je je product nog lanceren."
Microservices
Dit is te voorkomen door de queries en commands af te laten handelen door een centrale message broker. De verschillende microservices zijn niet aan elkaar geknoopt en zijn geen van alle direct op het internet aangesloten. "Het zijn geen applicaties waar je naartoe kunt gaan in je browser. Dat betekent ook dat ze minder kwetsbaar zijn voor aanvallen van hackers. De message broker begrijpt bovendien helemaal niets van de berichten, maar slaat alleen op welke queries en commands worden afgehandeld. De message broker kan ook voor de load balancing zorgen. Bovendien kunnen we precies volgen wat er gebeurt. Niet alleen de events, maar ook alle inkomende API-verzoeken, alle berichten die binnenkomen, welke browser werd gebruikt enzovoort. Bij Portbase hebben we nu tientallen microservices gecreëerd die helemaal onafhankelijk van elkaar de logs uitlezen."
Applicatie testen met gemak
Ook het testen gaat nu veel eenvoudiger en levert veel betere resultaten op. "Als je verschillende services wilt testen, is dat vaak een lastig proces. Je moet een testomgeving creëren met een database, verschillende services en een netwerkverbinding. Doordat dit omslachtig en foutgevoelig is, wordt in de praktijk zelden het functionele gedrag van de applicatie als geheel getest. Wij zijn bij het testen geïnteresseerd in het gedrag van de hele applicatie. Dat willen we constant testen, zonder dat we hoeven te weten hoe de applicatie dat voor elkaar krijgt. Zo hebben we al onze tests geschreven."
Backlog bijna leeg
Inmiddels zijn de belangrijkste applicaties helemaal los van de monoliet. "De transitie heeft per applicatie niet meer dan zes maanden geduurd en kon met een tiende van het aantal regels code vergeleken met de oude situatie. Het komt er dus op neer dat 90 procent van de applicatie puur uit techniek bestond. In plaats van twee keer per maand live gaan met een nieuwe versie kan dat nu vijf tot tien keer per dag. We gaan nu met verschillende teams zelfs zo'n honderd keer per dag live, steeds met echte features." Ondanks dat zo veel nieuwe zaken live worden gezet, zijn er veel minder problemen. “Voordat we begonnen, had het team een flinke backlog en het groeide sneller dan dat het afnam. Na de transitie van zes maanden was de backlog vrijwel helemaal leeg."
