Eventit ja integraatiot vuonna 2022

Integraatioasiantuntijamme Sasu Mikonranta ja Janne Nieminen kertovat tässä blogissaan tapahtuma- eli event-pohjaisen integraatioarkkitehtuurin uusimmista tuulista ja aihepiirin kehityssuunnista.

Tapahtumapohjainen arkkitehtuuri

Tarkastelimme tapahtumapohjaisuutta integraatioissa viimeksi pari vuotta sitten blogikirjoituksessa, mutta miten tilanne on kehittynyt? Moni organisaatio on tässä välissä ehtinyt jo harkitsemaan jonkin tapahtumavirtojen käsittelyalustan hankintaa, sekä osa on omaksunut näitä jo osaksi ympäristöään. Kerrataan alkuun hieman tapahtumapohjaisuutta ja sen päämääriä.

Tapahtumat itsessään eivät ole uusi asia, mutta tapahtumien ja tapahtumavirtojen hyödyntäminen osana IT-arkkitehtuuria on yleistynyt viime vuosina. Oikein hyödynnettynä tapahtumainformaatiosta voidaan saada toisen järjestelmän sivutuotteena uuden palvelun kulmakivi.

Tapahtumapohjaisella arkkitehtuurilla on pyritty vastaamaan entistä reaaliaikaisempiin liiketoimintavaatimuksiin sekä kasvavien datamassojen käsittelyyn. Siirtyminen alkoi tietokantakeskeisistä monoliiteista entistä hienojakoisempiin mikropalveluarkkitehtuureihin. Päivittäisten ETL-siirtojen sijaan tiedonsiirto toteutettiin reaaliaikaisemmin mikropalveluiden välillä hyödyntäen REST-rajapintakutsuja. Miksi kuitenkaan rajapintakutsut eivät ratkaisseet kaikkia ongelmiamme?

Rajapintakutsut perustuvat usein ”Request-Reply” -periaatteeseen. Tässä mallissa aktiivinen sovellus pyytää vastaanottajaa käsittelemään pyynnön ja odottaa saavansa kuittauksen, että pyyntö on käsitelty. Joissain tilanteissa tämä voi olla täysin validi tapa tehdä asioita. Tosielämässä kuitenkin ilmenee usein tilanteita, joissa näitä kutsuja joudutaan ketjuttamaan. Ketjun pituuden kasvaessa myös tapahtumaketjun käsittelyaika ja virhetilanteiden riski kasvaa. Näin voi tahattomasti syntyä useita kiinteitä kytköksiä palveluiden välille.

Vaihtoehtoisesti informaation lähettämisen sijaan järjestelmä voi tuottaa datamuutoksesta tapahtuman (event). Tässä tilanteessa datan tuottava sovellus ei varsinaisesti ota kantaa, miten, kuka tai ketkä sen tuottaman datan käsittelee. Informaatio tuodaan saataville ja siitä kiinnostuneet kuluttajat saavat päättää miten sen käsitellä.

Eventit ja event streamit

Tapahtumien käsittely voidaan karkeasti jakaa kahteen kategoriaan. Yksittäisten tapahtumien (single event) käsittelyyn, sekä tapahtumavirtoihin (event streams).

Järjestelmän tuottaessa eventin tästä kiinnostunut kuluttaja tekee tilauksen (subscribe) eventin tuottavaan järjestelmään (pub/sub-malli). Tilauksen teon jälkeen kuluttava sovellus saa jatkossa tietoonsa tilatun järjestelmän tuottamat uudet eventit. Tieto saadaan välittömästi sen muuttuessa, eikä tarvetta epäoptimaalisesti ajoitetuille kyselyille datan perään enää tarvitse tehdä. Sovellus toimii reaaliaikaisemmin ja muutokset järjestelmien välillä saadaan näkymään entistä nopeammin, jopa lähes välittömästi eventin synnyttyä.

Eventit tulevat kuitenkin tarjolle vain kerran ja jos luontihetken ohittaa, voi yksittäinen tapahtuma jäädä kuluttavalta sovellukselta kokonaan väliin. Tässä astuvat mukaan tapahtumapohjaiset alustat, kuten esimerkiksi Apache Kafka.

Tapahtumapohjaiset alustat ovat suunniteltu jonomaisiksi, mutta toisin kuin jonot, tapahtumapohjaiset alustat ovat tarkoitettu myös säilömään informaatiota tapahtumavirtana. Tuotettu tapahtuma lisätään osaksi datavirtaa muuttumattomana tietona, joka voidaan myös jaotella. Kuluttajat eivät varsinaisesti tilaa datavirtaa, vaan kuluttavat sitä omassa tahdissaan ja pitävät kirjaa käsitellyistä datoista position perusteella. Koska informaatio on saatavilla sen tuottamisen jälkeenkin, kuluttava sovellus voi missä vaiheessa vain hakea tarvitsemansa datan, vaikka tarvittaessa uudelleen. Jonopohjaisiin ratkaisuihin verrattuna tapahtumavirran kulutus voi skaalautua täysin eri mittaluokassa, koska yhdellä tapahtumavirralla voi olla jopa satoja eri kuluttajia. Eventtien käsittelyä voi pohtia muutaman suunnittelumallin kautta.

Event-patternit

Tapahtumiin perustuvassa tiedonvälityksessä käytetään monenlaisia suunnittelumalleja eli patterneja. Tässä esimerkkinä muutama yleisimmin käytetty malli ja niiden käytännön sovelluksia.

Event notification

Tämä malli on oikeastaan tapahtumapohjaisen kommunikaation perusta, ja on ollut käytössä pitkään. Järjestelmässä tapahtuu jotakin, ja siitä halutaan ilmoittaa kiinnostuneille kuuntelijoille. Tämä malli eroaa kuitenkin esimerkiksi jono- tai api-pohjaisesta viestinvälityksestä siinä, että itse eventin sisältö on hyvin suppea verrattuna perinteiseen sanomaan. Eventin on tarkoitus kertoa vain, että jotain on muuttunut, ja tapahtumasta kiinnostunut kuuntelija voi sitten reagoida tarpeen mukaan. Yleensä tämä tarkoittaa tapahtuman sisältämän tiedon avulla tehtävää hakua lähdejärjestelmästä ja tiedon päivittämistä johonkin toiseen järjestelmään.

Tätä mallia käytetään paljon julkisen pilven pilvinatiiveissa palveluissa. Alla olevassa kuvassa on esimerkki AWS:stä.

S3:een on konfiguroitu bucket, jossa Event Notification on päällä objektin luonnin yhteydessä. Tällöin bucket lähettää eventin aina, kun sinne luodaan uusi tiedosto. Eventtiä kuuntelee Lambda-prosessi, joka käy hakemessa bucketista eventissä mainitun tiedoston. Lambda vie tiedoston sisällöstä (esim. CSV-tiedosto) halutut tiedot DynamoDB-kantaan. Reagoimalla S3:n eventtiin suoraan Lambdan ei tarvitse pollata S3:a ja kysellä onko uusia tiedostoja, mikä on sekä tehokkaampaa että säästää AWS-kustannuksia. Lambdan tilalla voisi olla hyvin myös iPaaS-integraatioalusta, varsinkin jos käsittelyssä tarvittaisiin monimutkaisempaa logiikkaa, tai tiedon jakelemista useisiin järjestelmiin.

Vastaava event-pohjainen kommunikaatiomalli on laajasti käytössä muissakin julkisissa pilvissä ja parhaita käytäntöjä erityisesti pilvinatiivien palveluiden rakentamisessa.

Event-carried state transfer

Tämä malli eroaa edellisestä siinä, että nyt pelkän ”tämä objekti on muuttunut” -tiedon lisäksi eventti sisältää muutakin tietoa, josta lopulta ollaan kiinnostuneita. Edellisen tiedostoesimerkin sijaan kyseessä voi olla esimerkiksi ERP-järjestelmän generoima eventti. Sisällyttämällä eventtiin lisää tietoa pystytään välttämään eventin hyödyntäjän tarvitsema ylimääräinen hakuvaihe.

Haittapuolena eventin koko kasvaa, ja tärkeäksi tulee suunnitella eventin sisältö sellaiseksi, että se palvelee mahdollisimman hyvin kaikkia sen nykyisiä ja tulevia käyttäjiä. Tällöin keskeiseksi nousee eventin skeeman määrittely, ja tähän event-alustat tarjoavat apuvälineitä kuten esim. Amazon EventBridge Schema Registry tai Kafkan Schema Registry.

Esimerkkinä Microsoftin Dynamics 365 Finance and Operations tukee Business Eventtejä, joiden avulla voidaan lähettää tietoa muutoksista. Tässä esimerkissä myyntitilauksen hyväksyntä tai pysäytys triggeröi Business Eventin lähetyksen. Dynamics 365 mahdollistaa Business Eventtien ohjaamisen eri kanaviin. Tässä esimerkissä käytetään Azuren Event Gridiä eventtien ohjaamiseen Dynamics 365 Customer Serviceen, jotta asiakaspalvelu näkee reaaliaikaisesti asiakkaan tilausten tilan.

Change Data Capture (CDC)

Miten sitten muunnetaan integraatioarkkitehtuuri hyödyntämään eventtejä? Pelkän event-alustan käyttöönotto ei ratkaise asiaa: ongelmaksi muodostuu, pystyvätkö olemassa olevat järjestelmät tukemaan reaaliaikaisten eventtien käyttöä. Edellä olevan esimerkin mukaisesti jotkut modernit SaaS-järjestelmät jo tukevat eventtejä, mutta entä sitten vanhat perusjärjestelmät? Näissä tyypillisesti suoraa tukea ei ole, ja sen toteuttaminen voi olla työlästä.

Tätä ongelmaa helpottamaan event-alustoihin on luotu Change Data Capture (CDC) -toiminnallisuus. Sen avulla voidaan kytkeytyä olemassa olevaan järjestelmään, yleensä suoraan sen tietokantaan ja generoimaan kaikista muutoksista event, joka sitten ohjataan event-alustaan. Näin saadaan suhteellisen vähällä työllä lisättyä event-kyvykkyys vanhoihin järjestelmiin.

Alla olevassa esimerkissä sovelluksen SQL-tietokantaan kytkeydytään Debeziumin CDC-connectorilla, joka muuntaa sovelluksen tietokannan muutoseventit Kafka-yhteensopivaksi event streamiksi.

Event sourcing

Event sourcing on terminä sellainen, josta puhutaan paljon eventtien yhteydessä. Joskus törmää sellaiseenkin väärinymmärrykseen, että event-pohjainen arkkitehtuuri tarkoittaa event sourcingin käyttöä. Näin ei kuitenkaan ole, sillä kuten edellisissä esimerkeissä on kuvattu, event-pohjaisia patterneja on paljon muitakin. Itse asiassa event sourcing on edistyneimpiä event-arkkitehtuurin patterneja, joka ei ole vielä yleistynyt kovinkaan laajaan käyttöön.

Event sourcingin idea on, että eventtejä hyödyntävien sovellusten tila muodostuu joukosta tilasiirtymiä sovelluksen käyttöönoton jälkeen. Jokainen tilasiirtymä kuvaa muutosta jossakin sovelluksen entiteetissä. Käytetään esimerkkinä tilin saldoa. Sen sijaan että eventtien yhteydessä lähetettäisiin tieto uudesta saldosta, lähetetäänkin vain tieto siitä, miten saldo on muuttunut. Kun kaikki sovelluksen lähettämät tilitapahtumat käsitellään peräkkäin, saadaan tilin lopullinen saldo. Tästä seuraa, että itse asiassa event-säilöstä, johon eventit kirjoitetaan, tuleekin master-paikka, josta tilan voi päätellä. Eventtien käsittelytapa muistuttaa tietokannan transaktiolokin tai versionhallintajärjestelmän toimintaa.

Koska eventit pitää pystyä lukemaan alusta asti, on event sourcingin ehtona, että kaikki eventit pitää tallentaa – vanhoja eventtejä ei voi poistaa, koska muutoin sovelluksen tilan määrittäminen ei enää onnistu. Tallennustilaa tarvitaan tämän vuoksi reippaasti.

Kuten kuvauksesta voi päätellä, kyseessä on hyvin erilainen tapa ratkaista sovellusten synkronoinnin ongelma, ja se tuo mukanaan huomattavasti lisää monimutkaisuutta verrattuna esimerkiksi perinteiseen event-carried state transfer -patteriin. Etuna tässä tavassa on, että uudet, kyseisestä tiedosta kiinnostuneet sovellukset voivat lähteä lukemaan eventtejä streamin alusta lähtien, jolloin ne saavat sovelluksen entiteettien ajantasaisen tilan. Niin kutsuttu “alkulataus” saadaan siis automaattisesti. Tämän jälkeen sovelluksen riittää enää kuunnella uusia muutoseventtejä. Haittapuolena arkkitehtuuri monimutkaistuu. Lisäksi eventit tulee säilyttää periaatteessa ikuisesti, jolloin eventtien tallennuspaikka tulee kriittiseksi. Onkin erilaisia näkemyksiä siitä, mikä olisi sopivin säilytyspaikka muutoseventeille. Kafkaa tähän usein ehdotetaan, mutta siinä on omat haasteensa. Lisäksi on ihan tähän tarkoitukseen tehtyjä tallennusratkaisuja kuten Event Store.

Event-pohjaiset integraatiot

Integraatio eventin tuottajana

Tapahtuman välitys event-alustalle voidaan tehdä myös integraatioalustalla. Näissä tapauksissa integraation välittämä data tai integraation tekemien päivitysten muutoshistoria voidaan havaita hyödylliseksi tarjota muille kuluttajille.

Integraatio voi tässä käyttötapauksessa esimerkiksi noutaa datan lähdejärjestelmästä, rikastaa sitä ja lopuksi välittää osaksi tapahtumavirtaa. Tässä tapauksessa tapahtumavirta voi toimia integraation näkökulmasta kohdejärjestelmänä. Tapahtumavirtaan on taas yhteydessä järjestelmät, jotka lopulta kuluttavat kyseiset eventit virrasta.

Monet tuotteistetut integraatioalustat sisältävät valmiita kyvykkyyksiä, joiden avulla ne voivat integroitua tapahtumapohjaisiin järjestelmiin esimerkiksi valmiiden connectoreiden tai REST-rajapintojen kautta.

Myös integraation eri järjestelmiin tekemät päivitykset voivat olla muutoshistoriatiedoiltaan arvokasta tietoa.

Integraatio eventin kuluttajana

Reaaliaikaisempia integraatioita toteuttaessa integraatioalusta voi myös toimia eventin kuluttajana. Näissä käyttötapauksissa usein integraatioalusta on tilannut jonkin event-rajapinnan. Tämän tuottaessa eventin saa integraatioalusta tiedon muuttuneesta datasta ja pystyy välittömästi reagoimaan siihen. Riippuen eventin tyypistä integraatioalusta voi hyödyntää eventin tarjoamaa tietoa suoraan tai hakea sen välittämän viitteen kautta varsinaisen datan. Monesti myös kohdejärjestelmät eivät ole välttämättä valmiita lukemaan itse eventtejä, jolloin integraatioalusta voi toimia sovittimena tapahtuma-alustan sekä kohdejärjestelmän välillä.

Integraatioalustojen natiivi event-tuki

Puhuttaessa moderneista iPaaS-alustoista (Integration Platform as a Service) niiden natiivit event-kyvykkyydet ovat vielä kehitteillä. Kuten edellisistä esimerkeistä nähtiin, eventteja voidaan tuottaa ja tilata integraatioalustojen sisältämien teknologiaconnectoreiden, esimerkiksi Kafka- tai Salesforce-connectorin avulla. Mutta nämä connectorit kytkeytyvät jo olemassa olevaan event-alustaan – tarvitaanko iPaaS-alustan lisäksi aina toinen, erillinen event-alusta jos halutaan hyödyntää event-pohjaista arkkitehtuuria?

Monissa perinteisissä integraatioalustoissa on ollut olemassa jonopohjainen message broker joko sisäänrakennettuna tai sitten rinnakkaisena tuotteena. IBM App Connect Enterprise on pitkään käyttänyt IBM MQ:ta, joka tulee myös pub/sub-tyylistä event-välitystä vaikkakin perinteisten jonojen keinoin. Boomissa on Atom Queue -ominaisuus, joka mahdollistaa jonojen käytön Boomin eri integraatioprosessien välillä. Se ei kuitenkaan suoraan mahdollista niiden hyödyntämistä Boomin ulkopuolella, tai event-topiccien luomista. Boomiin on kehitteillä natiivi Event Streams -ominaisuus.

Azure Logic Apps ottaa hieman erilaisen lähestymistavan hyödyntäessään event-käsittelyssä muita Azuren natiiveja palveluita kuten Azure Service Bus (jonot ja topicit), Azure Event Grid (event-notifikaatiot) ja Azure Event Hubs (Kafka-yhteensopiva event-alusta). Vaikka näihin palveluihin löytyy connectorit, ne eivät ole täysin integroitu osaksi iPaaS-alustaa.

Tällä hetkellä integraatioalustat eivät yleisesti tarjoa natiivia tukea event-pohjaiselle arkkitehtuurille varsinkaan event streamien osalta. iPaaS-alustan rinnalle tarvitaan siis yleensä joku event-broker kuten Kafka tai pilvinatiivi palvelu kuten Amazon EventBridge hoitamaan event streamien välitystä.

Eventit tulevaisuudessa

Eventtien käyttö on viime blogin kirjoituksen jälkeen kasvanut, mutta valtavaa räjähdystä ei ole vieläkään nähty. Yritysten koko integraatioarkkitehtuuri ei ole muuttunut event-pohjaiseksi, vaan askeleita eventtien hyödyntämisessä on otettu sitä mukaa, kun uudet sovellukset niitä tukevat. Hyviä esimerkkejä ovat uudet SaaS-pohjaiset ERP- ja CRM-sovellukset, joiden viimeisistä versioista event-tuki alkaa jo löytyä.

Mitä muuta sitten on edessä eventtien osalta?

Event-hallinta

Kun eventtejä otetaan enemmän käyttöön, muodostuu arkkitehtuurista pakollakin enemmän asynkroninen. Tästä taas seuraa huonompi näkyvyys olemassa oleviin eventteihin ja niitä hyödyntäviin järjestelmiin. Toisaalta tarvittaisiin myös helppoja tapoja löytää jo olemassa olevia eventtejä ja ottaa niitä käytöön. Tarvittaisiin siis API-hallinnan kaltaisia governance-ominaisuuksia, tällä kertaa eventteihin sovellettuina.

API-hallintatuotteiden tekijät ovat heränneet tähän ongelmaan hieman hitaasti. Yksi ensimmäisiä tällaisen kyvykkyyden tarjoajia on IBM API Connect, joka laajemman Cloud Pak for Integrationin yhteydessä tarjoaa mahdollisuutta julkaista eventit osana API-hallinnan kehittäjäportaalia. Sitä kautta myös pystytään hoitamaan eventtien tilaukset ja hyväksymismenettelyt API-hallinnasta tutuilla välineillä ja prosesseilla.

API-hallinnan ulkopuolella toinen mielenkiintoinen eventtien hallintaa tarjoava tuote on Solacen PubSub+ Event Portal. Solace on kehittänyt event-portaalin ja tähän liittyvän discovery-työkalun, joka osaa etsiä nykyisestä ympäristöstä eventtejä ja viedä tiedot portaaliin. Tämän ympärille pystytään sitten lisäämään governance-ominaisuuksia, mikä tarjoaa arkkitehdeille ja kehittäjille paremman näkyvyyden eventtien käyttöön yrityksen sisällä.

Event-hallinta tulee varmasti olemaan tulevaisuudessa tärkeä osa eventtien hyödyntämisen mahdollistamista. IBM:n ja Solacen näkemykset ovat hieman erilaiset, mutta molemmissa on paljon potentiaalia. Muista API-hallinnan tarjoajista esimerkiksi Mulesoft tukee jo Event-APIen julkaisua rajatusti, ja muut isot pelurit tulevat taatusti perässä.

Digian suositukset

Suosittelemme erityisesti uusien järjestelmien käyttöönoton yhteydessä tarkastelemaan niiden tarjoamia event-kyvykkyyksiä. Integraatioita toteutettaessa on tärkeää, että integraatioarkkitehdit ja -kehittäjät pysyvät ajan tasalla eventtien tarjoamien mahdollisuuksien osalta, ja osaavat hyödyntää niitä tarvittaessa. Kun aiemmin opeteltiin kysymään integraatiotarpeen kartoituksessa ”Onko tälle olemassa APIa?”, nyt kysymyspakkiin voi lisätä ”Löytyykö tälle eventtiä?”. Koska event-alustoja ja standardeja on paljon, REST APIin verrattuna event-kysymys vaatii enemmän jatkokysymyksiä.

Luonteva ensimmäinen askel on hyödyntää jo käytetyn pilven kuten AWS:n tai Azuren omia natiiveja event-ominaisuuksia. Jos tiedossa tarvetta laajemmille event-välityksen ominaisuuksille, suosittelemme Apache Kafkaan tutustumista ja sen koekäyttöä. Positiivista on, että kahden vuoden takaiseen aikaan verrattuna nyt on helpompi löytää käyttötapauksia, joiden avulla omaa integraatioarkkitehtuuria voi lähteä ohjaamaan reaaliaikaisempaan suuntaan eventtejä hyödyntäen.

Integraatioarkkitehtuurin Fast Track: tiekartta tulevaisuuden ratkaisuihin, lue lisää >