Näin valitset yrityksellesi oikean integraatioratkaisun

Oikean integraatioratkaisun valitseminen yrityksellesi voi olla haastavaa, sillä vaihtoehtoja on monia. Digian ratkaisuarkkitehti Tero Niemistö neuvoo, miten päädyt oikeaan valintaan.

integraatiovalinta.jpg

Oletko valitsemassa yrityksellesi uutta tai ensimmäistä integraatioratkaisua, mutta eri vaihtoehdot saavat sormen suuhun? Houkutteleeko DIY ratkaisu ilman kalliita lisenssimaksuja, vai tarvitsetko tukea päätöksellesi hankkia palveluväylä?

Tässä blogissa esittelen 4 + 1 eri vaihtoehtoa integraatioratkaisuksi. Mikä niistä soveltuu parhaiten teidän yrityksellenne?

1. DIY eli ”Tein itse ja säästin”

Ajatus integraatioratkaisun toteuttamisesta itse voi tuntua monella tapaa houkuttelevalta. Siten ratkaisun voi toteuttaa millä tahansa teknologialla ja moderneja mikropalveluarkkitehtuurimalleja hyödyntäen. Et myöskään joudu maksamaan kaupallisista ratkaisuista, joten säästät rahaa. Eikö?

Ei aina. Pitkässä juoksussa itse tehty ei aina ole halvin vaihtoehdoksi. Monien valmiiden integraatioratkaisujen taustalla on vuosikausien tuotekehitys, jonka avulla ratkaisut ovat vikasietoisia, skaalautuvia, tietoturvallisia eivätkä sisällä juuri ollenkaan yllättäviä bugeja.

Jos pohdit tee-se-itse ratkaisua, kannattaa käydä läpi alla oleva lista. Mikäli vastaat vähintään viiteen väittämään ’kyllä’, tee-se-itse ratkaisu saattaa olla järkevin vaihtoehto sinulle.

  • Toisiinsa integroitavia järjestelmiä on hyvin vähän
  • Järjestelmät kommunikoivat vain yhdellä protokollalla (SOAP, JMS, jne.)
  • Integraatiot pysyvät kutakuinkin staattisina, eikä niitä ole tulossa lisää
  • Integraatiot ovat järjestelmän sisäisiä ilman käyttöoikeuksien rajauksia tai roolituksia
  • Sanomien määrä pysyy kohtuuden rajoissa (alle 5k/sec)
  • Sanomien reitityslogiikkaa ei ole tai se on hyvin yksinkertainen

Pro tip: Mikäli integraatiojärjestelmää lähdetään rakentamaan tyhjästä itse, kannattaa valita toteutusteknologiaksi tilaton ohjelmointikieli, kuten NodeJS tai Clojure.

2. Message Queue – Jonopalvelin

Jonopalvelin, eli MQ, on sanomien välitykseen tarkoitettu asynkroninen kommunikointiväline. Se sisältyy usein muihin laajempiin integraatioratkaisuihin, kuten palveluväylään.

Jonopalvelimen käyttö on perusteltua, mikäli suurin osa oheisen listan vaatimuksista täyttyy. Yksi yleisimpiä jonopalvelimen käyttökohteita on esimerkiksi publish/subscribe -ratkaisut.

  • Sanomien määrä on kohtalaisen suuri (yli 10k/sec)
  • Integroitavia järjestelmiä on kohtalaisesti
  • Tarvitaan käyttäjähallintaa
  • Tarvitaan monimutkaista reitityslogiikkaa
  • Tarvitaan online/offline -tuki
  • On varmistettava, että sanomien kuluttajat saavat sanomansa oikeassa järjestyksessä
  • Tarve useampiin protokolliin

Jonopalvelinta on saatavissa avoimen lähdekoodin ratkaisuna ja kaupallisena vaihtoehtona tuotetuen kanssa.

3. Integraatiokehys

Integraatiokehyksellä tarkoitetaan komponenttikirjastoa, joka tarjoaa valmiita työvälineitä ja toiminnallisuutta monimutkaisten integraatioiden toteutukseen.

Integraatiokehykset sisältävät usein jonkinlaisen jonopalvelimen, sekä sen päälle rakennettua toiminnallisuutta. Mikäli vastaat suurimpaan osaan alla olevista väittämistä ’kyllä’, voi integraatiokehys olla paras ratkaisu teidän yrityksellenne.

  • Kts. yltä Message Queue -vaatimukset
  • Integroitavia järjestelmiä on paljon
  • Tarve hyödyntää Enterprise Integration Patterneja (EIP)
  • Tarve yksinkertaisiin sanomamuunnoksiin
  • Tarve koota vastaus useasta kohteesta sekä synkronisesti että asynkronisesti

Integraatiokehyksiä on tarjolla esimerkiksi Java- (ServiceMix, Spring Integration) ja .NET-ohjelmointikielille (NServiceBus).

4. ESB - Palveluväylä

Kun integraatioratkaisulta vaaditaan paljon ja sen jatkuva kehittäminen ja tuottaminen ovat yrityksen keskiössä, on palveluväylä (ESB) oikeastaan ainoa ratkaisuvaihtoehto yrityksen tarpeisiin. Tarkista alta, onko vastauksesi väittämiin ‘kyllä’.

  • Kts. yltä Integraatiokehyksen vaatimukset
  • Integraatiot muuttuvat tiheästi ja niitä luodaan/poistetaan säännöllisesti
  • Tarve monimutkaiselle reitityslogiikalle
  • Tarve monimutkaisille sanoma- ja protokollamuunnoksille
  • Tarve valmiille monitorointituelle ja hallinnalle
  • Tarve korkeamman tietoturvan integraatioalustalle

Markkinoilla on useita palveluväyläratkaisuja, joista suurin osa on kaupallisia tuotteita tuotetuella.

+1. Tulevaisuuden trendi: Stream Processing

Entä tulevaisuuden trendit? Mitä integraatioiden kristallipallossa näkyy? Eräällä nosteessa olevalla teknologialla voidaan käsitellä käsitellä erittäin suuria datavirtoja laitteiden internetissä (IoT).

Suurista datavirroista puhuttaessa tapahtumien ja sanomien määrä nousee helposti yli 100 000 sekunnissa, parhaimmillaan voidaan puhua jopa miljoonista. Kun tähän yhdistetään tarve reaaliaikaiselle ja aikaikkunoihin pohjautuvalle analytiikalle, perinteiset integraatioratkaisut nostavat kädet pystyyn. Tällöin ainoa keino löytyy ns. Stream Processing -alustoista. Stream Prosessing -alusta on eräänlainen paranneltu versio perinteisestä jonopalvelusta.

Stream Processing poikkeaa perinteisestä integraatiosta merkittävällä tavalla. Kun perinteisessä integraatiossa keskitytään varmistamaan sanomien päätyminen haluttuun kohteeseen asynkronisesti, Stream Processing -teknologiaa ei kiinnosta, mihin data päätyy tai kuka sitä käyttää.

Teknologia ohjaa dataa ”virtoihinsa”, joista kuka tahansa voi sitä poimia – joko reaaliaikaisesti tai tietystä aikaikkunasta käsin. Lisäksi virtojen dataa voidaan analysoida reaaliajassa.

Alla on lueteltuna joitakin vaatimuksia, joiden tulisi täyttyä, jotta Stream Processing olisi varteenotettava vaihtoehto:

  • Sanomien määrä on todella suuri (esim. 100k/sec). Käytännössä tarvetta esiintyy IoT-maailmassa
  • Tärkeintä on saada sanomat tuottajilta aikajärjestyksessä
  • Tarve hakea sanomia määritellyltä ajanjaksolta (esim. edellinen viikko, viimeiset 2 tuntia, jne.)
  • Tarve tehdä haetuilla sanomilla ja niiden sisällöllä laskentaa ja analytiikkaa ennen paluuarvoa (esim. edellisten 2 tunnin keskiarvo sanoman kentässä XYZ)

Stream Processing -alustoja on saatavilla avoimen lähdekoodin ratkaisuina sekä kaupallisina tuotteina. Lisäksi eräät pilvipalvelut (AWS) tarjoavat tällaisia alustoja suoraan pilvestä.

Kuuntele webinaari!

integraatio




Tero Niemistö | Tiimiesimies, teknologia-johtaja

Tero Niemistö | Tiimiesimies, teknologia-johtaja

Tero on ”managerisoitunut” pitkän linjan arkkitehti. Noin 14 teknisen vuoden jälkeen Tero siirtyi esimiesrooliin tahtonaan johtaa alan huippuasiantuntijoita kuten itseään haluaa johdettavan. ”Esimiehen tärkein tehtävä on mahdollistaa alaistensa onnistuminen”, Tero sanoo. Teron johtamisfilosofiassa esimies ei ole perinteisen hierarkisen mallin mukaisesti joukkojen yläpuolella vaan tukee heidän päivittäistä työtä alhaalta. Hän haluaa olla läsnä ja kiinnostunut alaistensa arjesta sekä tukea heitä sparraamalla ja valmentamalla niin usein kuin mahdollista. Kun Tero laittaa ns. haalarit päälle ja kädet saveen, niin hänet löytää usein julistamassa DevOps-kulttuurin ilosanomaa ja rakentamassa sovelluskehityshankkeisiin täysin automatisoitua jatkuvan julkaisun putkea.

Kirjoittajan kaikki blogitekstit

Tilaa blogikirjoitukset sähköpostiisi




Seuraa meitä somessa

LinkedIn Twitter Facebook YouTube YouTube