Bij NS draait software delivery op schaal, met honderden teams, meerdere techstacks en strenge security- en compliance-eisen. Daarom bouwt NS met een developer-platform aan het verbeteren van de developer experience. Met platform engineering worden herbruikbare CI/CD-bouwblokken geleverd; teams krijgen daarmee snelheid en autonomie, en tegelijkertijd borgen ze kwaliteit en veiligheid.
In het webinar ‘Tweakers op Stoom’ laten CoE Lead Developer Experience Bas Vegter en CI/CD engineer Johan Veenstra zien hoe die aanpak in de praktijk werkt. Effectief, veilig en efficiënt software leveren is essentieel voor iedere organisatie, zo ook bij NS. Meld je nu alvast aan voor het webinar op 11 maart aanstaande, onderaan de pagina.
Bij NS moeten digitale systemen betrouwbaar draaien, terwijl teams blijven ontwikkelen en verbeteren. Dat vraagt om software delivery die snel en aantoonbaar veilig en compliant is.
IT-banen bij de NS
Twee mensen die daar bij NS dagelijks aan werken, zijn Bas Vegter (CoE Lead) en Johan Veenstra (CI/CD-engineer). Zij werken binnen de centrale platformorganisatie aan wat ze zelf zien als de fundering onder moderne softwareontwikkeling bij NS. Bas werkt sinds 2020 bij NS en heeft ruim achttien jaar ervaring in IT. Hij geeft leiding aan het Center of Excellence developer experience. “Wij leveren IT voor IT”, zegt hij. “We ondersteunen alle software development-teams, om businesswaarde te leveren voor NS, en daarmee uiteindelijk voor de reiziger. Wij bouwen de fundering waar die teams op werken.”
Portal als gezicht van het platform
Een paar jaar geleden startte NS vanuit twee thema’s die nu de basis vormen voor de platform-engineering-strategie. Enerzijds de Tech Stacks - de belangrijkste technologiestacks binnen NS, zoals .NET, Java, SAP, Mendix, mobile en data science, en anderzijds de Developer Journey - het end-to-end pad dat developers doorlopen, van idee en code tot een veilige productierelease.
“Met de Developer Journey zijn we begonnen aan het end-to-end delivery proces”, vertelt Bas. “Wat is het developmentproces dat developers doorlopen, en welke capabilities hebben ze daarbij nodig? Niet zozeer persoonlijke skills, maar tools. Welke middelen heb je nodig om die journey soepel te doorlopen?”
Omdat NS meerdere stacks heeft, ziet de journey er per domein net anders uit. High-code, SAP, Mendix en mobile apps kennen andere tooling, pipelines en randvoorwaarden. Juist die diversiteit maakt een ‘one-size-fits-all’-platform lastig, en het verklaart waarom NS inzet op platform engineering met herbruikbare bouwblokken.
De ambitie krijgt bij NS vorm in een Developer Portal: één plek waar uiteindelijk documentatie, services, templates en selfservice-acties samenkomen. Denk aan het aanvragen van toegang, het genereren van standaard pipeline-templates, en het provisionen van cloudresources.
“De portal is het gezicht van het platform”, zegt Bas. “Maar het platform is breder. Eronder zitten de pipelines, infrastructuur, securitychecks en alle bouwblokken die developer experience mogelijk maken.”
Kentering in CI/CD: van ‘één standaardpipeline’ naar pipeline bricks
Waar Bas vooral de visie en de koers neerzet, zit Johan dieper in de techniek. Hij werkt als CI/CD-engineer in het Center of Excellence en bouwt met zijn team aan modulaire pipeline-bouwstenen: pipeline bricks.
“Toen ik eind vorig jaar in het CI/CD-team stapte, stond er al een ‘standaard pipeline’”, vertelt hij. “In theorie mooi, in de praktijk te complex. We hebben heel veel verschillende tech stacks, teams die anders willen werken, en verschillende typen applicaties. Eén pipeline waar iedereen doorheen moet, werd gewoon heel lastig.” De teams moesten gebruikmaken van een complexe monolithische pipeline die ze configureren. De oplossing: modulariteit. Zo gebruikt NS kleine, herbruikbare blokken die elk één taak goed uitvoeren: build, tests, securityscan, deployment, performance-test, enzovoort. Die bricks zijn geversioneerd, getest en voldoen aan architectuur- en securityrichtlijnen.
:strip_exif()/i/2008000630.jpeg?f=imagenormal)
Veelgebruikte combinaties worden aangeboden als brick sets; dus meerdere bricks samen. Het voornaamste voordeel hiervan is dat je sneller een pipeline kunt samenstellen en minder vaak jezelf hoeft te herhalen, wat onderhoud reduceert.
Johan: “Dat doen we met bouwstenen die getest en compliant zijn. We zijn er nog niet, maar voor alle verschillende stukken van het voortbrengproces hebben we nu blokken.”
Een voordeel van die opzet: bricks zijn te vervangen zonder alles om te gooien. “We zien nu al dat de eerste blokken worden uitgefaseerd”, legt Johan uit. “Als een blok niet meer voldoet, zetten we een verbeterde versie ernaast, migreren we teams en halen we de oude er rustig uit.”
Obstakels: tooling die niet schaalde en adoptie die niet vanzelf gaat
Die omslag ging niet zonder lessen. Eén van de eerste zat in de toolingkeuze. “We hadden bijvoorbeeld een dependency checker gekozen”, zegt Johan. “In eerste instantie leek dat goed te werken. Maar zodra je schaal bereikt en tientallen of honderden pipelines per dag draait, merk je dat de tool het niet trekt. Downtime, onstabiel gedrag; dat gaat developers direct pijn doen.”
Feedback uit teams vormt dan de graadmeter: “Je hoort ‘dit werkt niet, dat werkt niet’. Dan weet je: deze tool past niet meer bij wat we nodig hebben.” Daarom hanteert NS nu een explicieter toolselectieproces:
- Capabilities definiëren: wat moet de tool kunnen (bijv. SAST, dependency-scans, secrets-detectie, DAST, performance-tests)?
- Onderzoek & hackathons: tools vergelijken, proefopstellingen bouwen, integraties testen.
- Pilot & adoptie: integreren in een brick en met enkele teams uitproberen.
- Monitoring & feedback: stabiliteit, functionaliteit én kosten bewaken.
“Als we structureel negatieve feedback krijgen op één brick, weten we dat die brick moet worden vervangen”, zegt Johan. “Omdat we modulair werken, kan dat gericht.”
De tweede uitdaging is minder technisch en draait om migratie en gedrag. “Teams hebben werkende pipelines. Dan is er niet automatisch een drang om over te stappen, ook al is het nieuwe platform beter”, zegt hij. Vaak ontstaat pas druk als compliance-eisen veranderen en oude pipelines niet meer voldoen. Dan moet je als organisatie teams meenemen, voordelen zichtbaar maken en duidelijk maken dat ‘het werkt nog’ niet hetzelfde is als ‘het is nog verantwoord’.
Tijdwinst door standaardisatie en selfservice, maar altijd veilig
Het doel ‘binnen één dag van idee naar productie’ klinkt ambitieus, maar Bas vindt het haalbaar; vooral voor kleinere changes en nieuwe services, zolang de keten ver genoeg is geautomatiseerd. De winst zit vooral in wat teams niet meer hoeven te doen. “Vroeger moest je een hoop zelf uitzoeken en weten”, zegt Bas. “Wil je compliant zijn, dan moet je integreren met securitytools, dependency-scanners, approvals, noem maar op. Dat kostte veel tijd: uitzoeken, coderen, valideren.”
Nu worden veel van die onderdelen als bouwsteen aangeleverd. “We leveren het als brick. Die zet je in je pipeline en je bent compliant. Dat scheelt dagen uitzoek- en implementatiewerk.”“We leveren het als brick. Die zet je in je pipeline en je bent compliant. Dat scheelt dagen uitzoek- en implementatiewerk.”
Daarnaast haalt selfservice wachttijd uit het proces. Een licentie aanvragen, toegang regelen of cloudresources provisionen: “Vroeger stuurde je een mail of maakte je een ticket aan en moest je wachten op een reactie”, aldus Bas. “Nu ga je naar het portaal en krijg je binnen een paar minuten bericht dat het geregeld is. Dat scheelt enorm veel wachttijd.”
Ook in de runtime van pipelines zit winst. “We hadden een securityscan die eerst vijf tot tien minuten duurde”, vertelt Johan. “We hebben die tijd teruggebracht naar onder de minuut. Als je dat opschaalt naar zo’n tweehonderd teams met tientallen tot honderden builds per dag, praat je over uren per dag die je als organisatie terugpakt.”
Sneller naar productie mag niet betekenen dat er meer risico op fouten ontstaat. Bij NS is security juist een belangrijke drijfveer achter de platformaanpak. “Het voelt misschien tegenstrijdig: snelheid en security”, zegt Bas. “Maar juist daarom standaardiseren we. Om compliant te zijn, moet je veel dingen goed doen, in code én in architectuur. Wachtwoorden horen bijvoorbeeld niet in je code, maar in een key vault. Dat kun je handmatig valideren, of je automatiseert het en krijgt feedback bij elke build.”
Die snelle feedback sluit aan op het DX-raamwerk dat NS gebruikt: Flow, Feedback en Cognitive Load. “Met name feedback is hier cruciaal”, zegt Bas. “Je wilt vanuit de pipeline zo snel mogelijk feedback op bijvoorbeeld je security. Daarmee voorkom je dat je er pas achter komt bij een audit of red-team-test en alles achteraf moet repareren.”
In de bricks zitten daarom standaard checks en integraties met tools voor onder meer codekwaliteit, secrets-detectie, DAST en performance-tests. Johan noemt bijvoorbeeld:
- SonarQube voor statische analyse en quality/security rules
- Gitleaks voor secret scanning
- Owasp ZAP voor dynamische tests (DAST)
- Artillery en JMeter voor load- en performancetests
“Normaal moet je als team zelf uitzoeken hoe je die tools goed configureert”, zegt Johan. “Wij doen dat één keer goed, vangen het in een brick en bieden die aan. Teams roepen ’m aan met één regel in hun pipeline, en klaar.”
Dit mogen kijkers verwachten in het webinar
In het Tweakers op Stoom-webinar maken Bas en Johan de vertaalslag van ‘platform engineering’ naar praktische uitvoering. Bas schetst de Developer Journey en hoe dat uitmondt in een developer platform Bas schetst de Developer Journey en hoe hij uitmondt in een developer platform
met selfservice. Johan laat in een demo zien hoe een pipeline is opgebouwd uit bricks, hoe je een brick met één regel aanroept en wat het verschil is tussen ‘oude’ en ‘nieuwe’ pipelines in snelheid en feedback. Ook toont hij een concreet before/after-voorbeeld van het optimaliseren van een zware scan. “Wat ik demonstreer, is wat onze teams in productie gebruiken”, zegt hij.
Voor wie is het interessant? Voor platform engineers die aan interne developer platforms bouwen, cloud engineers en SRE’s die automatisering op schaal regelen, developers en tech leads die worstelen met complexiteit en compliance, en architecten die willen zien hoe high-level keuzes landen in concrete bouwblokken en pipelines. En voor de tweaker die misschien iets minder onderlegd is in deze materie belooft de webinar een kijkje in de keuken van een grote, complexe IT-organisatie die niet alleen over platform engineering, CI/CD en security by design praat, maar het daadwerkelijk in de praktijk brengt.
Overigens zal serverless software engineer Didi de Jong in de tweede helft van het webinar dieper ingaan op de vernieuwde prijsstrategie van NS voor treinkaartjes. Dat gebeurt met een serverless inventarissysteem dat realtime capaciteit en prijzen per trein inzichtelijk maakt. Hierdoor kunnen kortingen voor specifieke treinen op bepaalde tijden worden aangeboden, om drukte te spreiden. Didi vertelt in het webinar hoe NS van een stateless microserviceslandschap is overgestapt naar een event-gedreven, stateful oplossing op AWS. Binnenkort lees je er op Tweakers meer over, in een interview met Didi.
Meld je aan voor het webinar Tweakers op Stoom
Het webinar vindt plaats op 11 maart, start om 19.00 en duurt ongeveer anderhalf uur. Er is ruim voldoende tijd om inhoudelijke vragen te stellen, zodat je alle ins & outs meekrijgt. Meld je hier aan voor het webinar ‘Tweakers op Stoom’.
Aanmelden Tweakers op Stoom NS webinar
Dit artikel is geen redactioneel artikel, maar gesponsord en tot stand gekomen dankzij NS en Tweakers Partners. Tweakers Partners is de afdeling binnen Tweakers die verantwoordelijk is voor commerciële samenwerkingen, winacties en Tweakers events zoals meet-ups, Developers Summit, Testfest en meer. Bekijk hier het 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].