IBM Webinar: Applicatiemodernisatie zet jou als ontwikkelaar centraal

Tweakers & IBM webinar

Op dinsdag 16 maart organiseren Tweakers & IBM het applicatiemodernisatie-webinar. Meld je aan via de poll onderaan het artikel of klik hier!

Ontwikkelaars zijn voor praktisch elk bedrijf een onmisbare schakel. Ze zijn het belangrijkste radertje in de keten en hebben daardoor een grote vinger in de pap als het gaat om vernieuwing van de organisatie. Dit betekent dat de ontwikkelaar vaak mensen mee moet krijgen om een nieuw pad in te slaan, maar ook vaak genoeg ‘nee’ moet leren zeggen als iemand met een wild plan op de proppen komt. Hoe dat in z’n werk gaat is voor elke organisatie anders. Om een gevoel te krijgen bij de relevantie van het werk van een ontwikkelaar en hoe je in de strategie kunt passen, spreken we met Marc Loos, cloud advocate van IBM, en Koen van Bakel, principal solution architect bij RedHat.

De belangrijkste reden om te beginnen met applicatiemodernisatie zou moeten zijn: het vervangen van systemen die niet meer goed functioneren of het willen uitbreiden van functionaliteiten die niet meer goed zijn aan te sluiten op bestaande systemen. Het gaat vaak om zogenaamde ‘monolieten’ of ‘ouderwetse’ mainframes. Het doel is uiteindelijk om zo’n monoliet om te bouwen naar een systeem dat beter schaalbaar is, vaak door gebruik te maken van microservices en clouddiensten. Marc wijst er tijdens het interview op dat we niet moeten vergeten dat microservices en virtualisatie al sinds 1973 wordt toegepast, maar nu voor iedereen bereikbaar is.

Hoe gaan we van een monoliet naar microservices of de cloud?

Marc: “Stel je een 18-wielige vrachtwagen met een 25 meter lange aanhanger voor, een LZV. Die past
prima op de snelweg of de ring van Rotterdam, maar het wordt lastig bij de eerste rotonde. Het gaat helemaal mis als je met dat gevaarte de binnenstad van Amsterdam in moet. Je kunt daar niet meer snel en effectief manoeuvreren. Daarom is de logistiek de afgelopen jaren snel veranderd. Zo’n LZV gaat naar een distributiecentrum buiten de stad en vervolgens wordt daar alles verdeeld over kleine elektrische wagentjes die snel en effectief door de hele stad heen kunnen.

"Je moet mee kunnen bewegen met de dynamiek van je omgeving"Zo krijg je een enorm logistiek voordeel: de kleine wagentjes zijn snel, effectief en schaalbaar. Je krijgt heel veel voordeel van het opdelen van de inhoud van zo’n grote vrachtwagen in kleine stukjes. Dat is in essentie wat applicatiemodernisatie is: een grote applicatie die nu als monoliet draait, opdelen in kleinere applicaties of verrijken met kleinere apps eromheen om sneller en effectiever met alles om te kunnen gaan.”

“De wereld verandert ook”, zegt Koen. “De stad is autoluw gemaakt, de monoliet in de vorm van een vrachtwagen beweegt steeds moeilijker. Je moet dus mee veranderen, je moet aanpassingen doorvoeren. Alles moet nu sneller en, ik durf het bijna niet te noemen, corona heeft dat proces ook versneld. Je moet mee kunnen bewegen met de dynamiek van je omgeving.”

Wanneer zeg je ‘nee’ tegen applicatiemodernisatie?

Marc: “Je brengt altijd eerst in kaart wat het meeste oplevert voor het bedrijf, je gaat dus prioriteiten stellen. Wat past goed in een cloud-native-strategie? Wat heeft baat bij een modernere infrastructuur? Sommige applicaties zijn extreem geoptimaliseerd voor hun functie, dus waarom zou je daar nu aan gaan zitten? Misschien moet je er alleen de front-end van aanpakken. Aan de andere kant kan de applicatie zijn geschreven in een oudere programmeertaal waar niet meer zoveel kennis van is. Dan kan het nodig zijn je toch te gaan richten op een migratie in de toekomst. Stap één is: inventariseer wat er is. Stap twee: vraag jezelf af wat je doelstelling of de doelstelling van het bedrijf is. En stap drie: kijk naar hoe je dat het snelst kunt bereiken.”

Koen: “Moderniseren om het moderniseren heeft weinig nut. Als je bedrijf er sneller en efficiënter door wordt, heeft het zin. Er zijn ook bedrijven die modernisatie inzetten om mensen te stimuleren buiten de gebaande paden te kijken en nieuwe technieken te leren.”

Stel, je behoudt een monoliet. Hoe neem je hem mee naar de toekomst?

Marc: “Er komt een moment dat de monoliet retired wordt, want de applicatie die er nu op draait is over een aantal jaar niet meer valide. Dan is er een end-of-life. Wil je daar nu nog in investeren? Of gaan we een sidetrack starten om functionaliteit van de monoliet over te zetten naar kleinere stukken zodat hij over vijf jaar wordt uitgefaseerd?”

Opensource en communities

Koen: “Ondertussen kun je kijken wat verschillende softwareleveranciers hebben en of er niet iets is dat past en klaar is voor een cloud-native omgeving. Je koopt dan functionaliteit in waar ook anderen gebruik van maken, waardoor de levensverwachting van die specifieke functionaliteit vermoedelijk langer is. Dat is iets wat we veel bij RedHat doen met communities rond onze opensourceprojecten. Met die extra bekendheid krijgt je project een grotere schaal en ook een bredere inzetbaarheid.

En ook niet onbelangrijk: er is een schreeuwend tekort aan goede developers. Dat kun je deels oplossen door gebruik te maken van bestaande applicaties die via cloud-native infrastructuur worden aangeboden. Je moet dan wel iemand hebben die dat goed kan vertalen naar functies voor cloud-native. Ontwikkelaars zijn daarom extra belangrijk omdat ze goed kunnen bepalen of het iets is dat je met je team kunt aanpakken, dat je zelf kunt schrijven of dat je gewoon kunt kopen en zo kunt gebruiken.”

Schrikt dat ‘spin in het web’ zijn ontwikkelaars niet af?

Marc: “Sommigen willen alleen maar programmeren, dat zijn de hypercodeschrijvers. Maar als je meer business-driven bent, denk je mee in het hele proces. Dat maakt je werk ook veel breder en potentieel interessanter.”

Heb je een voorbeeld van zo’n traject?

“Een Scandinavische financiële instelling wilde een modernisatieslag aangaan naar microservices en containers. In plaats van met honderden developers te gaan ontwikkelen, hebben we twee routes gemaakt. Route een deelden we op in drie blokken met OpenShift. Zo leerden de ontwikkelaars waar de scheidslijnen liggen, hoe ze met api-communicatie moeten omgaan en allerlei andere randvoorwaarden om het in zo’n platform te laten functioneren. Daarnaast moest operations werken met het platform. Elk team leerde zo hoe het moet. Vervolgens deelden we de blokken nog een stap verder op, in zes stukken. Dan heb je ineens achttien keer zoveel communicatie binnen je platform, achttien keer zoveel applicaties en alles wat daaromheen zit.

Route twee was het opdelen in microservices from scratch. Dat ging een heel stuk langzamer. Na zes maanden was de eerste route op het punt dat het hele team het goed kon, de architectuur doorzag en wist wat het aan het doen was. De andere groep was nog niet eens halverwege.

Pushnotificaties"Een wereldklus, wat er sinds maart vorig jaar is gebeurd. Allemaal te danken aan developers"

Om het wat dichter bij huis te halen: stel je een app voor als Tikkie. Als ik iemand betaal, krijgt de ander een pushnotificatie op zijn telefoon ‘Marc heeft betaald’. Wil je als developer de code voor de pushnotificatie schrijven? Of wil je code schrijven die ervoor zorgt dat het geld van de ene naar de andere rekening wordt overgemaakt en je daar alleen maar in hoeft te zetten ‘doe pushnotificatie’? Door zelf niet bezig te zijn met de code voor de pushnotificatie kun je je focussen op de core van de app, namelijk geld overmaken.”

Koen: “… en dat is dus precies wat je bent: de spin in het web die uit moet kunnen leggen waarom je bepaalde dingen wel of niet doet.

Afgelopen jaar is er natuurlijk ontzettend veel videovergaderd. Daar is in korte tijd zo ontzettend veel functionaliteit bijgekomen. Ik zit nu met een green screen achter me in een heel klein kamertje. Dat wil nu iedereen. Al die technieken zijn beschikbaar en kun je gebruiken. Als dat allemaal monolitische applicaties waren geweest, was dat nooit gelukt.”

Marc: “Een wereldklus, wat er sinds maart vorig jaar is gebeurd. Allemaal te danken aan developers. Als die stoppen, stopt de keten. De ontwikkelaar slaat de brug tussen al die werelden, van operations tot de manager en de directeur.”

Interesse en wil je meer weten?

Wil je meer weten over de dagelijkse praktijk en hoe je verder kunt kijken dan een opdracht? Kom dan naar de workshop op 16 maart. Voel Marc en Koen aan de tand tijdens een discussiepanel en vraag ze uit over wat modernisatie voor hun dagelijks werk betekent. Meld je snel aan via de poll. Uiterlijk 15 maart ontvang je dan de registratielink waarmee je je aanmelding definitief kunt maken.

Webinar IBM & Tweakers

Poll

Ja, ik wil aanwezig zijn op 16 maart.
Nee, ik laat deze actie aan mij voorbijgaan.

De opties zijn uitgeschakeld omdat de deelname gesloten is

Programma 16 maart *

18:30-19:30 - Panelgesprek met Marc Loos, Damiaan Zwietering (IBM), Koen van Brakel (RedHat) en Frank Everaardt (Tweakers).
19:30-19:35 - Korte break
19:35 - 20:20 - Workshop door Koen van Bakel & Marc Loos
20:20 - 20:25 - Korte break
20:25 - 21:10 - Vervolg workshop door Koen van Bakel & Marc Loos
21:10 - 21:25 - Bespreking en afsluiting

*programma is onder voorbehoud

Op 30 maart organiseert Tweakers in samenwerking met IBM een tech talk waarin een duik wordt genomen in de wereld van hybrid cloud en de rol van storage en compute hierin. Wil je hier meer informatie over ontvangen? Mail dan naar [e-mail]

Actievoorwaarden

• Je Tweakers-account moet voor 28 februari 2021 geactiveerd zijn.
• Meedoen kan tot 15 maart 2021 23:59 uur, alleen via de poll.
• Alleen ingelogde bezoekers kunnen deelnemen.
• Je kunt één keer aan de poll deelnemen.
• Aanwezigen krijgen uiterlijk 15 maart 2021 bericht per mail, in de vorm van een officiële uitnodiging. Hierin staat de link om je te registreren voor het webinar. Niet-aanwezigen ontvangen geen bericht.
• Deelnemers zijn op dinsdag 16 maart 2021 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 & IBM zijn uitgesloten van deelname.

Dit artikel is geen redactioneel artikel, maar gesponsord en tot stand gekomen dankzij IBM en Tweakers Partners. Dit is de afdeling binnen Tweakers die verantwoordelijk is voor commerciële samenwerkingen, winacties en Tweakers-events zoals Meet-ups, Developers Summit, Testfest en meer. Kijk hier voor een 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.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (15)

"Modernisatie", een term die alle cloud-boeren zijn gaan gebruiken om het verhuizen naar de cloud te framen. Maar er is weinig moderns aan de cloud. Voor de helft van de technieken hebben ze geen native oplossing waardoor je alsnog vps-sen zit te beheren, en tal van features die je pas krijgt in de hoogste prijsplannen. Puntje bij paaltje moet je dus 1 cloudplatform kiezen en je applicatie from scratch specifiek daarvoor bouwen. Dat is een starre vendor-lockin die tegen het vrije mantra van de cloudbelofte in gaat. Gelukkig is er een escape voor de huiverige techneut: de private cloud. Gewoon ouderwets alles zelf doen, maar wel met een cloud-labeltje eraan om de managers hun buzzwordbingo te kunnen laten afstrepen.

Mijn ervaring is dat je in een private cloud net zoveel vendor lock-in hebt als in de niet private cloud. Of maak je in een private cloud geen gebruik van, zeg en specifieke type database met bijbehorende stored procedures, of van een queue, of een bepaalde logging framework?

Modernisatie heeft wat mij betreft dan ook helemaal niks met cloud te maken. Een moderne applicatie kan ook in een servetje onder je bureau draaien.

Bij moderniseren zijn er zoveel factoren die meetellen, zoals de wijzigingsgraad van een applicatie, hoe vaak bugs voorkomen, bedrijfskritisch of niet, schaalbaarheid, performance, onderhoudbaarheid enz. Strooien met buzz termen zoals (private) cloud hebben dan ook weinig nut voor een professionele softwareontwikkelaar. Elke stukje software is maatwerk (als dat van toepassing is ) en modernisatie is dan ook maatwerk.

Edit:typo

[Reactie gewijzigd door david-v op 8 maart 2021 10:41]

Je kan ook een platform op de cloud omgeving bouwen dmv containers. Door een laag bovenop de cloud omgeving te bouwen kan je meerwaarde voor developers toevoegen, het makkelijker maken te managen en te verhuizen. Het grootste probleem wat ik nog wel zie is stateful workloads, dat is en blijft een moeilijk element. Maar niet elke applicatie hoeft te draaien op de plek waar de database draait.

Het kan natuurlijk zijn dat die 'monolitische' applicatie (is die wel monolitisch?) niet meer deugt maar misschien is het ook zo dat die nog prima voldoet, net zoals die 'legacy' spullen nog prima functioneren. Natuurlijk ontwikkelt software zich, het is nooit statisch, en dat daarbij nieuwe techniek gebruik worden is niet gek. Maar het moet nooit moderniseren om het moderniseren worden.

En 'de ontwikkelaar centraal' zou dat echt zo zijn? In deze tijd waarin het proces belangrijker is geworden dan de mens, snel, efficient zijn de trefwoorden in deze tijd. Waar jan en alleman om een project heespringen. Al scrummend en sprintend. ICT is niet eenvoudig.

Joel Spolsky, Things You Should Never Do, Part I

https://www.joelonsoftwar...u-should-never-do-part-i/

Afgelopen jaar is er natuurlijk ontzettend veel videovergaderd. Daar is in korte tijd zo ontzettend veel functionaliteit bijgekomen. Ik zit nu met een green screen achter me in een heel klein kamertje. Dat wil nu iedereen. Al die technieken zijn beschikbaar en kun je gebruiken. Als dat allemaal monolitische applicaties waren geweest, was dat nooit gelukt

Volgens mij is dit juist het toonbeeld van monolithische applicaties, MS teams, zoom, allemaal stuk voor stuk monolieten die alle resources van je computer drainen en totaal niet horizontaal schalen. Sure een paar backend services om in te loggen, maar de daadwerkelijke applicatie is 1 grote monoliet.

Hoe wil je horizontaal schalen bij je eigen computer dan? Extra computers ernaast zetten?

Hoe het kwa backend is is het waarschijnlijk geen monoliet, maar juist goed horizontaal schaalbaar.

Hoe het kwa backend is is het waarschijnlijk geen monoliet, maar juist goed horizontaal schaalbaar.

Ja maar die backend heeft niks te maken met chroma key, dat gebeurt namelijk allemaal on device. Het backend is hoogstens een login service en wat routering voor de video (misschien, als ze het slim doen gaat het via p2p achtig iets), meer niet.

Hoe wil je horizontaal schalen bij je eigen computer dan? Extra computers ernaast zetten?

Nee, daarom gewoon niet.

Punt is dat dit het slechtste voorbeeld is van microservices om mee te komen. Chroma keying gebeurt on device, en hoeft niet te schalen. Als MS dat niet on device doet dan zou dat echt heel slecht zijn.

Waarom? De video moet toch naar de cloud, en daar kunnen ze eventueel machinelearning gebruiken om de achterground weg te halen.

Ik mag toch hopen dat je chroma keying niet gaat doen met machine learning. Voor full virtual background (zoals zoom dat heeft) sure, maar voor slechts chroma key met greenscreen is dat superveel resources die je gaat inzetten voor iets relatief simpels. Daarnaast kun je het effect live op je eigen scherm zien zonder vertraging. Dat gaat niet als je het via de cloud doet.

En mbt tot video serving. Dat gaat vaak 1-op-1 door via direct routing en media bypass. Dit om juist servers te ontlasten en een meer responsive call te kunnen waarborgen.

Voor een gebruiker moet de voorkant wel een monoliet lijken, je kan moeilijk tegen een gebruiker zeggen dat die voor video, audio, scherm delen, chat allemaal verschillende applicaties moet starten. Maar aan de achterkant kunnen het wel allemaal losse services zijn.

Dat ze alle resources gebruiken op een computer heeft vaak meer te maken met besparen op hardware en de virusscanner op standje 11 hebben staan.

Dat ze alle resources gebruiken op een computer heeft vaak meer te maken met besparen op hardware en de virusscanner op standje 11 hebben staan.

Wat bedoel je hier mee?

Voor een gebruiker moet de voorkant wel een monoliet lijken, je kan moeilijk tegen een gebruiker zeggen dat die voor video, audio, scherm delen, chat allemaal verschillende applicaties moet starten. Maar aan de achterkant kunnen het wel allemaal losse services zijn.

Nee uiteraard begrijp ik dat je gewoon een fatsoenlijke frontend moet hebben die alles integreert, maar de voorbeelden van services die je noemt zijn niet op die manier geïmplementeerd. Tenminste. Als je even in taakbeheer kijkt zie je bij vrijwel al die conferincing applicaties 1 proces (misschien nog een helper erbij) draaien wat z'n ding doet. Als al die afzonderlijke spullen microservices waren geweest had ik verwacht iets te zien zoals chrome heeft. per ding een process.

Overigens maakt het bij heel veel van dat soort applicaties ook geen drol uit wat je wel of niet doet, resources verbruik is gewoon vet hoog. CPU die lekker op 350% loopt te blazen is hier geen uitzondering, bij verschillende apps (Jitsi, Zoom, Starleaf, Slack, whereby, MS teams). Het maakt dan niet uit of ik met 25 man in een call zit of met 2, met of zonder beeld, met of zonder screenshare, met of zonder chat.

Dat is wat ik bedoel te zeggen, met dat het allemaal wel meevalt met "microservices" zeker aan de voorkant vna het geheel. Je kunt niet modules uitzetten en zo besparen op resources, of juist extra module bijschalen, omdat je meer nodig hebt op inkomende video (wat altijd een doorn in het oog is aangezien overall video quality dan dropt als een gek, bij meer mensen) of meerdere vensters wil delen ofzo.

[...]
Wat bedoel je hier mee?

Dat veel bedrijven besparen op hardware maar vervolgens de virusscanners zo actief zetten, dat alles wat je doet tot "hoog" resourceverbruik lijkt te leiden, terwijl op een normale pc met normaal afgestelde virusscanner het allemaal wel meevalt.

Nee uiteraard begrijp ik dat je gewoon een fatsoenlijke frontend moet hebben die alles integreert, maar de voorbeelden van services die je noemt zijn niet op die manier geïmplementeerd. Tenminste. Als je even in taakbeheer kijkt zie je bij vrijwel al die conferincing applicaties 1 proces (misschien nog een helper erbij) draaien wat z'n ding doet. Als al die afzonderlijke spullen microservices waren geweest had ik verwacht iets te zien zoals chrome heeft. per ding een process.

Microservices zegt niets over het aantal processen van de frontend. Chrome heeft 1 proces per tabblad, maar dat maakt niet dat Chrome op microservices draait. Je moet microservices ook niet vertalen naar frontends, het zijn 2 heel verschillende dingen. Frontends kunnen wel microservices gebruiken om data op te halen, maar een frontend is eigenlijk nooit een microservice (of je moet je gebruikers gek willen krijgen met een apart scherm voor iedere functie).

Dat is wat ik bedoel te zeggen, met dat het allemaal wel meevalt met "microservices" zeker aan de voorkant vna het geheel. Je kunt niet modules uitzetten en zo besparen op resources, of juist extra module bijschalen, omdat je meer nodig hebt op inkomende video (wat altijd een doorn in het oog is aangezien overall video quality dan dropt als een gek, bij meer mensen) of meerdere vensters wil delen ofzo.

En dat moet de applicatie dus zelf onder water oplossen, daar moet een gebruiker niet in gaan rommelen. Maar zoals gezegd, hoe de voorkant eruit ziet zegt niets over de achterkant en heeft ook niets met microservices te maken.

Dat veel bedrijven besparen op hardware maar vervolgens de virusscanners zo actief zetten, dat alles wat je doet tot "hoog" resourceverbruik lijkt te leiden, terwijl op een normale pc met normaal afgestelde virusscanner het allemaal wel meevalt.

Maar we hebben het hier toch niet over een virusscanner? Ik heb het over normale applicaties die ik off the shelf draai. Je gaat mij niet vertellen dat ik al die apps individueel eerst maar eens moet gaan afstellen, want als dat het geval is, laat dan maar zitten.

Microservices zegt niets over het aantal processen van de frontend. Chrome heeft 1 proces per tabblad, maar dat maakt niet dat Chrome op microservices draait. Je moet microservices ook niet vertalen naar frontends, het zijn 2 heel verschillende dingen. Frontends kunnen wel microservices gebruiken om data op te halen, maar een frontend is eigenlijk nooit een microservice (of je moet je gebruikers gek willen krijgen met een apart scherm voor iedere functie).

Nee ik vertaal microservices ook niet naar frontends, maar als de IBM man het hier heeft over Microservices in de applicatie, verwacht ik dat ie het ook daadwerkelijk heeft over de applicatie en niet het gehele landschap (wat veel meer is dan alleen MS teams) erbij betrekt zonder context. Een frontend is an sich ook niet een apart applicatie, maar het is wel best practice om je UI logica te scheiden van je businesslogica. Dit om blocking te voorkomen. Ik zeg ook helemaal niet dat een frontend hetzelfde is als een microservice, maar dat de achterliggende logica modules (verwerking inkomende video, verwerking eigen webcam, screenshare module, chat module, uitgaande audio, binnenkomende audio) in principe als eigen proces gespawned kunnen worden met eigen thread.

En dat moet de applicatie dus zelf onder water oplossen, daar moet een gebruiker niet in gaan rommelen.

Nee ik zeg ook niet dat het aan de gebruiker is om dat te bepalen, maar dat de applicatie dat kennelijk niet doet. Het punt van microservices is dat je beter met resources omgaat en daar efficiënter mee kunt verdelen. Dat gebeurd dus echter niet. Het maakt niet uit wat je doet en hoe je dat doet, het verbruik is gewoon hoog.

Leuk dus dat er aan de backend wat microservices draaien voor bepaalde dingen, maar de features die er genoemd worden in het voorbeeld zijn grotendeels features die in de client zitten verwerkt. Juist de features die als microservice zijn geïmplementeerd worden niet benoemd (zoals media processing, Call routing, de hele MS cloud PBX). Dat zijn dingen waar microservices worden gebruikt. Niet een Green screen chroma keying.

een Microservice is overigens ook niet een backend specifiek dingetje ofzo. Met web gerelateerde zaken wordt dit vaak wel zo bekeken, maar in principe kunnen clientside processing services ook gewoon als microservice worden neergezet. Dit doet MS dan ook met bijvoorbeeld hun update software. De MS auto-updater is een microservice die op jouw computer draait en af en toe eens checked of er updates beschikbaar zijn voor MS software.

Ik wordt een beetje moe van het Microservices verhaal. Omdat dat in het geval van Netflix een goede oplossing is hoeft het echt nog niet op iedereen van toepassing te zijn. Net zoals een paar jaar geleden, toen NoSQL ineens populair werd. Ja, het heeft specifieke doelen, maar gebruik het niet alleen maar om hip te zijn. Het zelfde is ook op Microservices van toepassing. Een app moderniseren betekent nog niet microservices er van maken, ook microservices hebben zo hun nadelen...