Bij event-driven architectuur is dat geen hypothetische vraag. Het verschil tussen Event Grid, Service Bus en Event Hub bepaalt of je dit risico loopt, en de meeste teams weten dat niet.
De aanname die keer op keer misgaat
Bij Cloud Republic werk ik als Cloud Solution Architect en kom ik regelmatig bij klanten binnen die met event-driven architectuur werken op Azure. Daarbij valt me steeds hetzelfde patroon op: teams kiezen Service Bus, Event Grid of Event Hub, maar niet altijd om de juiste reden.
Zelf ben ik al een tijd bezig met een eigen tool om Service Bus en Event Hub inzichtelijk te maken: berichten queuen, dead-letter queues uitlezen, dat soort dingen. Die bezigheid heeft mijn interesse in event-driven architectuur alleen maar aangewakkerd. Hoe meer je in de interne werking van deze diensten duikt, hoe duidelijker het wordt dat het geen onderling inwisselbare opties zijn.
Toch worden ze in de praktijk vaak wel zo behandeld. Ik zie bij klanten regelmatig dat het verschil tussen Event Grid en Service Bus niet helder is, met als gevolg dat kritieke berichten verloren gaan. Of dat Service Bus wordt ingezet in een scenario waar Event Hub goedkoper was geweest en beter had geschaald. Die verwarring is het uitgangspunt van dit artikel.
Toen berichten stilletjes verdwenen
Een van de projecten waar dit misverstand het duidelijkst naar voren kwam, was een IoT-platform. Een actie op een apparaat moest leiden tot een reactie ergens anders in het systeem: andere onderdelen moesten weten dat er iets was gebeurd. Voor die communicatie werd Event Grid ingezet.
Op papier een logische keuze: Event Grid is gebouwd voor dit soort event-notificaties en is snel. Alleen garandeert Event Grid geen aflevering. Komt een bericht om wat voor reden dan ook niet aan, dan is het weg. Geen retry die je kunt sturen, geen bericht dat je opnieuw kunt afspelen. Dat is geen fout van Event Grid, het is gewoon niet ontworpen voor gegarandeerde aflevering.
In de praktijk betekende dit dat berichten soms zoek raakten. Acties op apparaten bleven hangen in het systeem zonder dat er ergens een reactie op volgde. Voor een IoT-platform waarin apparaten en systemen op elkaar moeten kunnen vertrouwen, is dat geen kleine bug. Het ondermijnt de betrouwbaarheid van het hele platform, en dat soort problemen valt pas op als het al een keer misgegaan is.
Drie diensten, drie beloftes
Het IoT-voorbeeld laat zien wat er misgaat als je Event Grid gebruikt op een plek waar aflevergarantie nodig is. Service Bus was hier de betere keuze geweest. Service Bus garandeert aflevering en is daarnaast relatief snel. Belangrijker nog: als een bericht om wat voor reden dan ook faalt, kun je het opnieuw afspelen. Bij Event Grid is een verstuurd bericht in principe weg, bij Service Bus heb je die vangnetten wel.
Maar Service Bus is ook geen universele oplossing, en dat zag ik terug in een ander soort setup. Daar werd Service Bus ingezet als lijmlaag tussen meerdere systemen: een update in systeem 1 moest doorwerken naar systeem 2 en 3. Werkbaar, tot op zekere hoogte. Alle filterlogica werd vastgelegd in Service Bus rules, en dat maakte de setup complex. Daarnaast liep het volume aan berichten regelmatig tegen de storage limieten van de topics aan.
Voor die situatie was Event Hub logischer geweest. In plaats van rules per consumer te definiëren, heb je één stream aan berichten waarin iedere consumer zelf bepaalt wat voor hem relevant is. Geen rules-beheer, geen topic-limieten die je in de weg zitten bij grote volumes.
Wat deze twee voorbeelden samen duidelijk maken: de drie diensten zijn niet onderling inwisselbaar, ze zijn gebouwd voor verschillende garanties en schaal. Event Grid is licht en snel, maar zonder aflevergarantie. Service Bus geeft je die garantie en replay, maar wordt onhandelbaar zodra de filterlogica en het volume groeien. Event Hub is gebouwd op juist dat volume, met één stream in plaats van individuele rules per consumer.
Event Grid | Service Bus | Event Hub | |
|---|---|---|---|
| Aflevergarantie | ✗ | ✓ | ∼ |
| Replay-mogelijkheid | ✗ | ✓ | ✓ |
| Typisch schaalpatroon | Licht volume, snel | Gemiddeld volume | Groot volume, meerdere afnemers |
Mijn vuistregel: snelheid, standaard, of schaal
Uit dit soort situaties heb ik voor mezelf een simpele vuistregel gedestilleerd, die ik ook aan klanten meegeef.
Moet het echt snel en is aflevergarantie geen harde eis? Dan is Event Grid de juiste keuze. Voor korte, event-gedreven notificaties waarbij snelheid vooropstaat, is Event Grid gebouwd.
Voor de meeste applicatieontwikkeling is Service Bus mijn standaard. Zodra je aflevergarantie, ordering, of replay nodig hebt, en berichten vaak specifiek voor een beperkt aantal services zijn, is Service Bus de veilige default.
Gaat het om grote datavolumes, met meerdere afnemers en potentieel meerdere producenten van vergelijkbare data, dan kijk ik naar Event Hub. Dat is precies het scenario waarin Service Bus vastloopt op rules en topic-limieten, en waar één stream met consumers die zelf filteren beter past.
Die vuistregel is geen exacte wetenschap. Sommige systemen hebben uiteindelijk alle drie de diensten naast elkaar nodig, elk voor het deel van de communicatie waar ze voor gebouwd zijn.
Zonder tracing tast je in het duister
Een les die niet uit de drie diensten zelf komt, maar uit het werken met event-driven systemen in het algemeen: zorg dat je traceability op orde hebt.
Event-driven systemen zijn inherent lastiger te doorgronden dan een synchrone request-response flow. Een bericht gaat een systeem in, en ergens verderop, soms via meerdere hops, gebeurt er iets mee. Zonder goede tracing is uitzoeken wat er precies is gebeurd, en waar het misging, nagenoeg onmogelijk. Je zit dan te gokken in logs van losse componenten, zonder dat je het verband tussen die logs kunt leggen.
De meeste SDK’s van Microsoft ondersteunen inmiddels OpenTelemetry, waarmee je distributed tracing goed kunt inregelen. Zelf gebruik ik dit vaak in combinatie met Application Insights, simpelweg omdat dat goed wordt ondersteund en naadloos integreert met de rest van Azure. Er zijn genoeg alternatieven, maar de kern blijft hetzelfde: bouw tracing niet achteraf in als noodoplossing, maar vanaf het begin.
Conclusie
De grootste valkuil bij Event Grid, Service Bus en Event Hub is niet de techniek zelf, maar de aanname dat het onderling inwisselbare opties zijn. Dat kostte in de praktijk aflevergarantie, overzicht, en soms simpelweg schaalbaarheid.
Wat daarbij minstens zo belangrijk is: zorg voor goede tracing vanaf het begin. Event-driven systemen zijn al complex genoeg zonder dat je blind moet varen op losse logs. De juiste dienst kiezen lost een deel van het probleem op, maar zonder zicht op wat er door je systeem stroomt, blijf je gokken.
Twijfel je tussen Event Grid, Service Bus of Event Hub voor een specifiek scenario? Leg de situatie aan ons voor, dan kijken we samen wat het beste past.
