Dankzij de nieuwe schaalbare en toekomstbestendige oplossing heeft de NS indrukwekkende stappen gemaakt in de fietsdeelmarkt. In dit blog delen we de technologische keuzes en architectonische beslissingen die we hebben gemaakt om tot dit digitale platform te komen.

Het digitale platform van OV-fiets is onlangs genomineerd voor een Dutch Interactive Award (DIA) in de categorie digitale transformatie.

Het startpunt van onze reis

Het oorspronkelijke fietsmanagementplatform van OV-fiets bestond uit functionaliteit die onafhankelijk door verschillende partijen werd beheerd. Het systeem was lastig om mee te werken en het bood de NS geen eenvoudige manier om de fietsen te beheren en data te analyseren. INFO werd ingeschakeld om de pijnpunten te identificeren, het nieuwe platform te ontwikkelen en de gebruikerservaring voor NS-medewerkers te verbeteren. Kortom: het nieuwe platform moest ervoor zorgen dat de juiste informatie op het juiste moment beschikbaar was om het OV-fietsverhuurproces te vergemakkelijken. Zo kan NS de OV-fiets gebruiker van een optimale ervaring blijven voorzien.

Technische visie voor een stralende toekomst

Om het bestaande platform te transformeren, kozen we voor een architectuur gebaseerd op microservices. Dit waren onze belangrijkste redenen om voor microservices te kiezen:

• Het vereenvoudigen van de architectuur door duidelijke grenzen, verantwoordelijkheden en interacties tussen diensten te definiëren.
• Het vergroten van de betrouwbaarheid en fouttolerantie, door diensten zo te isoleren dat het platform altijd blijft presteren, zelfs als sommige diensten niet beschikbaar zijn.
• Het verbeteren van schaalbaarheid, door te concentreren op de diensten die mogelijk extra middelen nodig hebben of in de loop van de tijd meer groei ervaren.
• Snellere delivery, door agile product development te combineren met kleinere, meer gecontroleerde deploys, waardoor risico’s worden verminderd.
• Flexibiliteit in technologie omdat we verschillende technologie stacks per microservice kunnen toepassen.

Het nieuwe digitale platform is ontworpen met een duidelijk doel voor ogen: functionality providers onafhankelijk houden van clients. Dit onderscheid stelde ons in staat om best practices per geval toe te passen en tegelijkertijd een grote flexibiliteit te bieden op het gebied van connectiviteit.

Verander, maar maak niks kapot

Na het vaststellen van het doel en het bepalen van de technologische visie, moesten we rekening houden met een andere uitdaging: achterwaartse compatibiliteit. Het migreren van zo’n groot platform, met alle complexiteit en afhankelijke processen en interacties, naar een op microservices gebaseerde architectuur is niet eenvoudig. Zeker niet als niet alle partijen de middelen hebben om in hetzelfde tempo mee te gaan. Dit betekende dat we ervoor moesten zorgen dat de data en flows in het nieuwe platform na de migratie compliant waren en zich hetzelfde gedroegen als voorheen.

Als we het over achterwaartse compatibiliteit hebben, is het uiterst belangrijk om kritisch en analytisch te zijn en te blijven. We kijken kritisch naar bestaande procedures en samen beslissen we wat moet blijven en wat veilig kan worden veranderd. Zo kunnen we waarborgen dat de migratie alleen dat meeneemt wat noodzakelijk is, zonder onnodige bagage. Maar hoewel dat helpt, is het niet genoeg.

In situaties waar het systeem precies hetzelfde moet werken als voorheen, hangt de aanpak af van de levensduur van de componenten. Voor componenten met een lange levensduur is het creëren van diensten die fungeren als interfaces of adapters de juiste keuze. Voor componenten die snel worden vervangen, helpen technieken zoals API-versiebeheer en feature-switches bij de ontwikkeling en verbetering van het platform.

Meer diensten, meer communicatie, meer uitdagingen

Gaandeweg hebben we nieuwe diensten aan het platform toegevoegd. De evolutie van het domeinmodel bracht nieuwe uitdagingen naarmate er meer en meer ongeplande interacties tussen componenten opdoken. Als je met een modificerende API op basis van microservices werkt, is het belangrijk om te bepalen of alle bijwerkingen van een API-oproep kunnen worden verwerkt door één unieke module of afhankelijk zijn van andere, en hoe dat past binnen niet-functionele vereisten zoals de reactietijd.

De uitdaging ontstaat wanneer je zowel snel als zeker moet reageren, terwijl je te maken hebt met gegevens die mogelijk inconsistent zijn. Je moet kiezen of delen, maar je hebt natuurlijk wel controle over hoe je gegevens deelt. API-bewerkingen moeten mogelijk verder worden opgesplitst in taken die afhankelijk zijn van 100% gegarandeerde gegevens en taken die kunnen worden uitgesteld zonder de gebruikerservaring te beïnvloeden.

De OV-fiets smart lock

Een belangrijke ontwikkeling dit jaar was de introductie van OV-fiets Connect (OVFC), een nieuwe manier om fietsverhuur aan klanten aan te bieden. Klanten kunnen de huurfiets van het slot halen door hun eigen OV-chipkaart op het slot te plaatsen, een sleutel is niet meer nodig.

Dit nieuwe product brengt nieuwe manieren van interactie met het platform en introduceert ook tal van variaties op veel processen in vergelijking met het traditionele OV-fiets slot. We ontwikkelden nieuwe componenten om deze nieuwe processen te faciliteren. Hoewel de gebruikerservaring anders is – net zoals de interface tussen de hardware en het platform – zijn er vanuit een domeinoogpunt veel overeenkomsten tussen het legacy-product en het OVFC-product. Een fiets is tenslotte een fiets.

Voor de NS-medewerker was het belangrijk dat de data uit die twee heterogene bronnen samen werd gebracht en op dezelfde vertrouwde manier werd gepresenteerd. Ze gebruiken de data om het fietspark te beheren en de klant optimaal te bedienen.

Voor de NS-klant was er de behoefte om beide diensten op een volledig compatibele manier te gebruiken zonder het leven van de klant onnodig moeilijk te maken.

Als developers werden we uitgedaagd om gegevens consistent te houden tussen verschillende modules, zonder de latency van bewerkingen te beïnvloeden.

Dit gecombineerd was de aanleiding om event streaming in de architectuur te introduceren. Op deze manier kan een willekeurig aantal microservices zich eenvoudig abonneren op specifieke gebeurtenissen in een bepaald domein en onafhankelijk reageren, terwijl de gegevens consistent zijn.

Was een microservices-architectuur de beste keuze?

Wij zijn ervan overtuigd dat het gebruik van microservices hier de juiste keuze was. We hebben geprofiteerd van tal van voordelen die worden bepleit door microservice-architecturen:

• We kunnen eenvoudig en individueel per omgeving (OTAP) en per microservice schalen.
• Implementatiecycli zijn drastisch verminderd.
• We kunnen resources afzonderlijk per microservice inzetten, waardoor we efficiënter met resources omgaan.
• De betrouwbaarheid is toegenomen, ondanks de groei van het aantal transacties van NS OV-fiets.
  
• We gebruiken verschillende technologieën op basis van de behoeften van elke microservice. Hoewel we de voorkeur geven aan de Java & Spring Boot-stack, gebruiken we ook standaard Java, React, .NET en zelfs standaard C, waar deze technologieën beter passen.

Aan de andere kant zijn er ook aspecten die de overhead aanzienlijk zouden kunnen verhogen. Als we bijvoorbeeld kijken naar teamgrootte, brengt deze aanpak extra complexiteit die niet loont in termen van het splitsen van teams per microservice.

Klaar voor de toekomst

De digitale omgeving van NS OV-fiets is nu modern, schaalbaar en toekomstbestendig. Door het nieuwe digitale platform is OV-fiets gegroeid van 4,2 naar 5,2 miljoen ritten in 2019 en samen zorgen we ervoor dat de toekomstige vraag soepel verloopt.

“Met deze digitale transformatie hebben we legacy-systemen achter ons gelaten en zijn we uitgegroeid tot een toekomstbestendig platform. Samen met INFO blijven we innoveren om onze reizigers de best mogelijke OV-fietservaring te bieden ” – Marise Bezema, Manager Services NS-Stations