Integraatiot eivät ole mitään uutta
Niin kauan kuin on tarve liittää eri ohjelmia, ohjelmistoja tai tietojärjestelmiä yhteen, on myös tarvetta integraatioille. Integraatiojärjestelmä voi toimia niin lähettinä, tulkkina kuin tekijänäkin.
Kaikki saa kuitenkin alkunsa tarpeesta – mitä pitää yhdistää ja miten.
Näitä tarpeita myös riittää. Maailmassa on lukematon määrä erilaisia ohjelmia ja järjestelmiä sekä yrityksiä, jotka hyödyntävät niitä. Yritysten tehdessä yhteistyötä keskenään voi eri järjestelmien yhteensopimattomuus tulla tielle: tässä kohtaa esiin astuu integraatio. Integraatio pitää huolen siitä, että järjestelmät kykenevät kommunikoimaan ja toimimaan keskenään, jättäen yrityksille aikaa ja resursseja keskittyä omien liiketoimiensa kehittämiseen ja ylläpitämiseen.
Mitä moderneilta integraatioilta tänä päivänä sitten vaaditaan? Miten IT-alan nykyaikaiset kehityssuuntaukset ovat muovanneet integraatioiden anatomiaa? Mitä AWS tarjoaa modernien integraatioiden rakentamiseen? Miten me Skillwellillä olemme asian ratkaisseet? Tässä artikkelissa vastaamme näihin kysymyksiin.
Ketteryyttä integraatioihin pilvipalveluista
Yksi nykyaikaisista kehityssuuntauksista sovelluskehittämisessä sekä IT-alalla yleensäkin on ketteryys. Projektityöskentelyn osalta on havaittu, että vaatimusmäärittelyissä harvemmin saadaan kaikki mahdolliset asiat kerralla tapetille, ainakaan missään järkevässä määräajassa, ja mikäli projekti ei kykene joustamaan muutosten tai puutteiden tullessa esille, ollaan hyvin nopeasti syvässä kuopassa, josta pois pääseminen ei tule helpolla.
Pilvipalvelut itsessään ovat myös alati kasvava kenttä. Nekin ajavat ketteryyttä, sillä pilvipalvelut ovat vieneet resurssien ja infrastruktuurin hallinnan konesaleista verkkoselaimeen, lähdekoodiin sekä komentoriville. Uuden palvelimen pystyttäminen ei enää vaadikaan raudan ostamista, tilan raivaamista ja laitteiston asentamista; konfiguraatioiden määrittäminen ja nappien painaminen selaimessa riittää.
Vielä pidemmälle asia viedään nk. serverless- eli palvelimettomuusmallin avulla: siinä taustalla olevien resurssien pystyttäminen on pelkistetty hyvin yksinkertaiseksi prosessiksi, missä iso osa siihen liittyvistä asioista on piilotettu kannen alle. Nimestään huolimatta palvelimettomissa palveluissa toki käytetään palvelimia – sovelluskehittäjän ei vain tarvitse sen kummemmin huolehtia niiden konfiguroimisesta tai ylläpitämisestä.
Ketteryys ja joustavuus ovat tehneet kauppansa myös integraatiomaailmassa. Avainsana on reaktiivisuus: sen sijaan että järjestelmien välisiä tapahtumia käsiteltäisiin isoissa erissä joko manuaalisesti tai ajastetusti, voidaan tapahtumiin reagoida silloin, kun ne tapahtuvat. Isojen pilvipalveluntarjoajien valikoimista löytyy monesti erinäisiä palveluita, joilla pystytään toteuttamaan tämäntyyppinen tapahtumavetoinen arkkitehtuuri.
Reaktiivisuus ei kuitenkaan ole mikään yleispätevä lääke kaikkeen; kaikki on edelleen kiinni asiakkaan tarpeesta. Joskus on järkevämpää suorittaa isompia ajoja silloin, kun järjestelmän käyttö on vähäistä. On myös mahdollista toteuttaa eräänlainen hybridiratkaisu, jossa tapahtumia kerätään ja tallennetaan käsiteltäväksi sitä mukaa kun niitä syntyy, mutta yhden ison ajon sijasta voidaan ajastaa useita ajoja tasaisin väliajoin.
Ketteryyden, joustavuuden ja reaktiivisuuden lisäksi integraatioilta halutaan myös muita ohjelmilta ja järjestelmiltä yleisesti haluttavia ominaisuuksia: skaalautuvuutta, vikasietoisuutta, kustannustehokkuutta, kansainvälisyyttä ja tietoturvallisuutta. Etenkin hyvän vikasietoisuuden tärkeys korostuu integraatioissa: järjestelmien välillä kulkevien viestien tulisi löytää tiensä varmasti päästä päähän, ja häiriötilanteissa niiden tulisi säilyä kunnes järjestelmä on jälleen toimintakuntoinen sekä valmis vastaanottamaan ja prosessoimaan niitä.
AWS:n tarjoamat mahdollisuudet integraatioiden ketterään rakentamiseen
Miten AWS eli Amazon Web Services sitten näkyy tässä kuviossa? Mitä AWS tarjoaa ja mikä mahdollistaa modernien integraatioiden rakentamisen? Joustavuus tavassa ajaa ohjelmia on yksi hyvä esimerkki.
Elastic Compute Cloud (lyh. EC2), yksi AWS:n vanhimmista palveluista Simple Storage Servicen eli S3:n ohella, tarjoaa asiakkaalle mahdollisuuden käynnistää virtuaalikoneinstanssin, jonne oma ohjelma tai ohjelmisto voidaan asentaa ja josta sitä voidaan tarjota ulkomaailmaan.
Elastic Container Service (lyh. ECS) taasen mahdollistaa esimerkiksi Docker-konttien suorittamisen EC2-koneiden päällä. ECS-palvelua on myös mahdollista käyttää palvelimettomalla tavalla AWS Fargaten avulla: Fargate hoitaa kulissien takana mm. EC2-instanssien käynnistämiseen ja konfigurointiin liittyviä asioita.
Toinen tärkeä AWS:n palvelimeton laskentapalvelu on AWS Lambda. Se on nk. FaaS-palvelu (Function-as-a-Service), joka myös mahdollistaa ohjelmakoodin suorittamisen ilman, että taustalla olevaa infraa tarvitsee sen tarkemmin määritellä. Lambda on eritoten rakennettu tapahtumiin perustuvaa arkkitehtuuria varten, sillä se yleensä käynnistyy jonkin tapahtuman seurauksena. Lambda tukee monta eri ohjelmointikieltä, ja se tarjoaa näillä kielillä kehitetyille ohjelmille valmiita ajonaikaisia ympäristöjä käytettäväksi.
Tämän tekstin kirjoitushetkellä AWS:n palveluvalikoimista löytyy yli 200 erilaista palvelua. Kaikki nämä palvelut eivät tietenkään voi olla olennaisia integraatioiden kannalta, osa niistä saattaa tuoda jotakin lisähyötyä ja tietyt palvelut ovat kriittisiä palasia mille tahansa järjestelmälle. Mitkä näistä palveluista sitten ovat olennaisimpia meidän näkemyksellemme moderneista integroinneista?
Skillwellin integraatioalustan anatomia
AWS Lambda on integraatioalustan lihasmuisti
Lambda-funktiot muodostavat integraatioalustan lihaksiston – ne ovat varsinaista integraatiotyötä tekevä palanen.
Lambda-funktiot käynnistyvät jonkin tapahtuman seurauksena, joka voi olla niin ajastus kuin jokin tapahtuma jossain toisessa palvelussa. Käynnistyttyään Lambda suorittaa sille annettua ohjelmakoodia, joka tekee sitä, mitä kyseisen funktion halutaan integraatiossa tekevän: esimerkiksi tietokantojen päivittämistä, sähköpostien lähettämistä tai tiedostojen muodostamista. Tämän toimintalogiikan eli “lihasmuistin” me rakennamme asiakkaan tarpeen mukaan.
Amazon Simple Queue Service ja API Gateway tuovat aistihavaintoja integraatioalustalle
Simple Queue Service on Amazonin viestijonopalvelu ja API Gateway on palvelu verkkoprotokollapohjaisten ohjelmointirajapintojen (esim. REST) luomiseen, julkaisemiseen ja hallintaan. Nämä palvelut yhdessä toimivat kuin ääreishermosto ja aistit. Ne tuovat kehon eri osille informaatiota, jonka pohjalta tehdä asioita.
API Gatewayn avulla voidaan tallentaa HTTP-pyynnöillä lähetettyjä viestejä SQS-jonoon; API Gateway on siis kuin silmät tai korvat, jotka aistivat ulkomaailmaa ja välittävät havaitsemaansa informaatiota eteenpäin ääreishermoston eli SQS:n kautta. SQS tallentaa tätä informaatiota jonoon, josta sitä voidaan hakea muiden palasten toimesta, jolloin SQS toimittaa myös hieman muistin virkaa.
Amazon EventBridge toimii kokonaisuudessa hermostona
EventBridge voi toimia integraatioalustalle niin keskushermostona kuin autonomisena hermostonakin. Se voi ohjata tapahtumia ja tekemistä reitittämällä AWS:n ja joidenkin kolmannen osapuolen palveluissa tapahtuvia tapahtumia muille palveluille.
EventBridge voi myös säädellä ajastuksin sitä, mitä ja miten usein tehdään: jokin tietty integraatioprosessi voidaan käynnistää vaikkapa viiden minuutin välein. Tällainen ajastaminen yhdistettynä SQS-palvelun viestijonon kanssa mahdollistaa aiemmin artikkelissa mainitun hybridimallin, jossa tapahtumiin ei reagoida täysin reaktiivisesti, mutta tietoa ei kuitenkaan pantata yhtä suurta ajoa varten. Sen sijaan jonoa puretaan jatkuvasti useilla lyhyemmillä ajoilla.
Amazon DynamoDB säilöö tietoa kuin aivot
DynamoDB on dokumenttitietokanta, integraatioalustan aivot. Siellä voidaan säilyttää integraatioalustalle ja integraatioille tärkeitä tietoja, kuten konfiguraatioita (miten jokin asia tulisi tehdä) ja ajohistoriatietoja (mitä on tehty ja miten siitä on suoriuduttu).
Yleensä Lambda kutsuu DynamoDB:tä suoraan tietojen hakemiseksi, ja Lambdat voidaan myös kytkeä käynnistymään DynamoDB-tauluihin kohdistuvien muutosten, kuten rivien päivittämisen, lisäämisen tai poistamisen, johdosta. Tähän käytetään DynamoDB Streams -nimistä palvelua.
Hyötyjähän tässä haetaan
Miten tämä arkkitehtuuri ja AWS:n palvelut sitten tukevat asiakkaan tavoitteita? Sitä voidaan selvittää tarkastelemalla integraatioalustaa aiemmin mainittujen hyvien ominaisuuksien kautta: ketteryys, joustavuus, reaktiivisuus, vikasietoisuus, kansainvälisyys, kustannustehokkuus ja tietoturva.
1. Ketteryyttä ja skaalautuvuutta
Yksi tärkeä ajattelutapa AWS-ympäristössä työskennellessä on IaC eli Infrastructure as code. Sen ideana on resurssien ja infrastruktuurin hallinta koodina: resursseja voidaan määritellä ja hallita koodin tavoin templaattitiedostoina, joita niitä tulkitsevat palvelut hyödyntävät resurssien pystyttämiseen juuri siten, miten ne on tiedostossa määritelty. AWS:n oma IaC-palvelu on CloudFormation, joka mahdollistaa sekä AWS:n että kolmannen osapuolten resurssien mallintamisen JSON- tai YAML-muotoisiin dokumentteihin.
AWS:n ja CloudFormationin avulla järjestelmä voidaan rakentaa ja määritellä täysin koodipohjan sisällä, ja koodipohja voidaan myös versioida AWS:n sisällä Gitin avulla käyttäen AWS:n omaa Git-repositoriopalvelua CodeCommitia. Tämä yhdistettynä AWS:n DevOps-palveluihin, kuten CodeBuildiin ja CodePipelineen, auttaa rakentamaan ketteriä kehitysympäristöjä, mikä puolestaan näkyy parempana kykynä sopeutua muutoksiin.
Skaalautuvuus on myös yksi perinteinen tietojärjestelmien haaste – kasvua on vaikea ennustaa tarkasti, ja perinteisen IT-salin laajentaminen kasvaneeseen tarpeeseen vie paljon aikaa ja resursseja. Pilveen siirretyn infrastruktuurin yksi isoimmista eduista onkin sen skaalautuvuudessa.
Palveluita ja infrastruktuureja voidaan pystyttää virtuaalisesti AWS:n oman, massiivisen infrastruktuurin päälle.
Lambda-funktiot ovat automaattisesti skaalautuvia: jokainen tapahtuma käynnistää oman ajonsa Lambda-funktiosta.
S3 tarjoaa rajattomasti tallennustilaa mille tahansa objektidatalle.
SQS-jonot voivat varastoida rajattoman määrän viestejä, ja yhtäaikaisesti viestejä voidaan käsitellä jonotyypistä riippuen 20 000:sta aina 120 000:een viestiin.
Liiketoiminnan kasvusta ei tarvitse siis murehtia – järjestelmä kasvaa sen mukana.
2. Luotettavaa vakautta
AWS:n infrastruktuuri tukee helpon skaalautuvuuden lisäksi myös vikasietoisuutta sekä kansainvälistämistä. AWS on hajauttanut infrastruktuurinsa maantieteellisesti useisiin eri alueisiin eli Regioneihin, jotka taasen on jaettu useisiin eri Availability Zoneihin, jotka ovat erillisiä datakeskuksia (tai datakeskusryppäitä) alueiden sisällä. Availability Zonet on myöskin eristetty toisistaan siten, että yhden AZ:n kaatuminen ei kaada koko Regionia tai muita Availability Zoneja. Jotkin palvelut myös mahdollistavat tietojen toisintamisen toiseen Availability Zoneen tai Regioniin, parantaen sovellusten toiminnan ja datan varmuutta.
AWS:n infrastruktuuria löytyy ympäri maailmaa, mikä mahdollistaa järjestelmien rakentamisen ja/tai tarjoamisen siellä, missä asiakkaat ovat. Regionien ja Availability Zonejen lisäksi on olemassa niin kutsuttuja Edge-sijainteja, joita löytyy myös paljon ympäri maailmaa. Ne on sijoitettu monesti suuriin kaupunkeihin lähelle käyttäjiä, ja Edge-sijainteja hyödyntävät vain tietyt AWS:n palvelut, tärkeimpänä CloudFront, joka on AWS:n oma CDN- eli sisällönjakeluverkkopalvelu.
CloudFront voi käyttää Edge-sijainteja cachena eli välimuistina; CloudFront voi esimerkiksi tallentaa usein haettuja tiedostoja näihin Edge-sijainteihin ja jakaa niitä sieltä sen sijaan, että se haettaisiin varsinaisesta lähteestä syvemmältä AWS:n infrastruktuurista. Tämä voi nopeuttaa esimerkiksi verkkosivujen lataamista, mikäli sivujen staattiset resurssit, kuten esimerkiksi kuvat, HTML-templaatit ja CSS-tyylitiedostot, haetaan lähellä sijaitsevan Edge-sijainnin välimuistista.
3. Turvallisuus ennen kaikkea
Nopeus ja vakaus ovat toki tärkeitä järjestelmän käytettävyyden ja sitä myöten sen haluttavuuden kannalta, mutta yksi tärkeimmistä asioista yleisesti tietojärjestelmissä on kuitenkin tietoturva. Tämän toteamuksen kanssa on helppo olla samaa mieltä. Valitettavasti tietoturva kuitenkin monesti joko laahaa perässä tai se laiminlyödään täysin, niin isoissa kuin pienissäkin organisaatioissa.
AWS-maailmassa tietoturva jaetaan kahteen leiriin: pilven tietoturvaan sekä pilven sisäiseen tietoturvaan. Pilven tietoturva tarkoittaa AWS:n ylläpitämän pilvi-infrastruktuurin tietoturvaa: AWS pitää huolen siitä, että sen pilvipalvelut mahdollistava infrastruktuuri on ajan tasalla, mitä tulee tietoturvauhkiin. Datakeskukset noudattavat tiukkoja turvallisuusprotokollia ja palveluiden tarjoamiseen tarvittavat ohjelmistot pidetään ajan tasalla.
Pilven tietoturva koskee siis AWS:n omia resursseja, joita sen pitää ylläpitää ja valvoa tarjotakseen asiakkailleen palveluitaan. Pilven sisäinen tietoturva on taasen AWS:n asiakkaan vastuu, ja se kattaa kaiken sen, mitä AWS:n palveluilla tehdään ja mitä AWS:n pilveen tallennetaan. Palvelut pitää konfiguroida oikein, käyttäjätunnusten tai salaisuuksien on oltava turvallisia ja oikein säilöttyjä, pilveen itse asennetut ohjelmat tai ohjelmistot täytyy pitää ajan tasalla ja ohjelmistokehitysprojekteissa täytyy itse huolehtia rakennettavan ohjelmiston tietoturvasta.
Me huolehdimme integraatioalustamme turvallisuudesta ja toimivuudesta noudattamalla hyviä, tietoturvallisia käytäntöjä rakentaessamme ja ylläpitäessämme sitä. Käytämme monia
AWS:n tarjoamia palveluita ja ominaisuuksia muun muassa salaisuuksien turvalliseen säilömiseen ja käyttämiseen, tietojen kryptaamiseen ja resurssien monitorointiin. Tämä helpottaa omaa työtämme alustan turvaamisessa ja valvomisessa sekä pienentää asiakkaan taakkaa tietoturvallisuudesta huolehtimisesta.
4. Vaan millä hinnalla?
Todellisuus on valitettavasti se, että kauniit ajatukset kantavat vain niin pitkälle kuin budjetti sen sallii. Taloudellisten realiteettien raamit rajaavat liiketoiminnan rakentamisen ja ylläpitämisen mahdollisuuksia, joten kustannustehokkuus on aina ajankohtainen kysymys järjestelmien suunnittelussa.
AWS:n hinnoittelumallit tarjoavat onneksi joustavuutta tilanteen mukaan. Ehkä yleisin AWS:n hinnoittelumalli on käytön mukaan menevä laskutus – palveluista maksetaan tietty taksa sen mukaan, kuinka paljon kyseistä palvelua on käytetty. Esimerkiksi Lambda-palvelussa maksetaan funktion suoritusajasta millisekunneissa sekä kutsujen määrästä. Lisäksi hintaan vaikuttavat Lambda-funktiolle annetun muistin määrä, prosessoriarkkitehtuuri sekä Region, jossa palvelua käytetään.
AWS:llä on myös ns. Free Tier -tarjonta, joka antaa tietyn määrän ilmaiskäyttöä joihinkin palveluihin. Jotkin Free Tier -tarjoukset ovat voimassa vain 12 kuukautta AWS-tilin luomisen jälkeen, mutta osa tarjouksista on voimassa aina. Esimerkiksi Lambda-palvelussa jokaisen kuukauden ensimmäiset miljoona kutsua ja 400 000 gigatavusekuntia ajoaikaa ovat aina ilmaisia. Lisäksi DynamoDB tarjoaa aina mm. 25 gigatavua ilmaista tallennustilaa ja SQS ilmaiset miljoona kutsua joka kuukausi.
AWS:n nk. ”pay-as-you-go”-hinnoittelumalli sekä Free Tier -tarjoukset tarjoavat edullisen lähtökohdan alkuun pääsemiselle. Kehitystyön alkuvaiheen AWS-kustannukset voivat hyvinkin olla lähellä nollaa. Liiketoiminnan ja asiakasmäärän kasvaessa alkavat laskujenkin summat toki nousta, mutta tätäkin tilannetta varten löytyy ratkaisuja: Savings Planit sekä Reserved Instancet.
Savings Planit ja Reserved Instancet toimivat molemmat samantyylisellä logiikalla: asiakas sitoutuu tiettyyn määrään käyttöä yhden tai kolmen vuoden ajaksi. Savings Planeissa sitoudutaan tiettyyn määrään resurssien käyttöä, joka mitataan dollareina tunnissa, ja Reserved Instanceissa varataan tietyn tyyppinen EC2-instanssi sopimuksen ajaksi. Vastineeksi asiakas saa käyttää sinä aikana sopimukseen kuuluvia resursseja huomattavasti halvemmalla hinnalla – parhaimmillaan n. 60–70 prosenttia halvemmalla.
Nämä kaikki AWS:n eri hinnoittelumallit mahdollistavat aloittamisen pienestä ja auttavat tarpeen tullen säästämään käytön kasvaessa paljon isommaksi. AWS:n joustavuus ei liity siis pelkästään palveluihin vaan myös kustannuksiin, joten oli tilanteesi mikä tahansa, sopeutuvat järjestelmän lisäksi myös kustannukset liiketoimintasi muutoksiin.
Summa summarum
Modernit integraatiot kaipaavat tiettyjä ominaisuuksia: ketteryyttä, joustavuutta, reaktiivisuutta, vikasietoisuutta, kansainvälisyyttä, kustannustehokkuutta ja tietoturvallisuutta. AWS-maailmassa nämä ovat helppoja ongelmia ratkottaviksi.
Monet palvelut ovat heti helposti skaalautuvia, kuten Lambda ja SQS, joita alusta hyödyntää integraatio-operaatioiden tekemiseen ja tiedonvälitykseen. DevOps- ja infrastruktuuri koodina -palvelut, kuten CodeCommit, CodeBuild, CodePipeline ja CloudFormation, mahdollistavat ketterän kehittämisen sekä resurssien pystyttämisen niin eri ympäristöihin kuin eri maantieteellisiin alueisiinkin nopeasti ja toistettavasti.
EventBridge sekä monet AWS:n palveluiden tapahtumat ja/tai niitä välittävät ominaisuudet tai palvelut (esimerkiksi DynamoDB Streams) mahdollistavat reaktiivisten toimintaketjujen rakentamisen, jolloin tapahtumiin voidaan reagoida heti, kun ne tapahtuvat.
Integraatiotapaukset, joissa nopea reagointi on tärkeää, ovat aivan yhtä mahdollisia kuin isommat massa-ajot tai hybdritoteutukset, joissa esim. SQS-jonoa käydään läpi lyhyin väliajoin.
SQS-jonot ovat myös osa vikasietoisuutta ja vikatilanteiden hallintaa. SQS-jonoissa liikkuvat viestit voidaan siirtää niin kutsuttuihin dead letter -jonoihin, mikäli niitä on yritetty prosessoida liian monta kertaa. Tämä raja on itse määriteltävissä. AWS:n fyysinen infrastruktuuri on rakennettu kestämään vikatilanteita palvelinraudassa ja datakeskuksissa, joten keskittyminen voidaan kohdistaa virheiden käsittelyyn lähdekoodissa ja AWS:n palveluissa.
AWS-kumppanina ja AWS:n ekosysteemiin keskittyvänä toimijana olemme etsineet parhaita palveluja ja tapoja kaikkien eri ominaisuuksien kunnolliseen toteuttamiseen integraatioalustallemme.
Tutustu integraatioalusta palvelukokonaisuuteemme täältä: Integraatioalustat - AWS Integration Platform
Ota yhteyttä asiantuntijoihimme ja kysy lisää!
Vastaamme mielellämme kysymyksiisi.
Harri Ilvonen
harri.ilvonen@skillwell.fi
+358 400 830 660
Jari Ikävalko
jari.ikavalko@skillwell.fi
+358 50 386 5590