Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Esp is niet geschikt voor elk probleem

Event stream processing (esp), een technologie om near real-time op gebeurtenissen te reageren, is al een tijdje hot. En zoals de Gartner Hype Cycle voorspelt, duurt het dan nooit lang voordat zo’n technologie in het dal van de desillusies belandt. Esp is zo’n lot ook beschoren. Tenzij organisaties zich goed realiseren wat de consequenties zijn van deze technologie en wat je moet organiseren om alle onderdelen van de gedistribueerde architectuur met elkaar te laten communiceren.

Allereerst: waar hebben we het over? Met event stream processing (esp) kun je event driven reageren. Dat betekent dat je reageert op basis van een gebeurtenis. Een klant die langs je winkel loopt en die je wilt targetten met een persoonlijk aanbod; een ander voorstel voor een vervangende vlucht doen nog voordat de passagier in de gaten heeft dat zijn vlucht is gecanceld of ernstig vertraagd. Het is niet vreemd dat bedrijven prachtige mogelijkheden zien in deze technologie. Er wordt zelfs in directiekamers over gesproken. De techniek staat voor niets, laten we deze kans pakken.

Wat mij betreft een goed idee, maar niet zonder dat je weet waar je het over hebt. Want deze technologie biedt niet alleen veel mogelijkheden, maar is ook complex. Gedistribueerd event driven werken betekent dat je parallel reactief aan de bak gaat. Voor de duidelijkheid: over het algemeen is reactief niet een term die als vooruitstrevend wordt gezien. Maar voor bijvoorbeeld een infrastructuur die je bij een derde afneemt per transactie, is dit prima. In dit geval vergroot het je flexibiliteit enorm, maar het betekent wel dat je de complexiteit die hier aan de achterkant bij hoort moet managen. Als je de consequenties niet volledig doorziet en als je niet begrijpt dat je bijvoorbeeld op een andere manier over data en dataconsistentie moet gaan nadenken, dan kun je er beter niet aan beginnen.

De bedoeling van dit artikel is niet om bedrijven angst aan te jagen, maar om aan ontwikkelteams en it-management duidelijk te maken wat de trade offs zijn van esp en streaming, zodat zij goed beslagen ten ijs komen als ze het gesprek aangaan met het C-level.

Ander architectuurmodel

"Oplossingen die gebruik maken van een esp hanteren over het algemeen een ander architectuurmodel"

Kafka is verreweg het bekendste esp-platform. Het stelt je in staat om realtime op events te reageren, en dit met hoge beschikbaarheid en schaalbaarheid. In dit artikel gaan we daarom met name uit van Kafka, al zijn de meeste implicaties ook op andere oplossingen van toepassingen.

Oplossingen die gebruik maken van een esp hanteren over het algemeen een ander architectuurmodel. Namelijk het scheiden van lees- en schrijfacties over streams en databases. De mutaties vinden in dit geval eerst plaats op de stream en pas later op de database. Dat brengt een aantal consequenties met zich mee.

In de eerste plaats zul je moeten accepteren dat de onderliggende databases niet altijd helemaal synchroon zijn. Data die meteen wordt verwerkt in de stream wordt immers pas later een keer opgeslagen in de database. Wanneer dat later precies is, weet je niet. Het concept gaat uit van ‘eventually consistent’ in plaats van realtime consistent. Er is dus nooit één versie van de waarheid. Overigens wordt in dit soort gevallen vaak de stream als primaire waarheid gebruikt. Logisch ook, zeker als je bedenkt dat het streaming platform schaalbaar, robuust en overal beschikbaar is.

Een ander facet waar je rekening mee moet houden, is de webservices-architectuur die ten grondslag ligt aan de applicaties die je realtime wilt laten reageren. Als je webwinkel bestaat uit honderd webservices die allemaal hun eigen data gebruiken, wil je er niet honderd databases onder leggen, dat wordt te duur. Je kunt wel de webservices gebruik laten maken van event streams, wat een veel goedkopere oplossing is. Dit betekent echter wel dat je gedistribueerde event streams creëert die uiteindelijk weer bij elkaar moeten komen. Dat is prima mogelijk, het lukt immers ook om de webservices zelf met elkaar te laten communiceren. Er moet wel goed over nagedacht worden.

Bijvoorbeeld over wat te doen bij een actie die honderd keer parallel wordt aangeboden maar slechts eenmaal tot resultaat mag leiden in het achterliggende landschap. Als een klant uit ongeduld honderd keer op de submit-knop kopen drukt, mag dat maar één transactie tot gevolg hebben. De services moeten op dat gedrag zijn gebouwd. Het zogenaamde ‘idem potent’-gedrag. Dat wordt niet standaard door het onderliggende event platform geregeld, dat is gewoon onderdeel van de service implementatie. Development-werk dus.

Complexiteit managen

Het feit dat parallel event gedreven een uitdaging is, is niet nieuw. Ik vergelijk het graag met het verbouwen van een huis. De aannemer komt om een offerte te maken en schat de klus in op duizend manuren. Hij kan een timmerman, stukadoor, loodgieter, elektricien en tegelzetter sturen, die allemaal ongeveer tweehonderd uur werk hebben. Dan zou de klus in theorie in vijf weken klaar kunnen zijn, maar de praktijk is dat ze op elkaar moeten wachten. De stukadoor kan immers pas beginnen als alle waterleidingen en elektriciteitskabels zijn weggewerkt. En de tegelzetter kan pas aan het werk als het stucwerk klaar is. De klus zal dus minimaal tien weken duren.

Stel dat de opdrachtgever als harde eis stelt dat het binnen drie weken af moet zijn. Dan kun je meer mensen inhuren, maar dat betekent dat de afstemming - die met vijf werklui al complex was - nog vele malen ingewikkelder wordt. Niet onmogelijk, maar wel lastig. De kans dat er in de afstemming wat fout gaat, met rework en vertraging tot gevolg, is erg groot. Voor één bouwbegeleider is het eigenlijk niet meer te overzien, je zult een heel leger bouwbegeleiders nodig hebben. Iemand voor de woonkamer, iemand voor de keuken, iemand voor de badkamer en ga maar door. Die moeten onderling ook weer afstemmen. Je wilt immers niet in je net afgetimmerde keuken ineens nog een buis van het toilet in de badkamer naar beneden krijgen. Je voegt dus extra lagen toe die op hun beurt voor extra complexiteit zorgen. Een ding is zeker: de kosten pakken veel hoger uit dan wanneer je akkoord was gegaan met tien weken. En de kans dat je concessies moet doen, neemt significant toe.

Zo is het met webservices ook. Het is niet zo ingewikkeld om een webservice te bouwen die goed samenwerkt met vier andere webservices. Het al een stuk ingewikkelder om honderd webservices te laten samenwerken. En het wordt helemaal complex als die webservices ook nog eens via event streams realtime data van elkaar krijgen die ze realtime moeten verwerken. Net zoals met de bouw van een huis neemt de foutkans navenant toe met de complexiteit. Kortom, al je monolithische applicaties opknippen in microservices en die combineren met event streams is een mooi concept. Maar let er wel op dat je het niet teveel fragmenteert. Anders heb je, bij wijze van spreken, al die werklui tegelijkertijd in je huis rondlopen.

Eventually (in)consistent

"Er gebeuren veel acties tegelijkertijd waarbij de services elkaar onderling op de hoogte houden zonder dat er één versie van de waarheid is"

Microservices combineren met event streams betekent ook dat het concept ‘eventually consistent’ vergaande consequenties heeft. Zoals gezegd wordt de realtime actie niet eerst in een database weggeschreven. Er gebeuren veel acties tegelijkertijd waarbij de services elkaar onderling op de hoogte houden zonder dat er één versie van de waarheid is. Natuurlijk, als je heel goed over de architectuur nadenkt en alle maatregelen neemt die nodig zijn - lees: je huurt tien bouwopzichters in die een heel procedurehandboek volgen om ervoor te zorgen dat ze binnen hun domein en onderling goed afstemmen - kun je dit wel realiseren. Maar dat brengt hoge kosten bij de implementatie van de services met zich mee. En kostenbesparing was juist een van de redenen om met microservices te gaan werken. De vraag is dus hoe hoog de uiteindelijke kostenbesparing gaat zijn als je in je berekeningen ook het managen van de complexiteitskosten meeneemt.

Een ander aspect is dat we moeten accepteren dat de databases in bepaalde mate ‘eventually inconsistent’ zijn, simpelweg omdat je van tevoren weet dat er bij de afstemming altijd wel iets tussen wal en schip valt. Dat is misschien ook niet zo erg, mits je van te voren maar goede afspraken maakt welke fouten zeker niet gemaakt mogen worden. Dat maakt dus dat je heel goed moet nadenken over: in welke gevallen is het niet zo heel erg dat mijn data niet consistent zijn en in welke gevallen is het een ramp?

Begin klein met Kafka-as-a-service

Wat kun je doen om de consequenties te leren doorzien? Ervaring opdoen, maar dan klein. En dat kan, want steeds meer partijen bieden Kafka-as-a-service. Je betaalt dan bijvoorbeeld per transactie. Tevens bieden deze platformen meer functionaliteit dan de standaard Kafka-omgeving. Dit geeft je de mogelijkheid om met esp te spelen en te onderzoeken: wat kan ik ermee? Hoe zorg ik ervoor dat de data consistent blijven? Wat doe ik in geval van failure? En wat als zo’n failure leidt tot ‘eventually inconsistent’? Op deze manier bouw je stapje voor stapje aan je esp-ervaring.

Frenk Ochse, integratiespecialist bij Conclusion Virtual Sciences

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

"Een klant die langs je winkel loopt en die je wilt targetten met een persoonlijk aanbod"

Ik kan me voorstellen dat ESP als term hierdoor in het dal van desillusies belandt, de Kafkaëske situaties die hieruit voortkomen zorgen nu eenmaal voor een wantrouwen bij het winkelende publiek door impact op de privacy. De discussie over discriminerende algoritmen komen voort uit Event Stream Processing AI statements zoals:

WHEN Person.Gender EQUALS "man" AND Person.Clothes EQUALS "bontkraag" ACTION close door.

Natuurlijk zie ik de dingen weer 'zwart-wit' maar het stapje-voor-stapje leren met de AI gedreven ESP kent een zeer duistere uitkomst, de nachtmerrie van Kafka-as-a-Service doet vermoeden dat Frenk Ochse nog niet zo goed nagedacht heeft over de maatschappelijke impact van sommige technologie. Veel ESP beslissingssystemen zijn nog gebaseerd op de 'vooringenomen' statements welke zijn verkregen uit statistische analyses en deze algoritmische 'olifantenpaadjes' missen veelal de genialiteit van een 'meesterzet' waardoor ze makkelijk te 'hacken' zijn.

@Een Oudlid

Niet helemaal mee eens. Het onlangs door de rechter verboden SyRi systeem kijkt middels de koppeling van overheidsbestanden naar algemene afwijkingen. Die hoeven helemaal niet een per definitie een "dicriminatoir" algoritme te gebruiken.

Waar het hier om gaat is die ongewenste uitkomst waaruit blijkt dat een aantal specifieke groepen erop los fraudeert. Daar zijn onze rechters niet van gediend en worden de algoritmen vervolgens bestempeld als "teveel inbreuk makende op de privacy" en "instrijd met het recht op een prive-leven".

De financiele schade van al die fraude wordt afgewenteld op de samenleving om de lieve vrede te bewaren. Net zoals wanbetalers van ziektekosten premies niet worden aangepakt.

Net zoals de agenten die nu een andere kant moeten uitkijken als zij een bontkraag (jouw woord) zien rijden in een nieuwe Mercedes S-klasse vanwege "etnisch profileren".

Maar aangezien de overheid juist nu op zoek is naar geld, zal er wel weer een andere rechter komen die het vonnis "nog eens gaat bekijken". Uiteindelijk blijkt het idee toch te lucratief om te laten liggen.

KJ,
Ik kan me vergissen maar uitspraak aangaande SyRi lijkt vooral te gaan om het ontbreken van een democratische toetsing op een opsporingsssysteem. De Kafkaëske situatie waarbij een bewijslast niet te toetsen is omdat deze uit het ongerede komt wringt niet alleen met artikel 8 lid 2 van het Europees Verdrag voor de Rechten van de Mens (EVRM).

@Een Oudlid
Dan lijkt mij dat de enige remedie is het verplicht openbaar maken van de broncode in beide gevallen (SyRi en ESP).

KJ,
Als je de discussies volgt over algoritmen dan is transparantie hierin inderdaad één van de voorstellen maar deze remedie kent een weerbastige commerciële weerstand. En daarnaast is er natuurlijk ook nog zoiets als een exclusiviteit van data, hele discussie aangaande de privacy gaat tenslotte vooral om een 'derdenverstrekking' zonder toestemming. Als je oude rapport (nr. 86 uit 2011) van de Wetenschappelijk Raad Regeringsbeleid (WRR) leest over de wijze waarop de 'iOverheid' informatiesystemen met elkaar koppelt dan is rechterlijke uitspraak niet zo verrassend.

In figuur 1.1 van genoemde WRR rapport zie je de problematiek aangaande het 'koppelvlakken-circus' omdat de technische eenvoud van een uitwisseling aan gegevens tussen overheidsinstanties conflicteert met fundamentele rechten zoals privacy. Dat de overheid steeds vaker 'teruggefloten' wordt door rechters is vooral het gevolg van ons democratische Juvenalis dilemma. Kafka en het proces gaat dan ook niet om de leesbaarheid van de code maar om een begrijpelijkheid van beslissingen welke steeds vaker zijn gebaseerd op informatiesystemen met een discutabele kwaliteit aan data doordat de context van metadata nog weleens verloren gaat in een uitwisseling aan gegevens.

Eind jaren 60 schreef E.W. Dijkstra het bekende artikel “Go To Statement Considered Harmful”.
In hoeverre wijken events eigenlijk af van het beruchte goto-statement?

Waar je met GoTo nog naar één plaats in de code springt, daar kun je met een event tegelijk (!) naar alle plaatsen in de architectuur springen waar dat event wordt geconsumeerd.

Kortom: met goto-statements maak je spaghetti-code en met events (of event triggers) maak je spaghetti-architecturen.

Terwijl we al sinds jaar en dag weten dat we juist naar lasagne-architecturen toe moeten.

Het verbouwen van een huis is overigens een mooi voorbeeld van een zin- en doelgedreven uitdaging. Event gedreven is meer een vorm van adhd en dat krijg je inderdaad bij gebrek aan focus op doelen.

Jack,
Een event-driven lasagne architectuur is heel goed mogelijk als je (privacy-by-design) hekwerken aanbrengt in je oplossing. En dit kan dus al heel eenvoudig door een scheiding van data, het 'ontkoppelen' zou de overheid (volgens WRR) ook eens moeten doen want deze negeert nu nog grondwettelijke vrijheden zoals het recht om onbespied te mogen leven. Een beter passend voorbeeld is het gedicht van Rudyard Kipling over de vragen van wat, waarom, wanneer, waar, wie en hoe als het om de GOTO statements gaat. Tenslotte kan hier al een vooringenomenheid in zitten die vaak tot een omgekeerde bewijslast leidt. Bij de gedachte van eens een boef, altijd een boef vertrouwt de waard zijn gasten zoals hij zelf is als je in omgekeerde volgorde Rudyard Kipling leest.

@Jack Moeilijk artikel begrijp er niet veel van maar de computer is in essentie event driven naar mijn idee. Op laag niveau met zijn interrupts, het web is event driven maar ook als je aan gui's programmeert (os, web) dan heb je ook te maken met events. Naar mijn idee staat het verhaal over de goto statement daar los van. Nu met javascript in de weer, gaat alleen maar over events. Wel lastig!

jack,
in de echte world wide wereld wil je toch multi user op knoppen duwen en verwacht je een consistent en responsive gedrag van de applicatie.
nix mis met event driven oplossingen in design, als je rekening houdt met de in het artikel genoemde zaken.

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2020-02-05T11:37:00.000Z Frenk Ochse
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.