RedHat als basis voor Hybride Integratie Platform maakt NS datagedreven

Denk je aan de trein, dan denk je aan de NS. Bij de belangrijkste OV-dienstverlener van Nederland speelt IT een allesbepalende rol. Op dat vlak bevindt het bedrijf zich momenteel in een omvangrijke transitie; op basis van het nieuwe Hybride Integratie Platform (HIP) moet het een datagedreven organisatie worden. In dit artikel licht Product Owner Strategische Ontwikkeling Jack Fleuren de verschillende technieken achter het platform toe. Ze komen ook aan bod in het webinar op 11 oktober, waarvoor je je onderaan dit artikel kunt aanmelden.

Voor veel mensen staat de NS vooral voor de gele treinen die ze van A naar B brengen, maar de landelijke organisatie is voor veel meer verantwoordelijk. IT speelt in alle processen een hoofdrol. De organisatie is afhankelijk van goede en betrouwbare IT om de treinen te laten rijden, reisinformatie te geven en onderhoud aan de treinen te kunnen uitvoeren. Maar ook bij het beheer van lockers, de verhuur van OV-fietsen, het zorgdragen voor de veiligheid van reizigers en de inzet van drones voor bouwkundige inspecties en controle op graffiti speelt technologie een sleutelrol. Zelfs een goede kop koffie wordt verkocht met behulp van IT. Op dit moment verwerkt de NS ruim 1 miljard api-aanroepen per maand, wat neerkomt op ongeveer 600 aanroepen per seconde. Niet alleen de hoeveelheid data is snel toegenomen; dat geldt ook voor het aantal applicaties dat de NS-organisatie breed gebruikt. De infrastructuur is daar niet langer op ingericht. Daarom bereidt het bedrijf zich voor op de overstap naar een centraal platform waar alle data-uitwisseling straks op moet plaatsvinden. Het doel van dit Hybride Integratie Platform (HIP) is duidelijk: het moet van de NS een datagedreven organisatie maken.

Jack Fleuren was als kind al gek van IT (“Ik bouwde als tiener websites als bijbaantje”). Zijn professionele carrière begon in de bankensector, bij de Volksbank. Daar vervulde hij verschillende rollen en fungeerde hij als brug tussen business en IT. Hij begon met het beheren van toegangsrechten tot systemen, wat een cruciale functie bij financiële instellingen is. Vervolgens werkte hij als releasecoördinator en groeide hij van junior projectleider door tot senior projectleider en programmamanager in IT. Hij heeft aan verschillende projecten gewerkt, variërend van klantgerichte systemen tot backend implementaties van omvangrijke belastingwetgeving. Na zijn tijd in de bankensector stapte Jack over naar consultancy en werkte hij bijna drie jaar bij ASML. Daar hielp hij bij het opbouwen van een digitaal platform om machinegegevens te verwerken. Inmiddels werkt hij ruim twee jaar voor de NS.

Jack bevindt zich nu midden in de transitie van het bedrijf. “Om onze processen uit te voeren, versturen we miljarden berichten per jaar tussen partijen en applicaties. Hiervoor gebruiken we een integratieplatform, en we zitten nu in de overgang naar een nieuw Hybride Integratie Platform. Hierbij worden data-uitwisselingen op een gestandaardiseerde wijze NS-breed gefaciliteerd en zorgen we dat dit op een snelle, veilige en betrouwbare manier gebeurt.”

Twee voorbeelden zijn data-uitwisseling voor bijsturingsapplicaties en sensordata op treinen. “Wanneer er dingen op het spoor gebeuren waardoor de oorspronkelijke dienstregeling niet kan worden uitgevoerd, worden mutaties uitgewisseld via het Hybride Integratie Platform om zo tot een nieuw plan te komen. Hierbij moet je denken aan de inzet van ander materieel en het herplannen van conducteurs en/of machinisten. Het Hybride Integratie Platform wordt ook gebruikt om sensordata van de trein in applicaties te krijgen. Zo weten we bijvoorbeeld wat de gps-locatie van een trein is, of dat er al dan niet preventief onderhoud moet worden uitgevoerd.”

Hybride Integratie Platform

Waarom is het tijd voor een nieuw HIP? Jack: “Ten eerste was onze huidige integratieoplossing verouderd en zou hij binnenkort niet meer worden ondersteund. Dat dwong ons te overwegen wat onze volgende stap zou zijn. We konden bij dezelfde platformleverancier blijven en hun nieuwste versie kiezen, maar we kwamen tot de ontdekking dat dit zou betekenen dat we alles opnieuw moesten opbouwen. Als een volledige herbouw nodig was, was het logisch om ook andere opties te verkennen.”

“Bovendien is het applicatielandschap binnen de NS aan het veranderen en wordt het gemoderniseerd. Dit zorgt ervoor dat we andere eisen stellen aan onze integratieoplossingen. Met de toename in de hoeveelheid sensordata hebben we te maken met een veel hogere frequentie en grotere datavolumes dan tien of vijftien jaar geleden, toen we met onze huidige oplossing begonnen. Trends zoals devops, waarbij teams decentraal integraties kunnen bouwen, passen niet in onze oude oplossing. Met het nieuwe, gecontaineriseerde platform kunnen ontwikkelteams deze verantwoordelijkheid wél nemen.”

Hoe zit het Hybride Integratie Platform in elkaar? Het platform is gebaseerd op verschillende opensource technologieën met enterprise-ondersteuning van RedHat:

• Kubernetes (RedHat Openshift) - Containertechnologie als fundament om integraties te ontwikkelen, een enabler om devops te kunnen ontwikkelen.
• Camel (RedHat Fuse) - Framework om databewerking of -vertaling uit te voeren.
• ActiveMQ (RedHat AMQ Broker) - Message broker om asynchrone uitwisseling te faciliteren.
• Skupper (RedHat Service Interconnect) - Transparant netwerk dat integratieknooppunten met elkaar verbindt.

Het platform is gebaseerd op drie protocollen. HTTP, MQTT 5.0 en het berichten-queueing-protocol AMQP 1.0 zorgen daarbij voor het verzenden van berichten. Jack: “Deze protocollen zijn specifiek gekozen voor het HIP omdat ze aansluiten bij de drie kernwaarden van het platform: standaardisatie, uniformiteit en flexibiliteit. De protocollen hebben al een hoge adoptie en kunnen bovendien eenvoudig met verschillende systemen worden gebruikt. Dat moet het platform toekomstbestendig maken.”

Tijdens het aankomende webinar Tweakers op Stoom (zie onderaan deze tekst) zal Jack dieper ingaan op hoe de api van het nieuwe platform werkt en waarom bij het HIP is gekozen voor het opensource framework RedHat Fuse.

Data, data, data

Jack ziet dat de NS langzaam verandert in een allesomvattend mobiliteitsplatform. Dit betekent dat integratie een nog belangrijker element zal worden. “Het doel is om andere dienstverleners aan het NS-platform te koppelen. Zo kunnen reizen nu al worden gepland met bijvoorbeeld deelscooters, via de NS-app. Hierdoor kan de NS niet alleen treinreizen aanbieden, maar een complete reis van deur tot deur realiseren. Deze scooters kun je makkelijk achterlaten op een aangewezen plek in de buurt en ze weer ophalen wanneer je ze nodig hebt.”

Tegelijkertijd heeft de NS te maken met een personeelstekort. “Dit gaat niet veranderen, aangezien de samenleving veroudert”, zegt Jack. “Om het aan te pakken, moet de NS slimmer werken met minder mensen, en IT is een cruciaal onderdeel hiervan. Om slimmer te werken, is informatie en data nodig, niet alleen uit het systeem waarmee je werkt, maar ook uit andere cloudapplicaties of datacenters.” Jack illustreert dit met een voorbeeld: “Bij het plannen van het rooster van de treinmachinisten moet je ervoor zorgen dat je weet dat de machinisten over de nodige kwalificaties beschikken om bepaalde treinen en routes te bedienen. Deze informatie is wellicht niet opgeslagen in je planningssoftware, maar wel in het HR-systeem. Dit is slechts één voorbeeld van gegevensuitwisseling die moet plaatsvinden. Bovendien moet je, als een trein vertraging oploopt, mogelijk roosters aanpassen en de dienstkaart van de machinist bijwerken. Dit vereist coördinatie tussen verschillende teams en systemen.”

Ook rijdende treinen zorgen voor waardevolle data. “De precisie van sensordata verbetert voortdurend, wat leidt tot een groeiende hoeveelheid gegevens. Het is interessant om te overwegen hoe we deze data nu gebruiken en hoe we ze in de toekomst kunnen inzetten. Enkele jaren geleden waren bepaalde toepassingen misschien ondenkbaar, maar nu worden ze werkelijkheid. Zo zijn we nu aan het experimenteren met CO₂-sensoren in toiletten. Het idee is om op basis van deze data te bepalen of een toilet moet worden schoongemaakt. Een ander voorbeeld is de drukte-indicator in de reisplanner, die het gewicht van een treinwagon meet. Dankzij sensoren, of ze nu het gewicht van passagiers meten of de luchtkwaliteit in de wagon, kunnen we inschatten hoe vol een trein zit. Deze informatie is weliswaar nog niet volledig realtime, maar kan ons inzicht geven in patronen. Als een trein bijvoorbeeld regelmatig overvol blijkt, zou het toevoegen van een extra wagon een oplossing kunnen zijn. Dit kan weer leiden tot aanpassingen in de dienstregeling.”

NS als IT-werkgever

Wat maakt de NS uniek als IT-werkgever? Wat vindt Jack fijn aan zijn huidige job? “Bij de NS krijg je als IT-professional de unieke kans om op veelzijdige manieren betrokken te zijn en gemakkelijk van rol te wisselen. Bovendien betekent werken voor de NS werken voor een bedrijf met een diepgaande maatschappelijke impact. Als er iets misgaat, komt dit groot in het nieuws vanwege de cruciale rol die de NS speelt in onze samenleving. De grappen en irritaties over de ‘trein is weer eens te laat’ zijn bekend. Maar al die duizenden keren dat het dag in, dag uit goed gaat, vergeten mensen weleens.”

“Ik geloof dan ook echt dat het werken bij de NS je de mogelijkheid geeft om daadwerkelijk een verschil te maken voor Nederland. Het is een schone manier van reizen en het helpt indirect mee om de groeiende bevolking en het toenemend woningtekort het hoofd te bieden. In plaats van te kiezen voor meer snelwegen, werkt de NS aan het creëren van hubs die efficiënte, frequente en snelle openbaarvervoer-oplossingen bieden. Deze belangrijke thema’s geven mij voldoening.”

“Ik kan oprecht zeggen dat er bij de NS een warme en collaboratieve sfeer heerst”, vervolgt Jack. “Teamleden werken goed samen en vinden een gezonde balans tussen samenwerking en resultaatgerichtheid, wat een welkome afwisseling kan zijn voor iemand die uit een high-pressure consultancyomgeving komt. Daarnaast is de hybride werkcultuur fijn. Terwijl de operationele teams wellicht vaker op locatie moeten zijn, kunnen IT-professionals genieten van de balans tussen thuiswerken en aanwezig zijn op kantoor. Meestal werken we rond de twee dagen per week op locatie.”

Meld je nu aan voor het webinar ‘Tweakers op Stoom’

Tijdens het webinar ‘Tweakers op Stoom’ gaat Jack dieper in op de drie hierboven genoemde protocollen en legt hij uit hoe ze worden ingezet voor het HIP. Het webinar start om 19.00 uur en duurt ongeveer anderhalf uur. Er is ruim voldoende mogelijkheid om inhoudelijke vragen te stellen, zodat je alle ins & outs over de IT-transitie komt te weten.

Meld je nu aan voor het webinar ‘Tweakers op Stoom’ op 11 oktober en leer meer over hoe het HIP het hart van de data-uitwisseling bij de NS vormt.

Wil je aanwezig zijn bij het Tweakers en NS webinar op 11 oktober?

Poll

Ja, ik wil aanwezig zijn op 11 oktober
Nee, ik laat dit webinar aan mij voorbijgaan

De opties zijn uitgeschakeld omdat de deelname gesloten is

Actievoorwaarden poll

• Je Tweakers-account moet voor 16 september 2023 geactiveerd zijn.
• Meedoen kan tot 8 oktober 2023 23.59 uur, alleen via de poll.
• Alleen ingelogde bezoekers kunnen deelnemen.
• Je kunt één keer aan de poll deelnemen.
• Aanwezigen krijgen uiterlijk 9 oktober 2023 bericht per mail, in de vorm van een officiële uitnodiging. Hierin staat de link om in te loggen voor het webinar. Niet-aanwezigen ontvangen geen bericht.
• Deelnemers zijn op woensdag 11 oktober 2023 beschikbaar om het gehele programma te volgen.
• De uitnodiging voor het evenement is strikt persoonlijk en kan niet worden overgedragen.
• Klachten kunnen via [e-mail] worden ingediend.
• Medewerkers van Tweakers & NS zijn uitgesloten van deelname.

Dit artikel is geen redactioneel artikel, maar gesponsord tot stand gekomen dankzij de 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].

Reacties (31)

[Tristan]

Ik vraag mij af hoeveel bedrijven daadwerkelijk echt blij worden van Kubernetes (k8s) Volgens mij zijn de operationele kopzorgen om k8s op echt grote schaal te laten draaien niet mals.

[Moartn]

Ik snap de populariteit van k8s ook niet helemaal, zeker niet op Azure of AWS. Dan heb je een moderne modulaire cloudomgeving, en ga je er weer 1 heel dik cluster op deployen met de beheerellende die in deze thread al wordt geschetst.

Binnen AWS gebruiken wij vaak ECS als veel meer lichtgewicht container managementlaag, samen met Fargate (= serverless). Dat scheelt enorm veel beheeroverhead. Kan dat hetzelfde als k8s? Nee, maar veel dingen die binnen k8s kunnen zijn dan vaak ook weer nodig omdat de schaal veel groter is. Met ECS is mijn ervaring dat je dingen gewoon sneller opknipt in meerdere clusters. Want vaak hoeven dingen niet binnen hetzelfde cluster te draaien.

[Mars Warrior]

Ik snap de populariteit van k8s ook niet helemaal

Het beloofde platformonafhankelijkheid, totdat bleek dat het een onbeheersbaar waterhoofd is, waarbij je eigenlijk een managed omgeving wil, en dus volledig afhankelijk wordt van je cloudomgeving provider.

Met AWS is dat nog erger: je zit met handen en voeten gebonden aan AWS als je dingen als Fargate etc. gebruikt. Dat is ook precies wat AWS wil: dat je je applicaties niet meer zo maar kunt migreren naar Azure bijv.

De keuze voor RedHat door de NS zal wel komen doordat ProRail ook alles met RH doet. En dus gebruiken ze alles van RedHat/IBM onder de noemer "Open Source".

Ze hebben blijkbaar ook al veel geïnvesteerd in Java, gezien de keuze voor Apache Camel. De complexiteit en enorme leercurve sluit in ieder geval mooi aan op K8s

[UPPERKEES]

Red Hat is de grootste in de zin van open source development. Ik snap je quotes niet.

[Squats]

In zo’n instance kan je dan niet beter op dell powerlflex/apex block storage in aws draaien? Kan je in principe alle kanten op..

[Djerro123]

Bij NS zijn deze dingen gewoon uitbesteed, en ze IT technisch doen ze echt NUL zaken “omdat ProRail”.

Verder; als je applicatie containerizeerd maar je bent gebonden aan de infra, dan moet je je solution architect ontslaan en netjes je software opbouwen. Afhankelijkheden naar de infra stop je in een abstractie laag die je vrij easy kan omvormen naar een ander cloud platform. Ja het is werk, maar als je met handen en voeten gebonden bent aan je cloud platform is dat toch echt je eigen schuld hoor.

[ctrl-tab]

Ik snap de populariteit van k8s ook niet helemaal, zeker niet op Azure of AWS. Dan heb je een moderne modulaire cloudomgeving, en ga je er weer 1 heel dik cluster op deployen met de beheerellende die in deze thread al wordt geschetst.

Kubernetes is geen kattenpis en je hebt in een enterprise inderdaad een team nodig om het goed te onderhouden.
Je hoeft geen dik cluster te deployen. Als je je autoscaling goed op orde hebt schaalt het netjes mee, helemaal als je Karpenter gebruikt. Zoveel intelligentie ga jij qua schaalbaarheid niet in je ECS clustertje krijgen.

Binnen AWS gebruiken wij vaak ECS als veel meer lichtgewicht container managementlaag, samen met Fargate (= serverless). Dat scheelt enorm veel beheeroverhead. Kan dat hetzelfde als k8s? Nee, maar veel dingen die binnen k8s kunnen zijn dan vaak ook weer nodig omdat de schaal veel groter is.

Dat kan wel. Fargate is gewoon een serverless resourcetype dat je ook op EKS kunt gebruiken.
Dus een workernode-loos kubernetes cluster is gewoon mogelijk.

Met ECS is mijn ervaring dat je dingen gewoon sneller opknipt in meerdere clusters. Want vaak hoeven dingen niet binnen hetzelfde cluster te draaien.

Je hebt wel te maken met een proprietary technologie. Imo is de grote kracht van kubernetes dat het universeel is. Of je het on-prem, bij AWS (EKS) , Azure (AKS) , Google (GKE) draait, dat maakt zoveel niet uit.
Dat helpt wel bij het vinden van mensen, en bij een eventuele exit-strategie of hybride scenario.

[Djerro123]

Ik ken echt genoeg bedrijven die het “goed” aanpakken, en idd genoeg bedrijven die het “verkeerd” aanpakken.

De bedrijven die het goed aanpakken kunnen veel applicaties bouwen en onderhouden, de bedrijven die het verkeerd doen hebben zowel een platformteam die zwemt als k8s expertise in de dev teams zitten die er door ontzorgt zouden moeten worden.

Het is net IT zou je kunnen zeggen maar je kan het wel degelijk goed voor je kunnen laten werken, met de juiste setup en juist disciplines over je ontwikkelteams heen.

[UPPERKEES]

Kan je dat ook uitleggen? Kubernetes is juist gemaakt om op grote schaal te werken.

[Motrax]

Voor zover ik nu heb gezien op Azure:

• Er is geen LTS versie, elke 3 maanden upgraden met je productie platform: good luck
• Het wordt verkocht als PaaS, maar het is een IaaS hosting platform
• Beheer is 1 groot drama. Het is niet hands-off, niks is automatisch, je moet alsnog alles zelf regelen

[worrelborst]

Wat een onzin zeg. Je moet je OS toch ook updaten en rebooten?

- Bij Kubernetes op Azure verhuizen dan netjes je applicaties van node naar node net zolang tot alles is geüpdatet. Je hebt er verder geen omkijken naar, hoeft geen handmatige acties te doen.
- Hoezo IAAS? Je hoeft niks met dat OS te doen? Ja je moet wel de configuratie van je applicaties en dergelijk doen maar dat moet je anders ook.
- Beheer is helemaal geen drama. Als applicaties crashen starten ze opnieuw op. Ligt dat aan AKS? Nee, ligt aan je applicatie.

Je moet er wel verstand van hebben en ja het is soms complex maar heel goed te automatiseren.

[Jay-v]

Tuurlijk is dat geen onzin. Kubernetes is VEEL overhead maar je krijgt er flexibiliteit voor terug.

Cloud providers maken cluster management makkelijk. Nodes recyclen is eenvoudig, applicaties deployen is makkelijk. Maar je moet zelf:

- Een Ingress Controller beheren zodat een cloud loadbalancer wordt aangestuurt.
- Version upgrades doen van cluster en nodes (max version skew=3, bijv cluster 1.28.3 -> nodes 1.28.0). Dit gaat vaker fout dan je denkt (deprecated API's etc).
- CertManager voor SSL certs
- Node Feature Discovery (voor GPU's of wanneer je mixed CPU's hebt).
- Een log/metric collector OTEL, FluentD etc
- CSI drivers voor shared of block storage
- Een autoscaler
- Een secrets controller (external secrets).

Zet dit tegenover bijvoorbeeld ECS Fargate en je hebt dit allemaal inbegrepen zonder dat je ook maar ooit een ECS version upgrade hoeft te doen.

Het heeft allemaal met schaal te maken. Heb je een handje vol applicaties? Weinig mensen in je team? Dan kan ik Kubernetes moeilijk aanraden. Je hebt echt een platform team nodig.

[UPPERKEES]

openSUSE MicroOS geprobeerd? Met kured als scheduled auto reboot bij nieuwe overlay updates? MicroOS doet bij elke update health checks en kured zorgt voor een gecontroleerde Kubernetes reboot. Werkt als een zonnetje. Geen omkijken naar.

[Brent]

De vraag moet zijn: wat lost het op? Kubernetes kostenefficiënt draaiende krijgen en houden vergt het soort expertise dat zulke tokos zelden in huis hebben (die lui werken al bij Google et al voor een orde grootte meer salaris) en hebben het ook zelden nodig. Outages door niet kunnen schalen ruil je in door outages door misconfig, onverwachte nieuwe effecten, traagheid door gebrek aan expertise, etc. 1 expert die C++/Erlang achtige software kan bouwen en 1 dikke server kan in praktijk hetzelfde voor een fractie van de prijs. Maar zulke jongens moet je dik betalen, en niet lastigvallen met al het soort opgelegde software-omgevingen zoals je buiten Big Tech vind. Bovendien heb je er 1, hooguit een paar nodig, en niemand die daarvoor een 100-1k koppige divisie durft te ontslaan

Maar, het doet het goed op een CV voor de stap na de NS

[bzzzt]

Ja, vooral prachtig als die ene gast die Erlang kan een nieuwe baan vindt.
Of als die enkele server omvalt.
"Opgelegde omgevingen" is waar de klant voor betaalt right?

Daarnaast heb je geen 100 man nodig om software te optimaliseren, dus als je dergelijke teams hebt is het meestal omdat de functionaliteit in de breedte schaalt. Ik ben het volledig met je eens dat veel projecten efficiënter kunnen worden uitgevoerd, maar zonder te weten wat je business vereist lijkt het me heel voorbarig om 1000 man overbodig te verklaren. (zie bv wat er met de inkomsten van Twitter X is gebeurd sinds Musk z'n massaontslagronde).

[Sandor_Clegane]

Je kan mensen natuurlijk ook gewoon inhouse opleiden...... Maar ja, dat kost geld en is niet sexy.

Kubernetes is a poor man's Erlang.

[shades]

Ik proef een beetje "wat de boer niet kent...."
Maar goed - ik weet niet of het slim is om momenteel Redhat te kiezen als partner vanwege het feit dat hun rhel builds tegenwoordig achter een paywall zitten en een dikke vinger naar de opensource community hiermee hebben gegeven.

[Reactie gewijzigd door shades op 26 juli 2024 20:47]

[arbraxas]

Dat zal ook echt 1 van de zware eisen zijn voor NS.........

[Hakulaku]

Ik weet niet of je ooit met Red Hat gewerkt hebt maar hun business model is het rebranden en supporten van community (open-source) software. Het IBM model dat nu ook doorgevoerd wordt bij Red Hat zal er voor zorgen dat binnen afzienbare tijd (en het is nu al in gang gezet) core developers de overstap maken naar concurrenten en dat Red Hat blijft zitten met weinig tot geen kennis.

Ik ben benieuwd hoe het vergaat met Red Hat maar ik heb geen goede hoop...

Uiteindelijk zal dit voor een hoop bedrijven kopzorgen gaan geven omdat de kwaliteit en support die Red Hat in de toekomst kan leveren, minder zal worden.

[Reactie gewijzigd door Hakulaku op 26 juli 2024 20:47]

[Hakulaku]

Het is zeer afhankelijk van de omgeving waarin je k8s (of de gebrande distro's) probeert op grote schaal uit te rollen. In de cloud bij Azure, AWS of Google zou je weinig problemen ervaren.

In house zou je an sich, mits de workloads, hardware, virtualisatie en netwerk juist opelkaar afgestemd zijn het moeiteloos op grote schaal moeten kunnen draaien. Echter is mijn ervaring dat dit niet het geval is en er inderdaad grote uitdagingen zijn om dit op grote schaal te draaien wanneer je ook rekening moet houden met andere applicaties. Maar met welke software is dit niet het geval?

Ik maak me wel zorgen om Red Hat aangezien steeds meer achter een paywall verdwijnt, hoop developers overstappen en de support vanuit Red Hat zelf geleverd wordt door onervaren techneuten. Daarnaast wordt er veel beweert, beloofd en gedemo'd in de Community Days van Red Hat, echter zijn dit vaak Proof Of Concepts en opgeblazen verhalen.

[DeSoepkip]

Joh dit is een advertentie. Zo'n "wij van wc-eend verhaaltje". Niet teveel waarde aan hechten

[GlasHalfVol]

Echt, een hele nuttige, inhoudelijke bijdrage aan deze discussie

[3dfx]

Als ik de woorden RedHat en NS in 1 regel zie staan, denk ik toch als eerste aan opa Flodder

[Jeroen hofman]

@3dfx dacht meerder aan RedHat als basis voor Hybride Integratie Platform maakt NS datagedreven,
een Advertentie op de achtergrond?.
Waarom niet een background iets redHat op de achtergrond.
Gaat (niet over de NS) maar RedHat.
Ik begrijp niet dat NS nog steeds een probleem is, hier horen we toch al jaren over.
Wordt volgens het nieuws,denhage volgend jaar 2024 weer 300 Milj in NS gepompt.

Denk je aan de trein, dan denk je aan de NS en of het allemaal wel rijdt vandaag, morgen en weer op tijd op je werk bent En weer thuis.
Als ik zo ook bij de overheid lees is thuiswerken toch een blijvertje is
https://www.rijksoverheid...swerken-is-een-blijvertje
Dacht even terug, toen het nog niet zo druk was
Vroege moest via de A15 naar mijn werk, herinner me de stelten beton platen nog.
je bleef echt wel waker in de auto zeker na Kesteren tot nabij de sluizen in Tiel.
Och jaren 70 80 stroomde Amsterdam al dicht,en later ook andere grote steden werd o.a de binnenstad afgesloten (bordje lossen tussen )
70-80' jaren en was het al verhaaltje trein ook vaak veel probleem, en nam het verkeer ook drastisch toe op de snelwegen. ligt veel asfalt aan wegen. Zo ook het hele Betuwe-lijn trein project.
Betuwe-lijn trein project, zou toch vanuit de haven Rotterdam naar Duitsland vervoeren.

Jaren geleden is daar onderzoek gedaan, Betonrot. Wat heeft daar aan menig bewoner zijn huis , land gedwongen voor heeft moeten inleveren.
Toen waren er al veel oplossingen betonrot koste wel wat om dat te herstellen maar dan was het wel mogelijk om daar bijvoorbeeld een treinstel met 20 wagons achter te hangen waar dan weer 16 auto's per wagon vervoert worden. Her en der een tussen stop.
Jammer Hoop kostbaar geld,verspild, gekost.
Maar Gaat over RedHat als basis voor Hybride Integratie Platform maakt NS data gedreven
Komt vast ooit wel goed.

[Ed Vertijsment]

Aantal jaar geleden hebben we bij ons een grote klant met miljoenenpubliek van cloud architectuur met micro services en poeha verhuist naar een ouderwetse monoliet op een dedicated server met een cdn ervoor.

Kosten met zon 100voud verlaagt en zowel performance als beschikbaarheid verbeterd.

[roelboel]

Microservices zijn 99 van de 100 keer ook een stompzinnig idee, die hooguit organisatorische problemen oplossen dan technische.

[Reactie gewijzigd door roelboel op 26 juli 2024 20:47]

[Ed Vertijsment]

Ben ik het mee eens

[Hoover]

Dit is wel iets wat in mijn straatje past.
Ik ben ondertussen al ruim 10 jaar bezig in de integratiewereld en ben wel benieuwd hoe het bij iemand anders in de keuken er aan toe gaat.
Ik heb verschillende producten en volwassenheid van integratie platformen gezien bij een boel bedrijven waardoor ik benieuwd ben naar het platform van NS en of ik daar nog wat van kan leren.

[dieguyvanit]

Doe mij maar een zitplek, een schone wc enne 25 Euro voor een enkeltje Enschede Amersfoort lijkt me ook wat aan de dure kant.

[GlasHalfVol]

hele nuttige bijdrage aan deze discussie

[erwindon]

> Ik weet niet of je ooit met Red Hat gewerkt hebt maar hun business model is het rebranden en supporten van community (open-source) software

veel van die open-source wordt ook gewoon door daarvoor betaalde werknemers van Red Hat zelf onderhouden. dan is het re-branden een peuleschil. en bij upstream problemen lossen ze het meteen zelf op, terwijl community bijdragen nog steeds gewoon welkom zijn.