'Pull' en 'Push' Architectuur
Casper
Informatie en data 'trekken' en 'duwen' (click here for English version)
In dit blog wil ik het hebben over ‘Pull’ en ‘Push’ Architectuur.
Grappig is dat het ene niet zonder het andere kan om tot een evenwichtige balans te komen. Net als de tegel-wijsheid vermeldt “Op de deur van succes staat zowel duwen als trekken”.
Om dieper in te gaan op het onderwerp wil ik de twee concepten even van een dagelijks voorbeeld voorzien. De ‘Pull’ of trekken kennen we allemaal van uit het bezoeken van een (traditionele) website. Je trekt informatie (webpagina of data) van een (web-) server. Het initiatief ligt bij de aanvrager, jou. Bij een ‘Push’ kun je denken aan de notificaties welke je ontvangt op een device, bijvoorbeeld telefoon. Het initiatief ligt dan bij de verzender, bijvoorbeeld een nieuwssite (NOS, RTL etc.). Een belangrijke is de NL-Alert. Dit bericht waarschuwt je en wordt verzonden vanuit de overheid (hulpdiensten bijvoorbeeld). Beetje ingewikkelder wordt het als het een combinatie is van de twee (Pull en Push). Ik heb niet voor niets in het eerste voorbeeld het woord ‘traditioneel’ gebruikt. Je ziet steeds vaker dat er informatie initieel ge-‘pulled’ wordt vanaf een locatie en zodra de verbinding er is aanvullende informatie ge-‘pushed’ wordt.
In een goede moderne architectuur zie je in feite hetzelfde gebeuren aan de top worden gegevens (data) ge-‘pulled’. De onderliggende laag gebruikt (micro-) services en het push principe voor bewerkbare processen en de data op strategische locaties te zetten. Je ziet dit vaak samen met een soort van messagebus waar microservices op geabonneerd zijn. Je kunt deze lijn doortrekken naar software architectuur (binnen de microservices) ‘Event-Driven-Development’ (EDD).
Okay, waarom hebben we het nodig? Simpel. We beschikken over steeds meer en complexere data en willen daar snel informatie uit extraheren liefst op maat naar persoonlijke wensen, op verschillende platformen
(website, mobile, koppelingen, etc.). Het is daarom belangrijk om gegevensverzamelingen te groeperen en vanuit die groepen pull requests te faciliteren. Tussen de gegevensgroepen kan de data doormiddel van het ‘push’-principe geüpdate worden door bijvoorbeeld (micro-) services. Die gegevensgroepen kunnen dan redundant (schaalbaar) worden uitgevoerd al naar gelang de behoefte naar beschikbaarheid of snelheid. Zo voorkom je dat de core-architectuur vastloopt. Koppelvlakken met big data structuren (zie ook voorgaande blog ‘Big Data’, https://www.casperotto.nl/big_data_strategie) kunnen hiermee worden gelegd en je kan op een meer Agile manier inzichten verkrijgen (zie ook voorgaande blog ‘Business Intelligence’, https://www.casperotto.nl/business_intelligence). Uiteindelijk is het doel om een schaalbaar en flexibel concept neer te zetten waarop een organisatie haar business strategieën kan vorm geven. Voor zowel nu als in de toekomst.
Zo’n Pull en Push architectuur is nooit echt af, soms moet je verzamelingen opnieuw definiëren (refractor) om de slagkracht te behouden of te versterken. Een goede architectuur is altijd in beweging; ‘... Werk aan de winkel ...’.
Casper.
Bronnen:
A Temporal Analysis of Posting Behavior in Social Media Streams
Efficient Monitoring Algorithm for Fast News Alert
DCCast: Efficient Point to Multipoint Transfers Across Datacenters
Blog
Eindelijk is het zo ver. Na lang testen, veranderen en ‘bij-’schaven kunnen we starten met de onthulling. Na maanden gewerkt te hebben aan het product gaat de wereld er kennis mee maken. Hoe pak je dat aan. In dit vierde deel van de reeks wil ik daar dieper op in gaan.
Het idee is geboren, de ooievaar is geland. Hoe pak je als organisatie door? Welke stappen moet je nemen om het idee een goede overlevingskans te geven?
Dit blog is de tweede in de serie en gaat over creativiteit in relatie tot productontwikkeling.
Productontwikkeling het begint vaak met een idee, een gedachte aan iets nieuws, beetje in de zin van; “Wat zou het mooi zijn als …..”. Hoe ga je daarmee om binnen een organisatie. Deel 1; "De harde aspecten".
Laatste tijd hoor ik er veel over in de media; - datalekken -. We leggen veel data vast in systemen welke relatief makkelijk zijn in gebruik. Wat kun je als organisatie doen om misbruik tegen te gaan?
Een ' must have ' voor iedere organisatie. (click here for English version)
Websites, slimme apparaten, het internet der dingen (IOT) het lijkt wel een stofzuiger voor het verzamelen van data, veel data. Als je naar de curves in de grafieken kijkt van hoeveelheden data die worden opgeslagen zie je dat exponentieel toenemen; “Big Data”.
Dit blog gaat over het ontstaan van een digitaal platform, in mijn subtitel aangegeven als ‘woud’. Steeds meer organisaties ontdekken de meerwaarde van een digitaal platform, maar worstelen met de invulling ervan.
De afgelopen periode zijn er veel apparaten en mogelijkheden bijgekomen. We leven in een technologie tijdperk. Soms vraag ik me wel eens af of de techniek er is om ons te helpen of andersom? Omnichannel Strategie kan je daar bij helpen, mits je hem aanvliegt vanuit de gebruiker.
Nu er veel nagedacht wordt over Digitale Transitie rijst de vraag; “ Wat doen we met al die digitale gegevens? ” Waar vroeger de website het eindstation was zijn er anno 2020 betere oplossingen. Waarom je beperken tot een website, of mobiel? “ -- Mobile first -- ” is een veel gehoorde kreet. Ik pleit er voor dat om te bouwen naar “ -- API-first -- ” (API staat voor; Application Programming Interface). Als we de software architectuur verdelen in een voor- en achterkant en we zetten daar een laag tussen die dat allemaal verbindt. We waren immers toch al bezig met het schaalbaar maken van de backend systemen (achterkant) in het kader van de digitale transformatie (Lees ook mijn blog over Digitale Transformatie , https://www.casperotto.nl/digitale_transformatie ). Hoe mooi is het als je een API-laag creëert waarop je alles zou kunnen aansluiten: een website of een mobiele applicatie of een koppeling met een ander platform of ….. wat je maar wil. Je bent flexibel om te doen wat voor jouw bedrijf het beste is. Bijvoorbeeld voor klanten een portaal realiseren waar ze zaken zelf kunnen regelen. Of koppelen met een ander portaal van een partner bedrijf. Ongekende mogelijkheden. Van belang is wel om de digitale transformatie goed door te voeren. Als systemen op een goede manier gekoppeld zijn heb je daar veel profijt van. Belangrijke vraagstukken zul je moeten beantwoorden (onder andere); • Welke delen van de architectuur gedragen real time, welke niet? • Waar leg ik gegevensverzamelingen aan? • Waar moet ik buffers creëren om niet (te) afhankelijk te zijn van andere systemen? • Waar maak ik gebruik van API’s en waar van (micro) services? Belangrijk is om goed het evenwicht in het oog te houden. Net als met alle goede apparaten moeten de componenten in balans zijn. Alleen dan werkt het optimaal samen. Naast het technische is het ook belangrijk dat je een groep met de juiste mensen samen stelt. Met focus op techniek, business en financiën. Multi disciplinair, laat ze samen werken, stel kaders op maar zo min mogelijk doelen. Laat het team dat doen, je kunt de uitkomst toetsen aan de strategie welke je voor ogen hebt. Misschien word je wel verrast met een uitkomst die je niet voor mogelijk had gehouden. Dat geeft je als ondernemer ook een boost, nieuwe terreinen verkennen, nieuwe dingen leren en ontdekken. Iedere disruptieve gebeurtenis, hoe vervelend ook, opent de deur voor nieuwe kansen en oplossingen. Laten we er wat mee doen! Casper. https://www.casperotto.nl/ https://www.casperotto.nl/blog