Onko ESB todella kuollut? Ei vielä...

Ansaitseeko ESB todella kaiken saamansa kritiikin? Tero Niemistö päätti esittää puolustuspuheenvuoron.

Kesäkuun Tietoviikon numerossa – ja myöhemmin elokuun lopussa verkossa - julkaistiin artikkeli ”Esb on kuollut – eläköön uusi esb!”. Artikkelissa oli haastateltu Futuricen silloista teknologiajohtajaa Ville-Matti Toivosta ja Solitan pilvi- ja integraatiopalveluista vastaavaa johtajaa Karri Lehtistä. Artikkelissa arvosteltiin Enterprise Service Bus (ESB) -ratkaisuja vanhanaikaisiksi ja nostetiin mikropalveluarkkitehtuurit jalustalle ”uudeksi moderniksi ESB-ratkaisuksi”.

Mielestäni artikkelissa asiantuntijoiden esittämä kritiikki perinteisiä ESB-ratkaisuja kohtaan oli hyvin pitkälti kohtuutonta. Kyseinen artikkeli ei ole vuoden sisään ensimmäinen [1] [2], jossa ESB:tä arvostellaan voimakkaasti. Olen kuitenkin lähivuosien varrella nähnyt myös paljon erittäin onnistuneita ESB-käyttöönottoja ja palveluratkaisuja, joten tässä blogissa pyrin korjaamaan tiettyjä ESB:tä kohtaan esitettyjä kriittisiä näkökantoja.

Parhaiden käytäntöjen noudattaminen minimoi tuskaa

Adjektiiveja, joilla ESB:tä on linkittämissäni artikkeleissa kuvailtu ovat mm. raskas, hidas, ei-skaalautuva, vikasiedoton, epästabiili, pullonkaula, ei-siirrettävä, jne. Tosiasia on, että kaikki nuo samat adjektiivit saadaan sovitettua myös mikropalveluarkkitehtuurilla toteutettuun ratkaisuun, mikäli niiden toteutuksessa ei noudateta arkkitehtuurimallin parhaita käytänteitä.

Jokaisessa arkkitehtuurimallissa on kokemuksien kautta syntyneet parhaat käytänteet, myös ESB:lle toteutettavissa integraatiossa. Epäonnistuneissa ESB-ratkaisuissa suurin osa ongelmista on yleensä johtunut nimenomaan täysin muista asioista kuin teknologiasta. Sen sijaan syy on ollut esimerkiksi osaamattomuudessa hyödyntää arkkitehtuurimallia, huonossa prosessissa, olemattomassa hallintamallissa ja mitä ohjelmoijat kutsuvat puutteellisiksi koodauskäytännöiksi. Itse näen vahvasti, että hyvin harvoin IT-järjestelmien ongelmat johtuvat yksinään huonosta teknologiasta. Useimmiten syynä on valitun arkkitehtuurimallin huono implementointi.

Todellisuudessa ESB ei teknologiana ole ollenkaan niin huono, kunhan seuraa kunkin ratkaisun parhaita käytäntöjä. Olkoon arkkitehtuurimalli mikä tahansa, sen kanssa ollaan takuuvarmasti ongelmissa, jos:

• Automaatiotestaus puuttuu
• Automatisoitu Continuous Integration/Delivery putki puuttuu
• Järjestelmän MTTR (Mean Time To Recover) lasketaan tunneissa minuuttien sijaan
• Yhteisesti sovitut toteutuskäytännöt puuttuvat

Kaikki ylläolevat voidaan siis toteuttaa myös ESB-arkkitehtuurissa.

Kuusi väitettä ESB:stä

Ohessa muutamia yleisimpiä kriittisiä väitteitä:

1. ESB on raskas ja vaatii paljon konfigurointia

Tässä kyse on pitkälti siitä, kuinka pitkälle DevOps-toimintamalli ja Continuous Integration/Delivery-putket on viety. Mikäli niitä ei ole, on ESB takuuvarmasti raskas ja hankala konfiguroida. Tosin niin on mikropalveluarkkitehtuurikin, ellei samoja DevOps-ominaisuuksia ole implementoitu.

2. ESB:t ovat tekniikoilta vanhanaikaisia, eivätkä tue palveluiden siirtoa uusille alustoille

Uusimmat ESB ratkaisut on saatavissa Docker-konteissa ja ovat silloin siirrettävissä mille tahansa alustalle, myös pilveen.

3. ESB:n käyttöönotto on raskas urakka

Niin on mikropalveluidenkin, jos päätetään kerralla toteuttaa kaikkien järjestelmien väliset integraatiot kyseisellä arkkitehtuurilla. Esim. Mulesoftin perustaja Ross Mason suosittaa, että ESB otettaisiin käyttöön pienin askelin, jotta varmistetaan arkkitehtuurin toimivuus:

”Do you have more than 10 applications to integrate? Avoid big-bang projects and consider breaking the project down into smaller parts. Pilot your architecture on just 3 or 4 systems first and iron out any wrinkles before impacting other systems.”

4. ESB on epästabiili ja suorituskyvyltään heikko

Niin on mikropalvelualustakin, jos se toteutetaan huolimattomasti ja osaamattomasti. Useassa suuressa suomalaisessa organisaatiossa ovat ESB:t olleet toiminnassa ilman katkoksia vuosikausia ilman vasteaikaongelmia.

5. ESB ei ole vikasietoinen ja on altis esim. ulkoiselle DoS-hyökkäykselle

Jos DoS-hyökkäys kaataa ESB:n, kyse on taas enemmän osaamattomuudesta ja huonosta toteutuksesta kuin teknologiasta. ESB-ratkaisuissa on sisäänrakennettuna estot normaaleja DoS-hyökkäyksiä varten. Sen lisäksi oikein rakennetussa arkkitehtuurissa mikään julkisesta internetistä tullut kutsu ei kulje suoraan ESB-väylään, vaan ohjataan sinne jonkun liikennettä tasaavan kuormantasaajan/proxyn kautta.

Itse väittäisin, että mikropalveluarkkitehtuuri on jopa riskialtiimpi ulkopuoliselle hyökkäykselle. Siinä missä ESB-ratkaisuissa on sisäänrakennetut komponentit tietoturvalle, kredentiaaleille ja salasanojen turvalliselle säilyttämiselle, nämä joudutaan toteuttamaan erikseen jokaiselle mikropalvelulle.

Jos yhdestäkään mikropalvelusta löytyy aukko, vaarantaa se potentiaalisesti koko arkkitehtuurin. Esimerkiksi jos yhdelle mikropalvelulle ei ole asetettu muisti- tai prosessirajoitteita, voi hyökkääjä mikropalvelun avulla monopolisoida palveluita pyörittävän alustan resurssit kokonaan näännyttäen, ja kaataen, kaikki alustalla olevat muut mikropalvelut.

6. REST vs SOAP

Tämä vastakkainasettelu ESB vs Mikropalvelut -keskustelussa on jo lähtökohtaisesti jotenkin kummallinen, koska molemmat arkkitehtuurimallit tukevat sujuvasti molempia sanomia. On tosin totta, että ESB:lle toteutetuissa rajapinnoissa suurin osa on yleensä SOAP-protokollalla toteutettuja, kun taas mikropalvelutoteutuksissa lähes kaikki rajapinnat ovat REST:iä.

On totta, että 90%, ehkä 95%, tapauksissa REST on SOAP:ia parempi vaihtoehto. On kuitenkin tärkeä ymmärtää, että REST ei ole – kuten ohjelmistoalalla ei yleensäkään ole mikään – vastaus kaikkeen. SOAP – vaikka onkin raskaampi ja vaikeampi – sisältää ominaisuuksia, joita vaan ei voi toteuttaa REST:in avulla. Näistä oleellisin on lähetyksen luotettavuus (muita ovat mm. korotettu tietoturva, transaktioiden luotettavuus sekä sisällön luotettavuus sopimuksen kautta).

Kuvitellaanpa tilanne, jossa suoritetaan tilisiirto REST:in ja SOAP:in avulla ja molemmissa tapauksissa viesti menee onnistuneesti perille, mutta vastausviesti eli kuittaus jää matkalle. REST-tekniikalla toteutettu ratkaisu tulkitsee lähetyksen epäonnistuneeksi ja lähettää sen uudestaan aiheuttaen täten potentiaalisesti rahojen siirtymiseen kahteen kertaan. SOAP-protokollalla tämä tilanne havaitaan ja varsinaista transaktiota vastaanottavassa järjestelmässä ei tapahdu.

ESB vai mikropalvelut – molempi parempi?

Oleellinen kysymys ei mielestäni olekaan ESB vai mikropalvelut. Molemmat ovat toimivia arkkitehtuurimalleja. Kummassakin mallissa on omat vahvuudet ja heikkoudet. En lähde tässä blogissa käymään läpi mikropalveluarkkitehtuurin vahvuuksia. Sitä varten kehotan tutustumaan esimerkiksi IT-alan gurun Martin Fowlerin erinomaisiin bloggauksiin aiheesta.

Oikeampi kysymys on: Minkä ongelman ne ratkaisevat paremmin kuin toinen? Mihin mikropalveluarkkitehtuuri sopii ja mihin ESB? Mielestäni Martin Fowler on oikeassa sanoessaan blogissaan seuraavaa:

”The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.”

Mikropalveluarkkitehtuuri on loistava valinta arkkitehtuurimalliksi, kun ollaan tekemässä tuotetta tai alustaa. Jos taas organisaatio on valitsemassa itselleen integraatioratkaisua, jossa:

• ollaan integroimassa 3 tai useampaa tuotetta toisiinsa
• kommunikoidaan useammalla eri protokollalla

on ESB:n valinta perusteltua. Mikropalveluarkkitehtuuri ja ESB eivät siis ole toisiaan poissulkevia vaan itse asiassa toisiaan täydentäviä, jotka voivat elää samassa ekosysteemissä keskenään sulassa sovussa.

Lopuksi vielä huomio: Fullers ESB on valittu kahdesti maailman parhaaksi, joten ei ESB niin kovin huono voi olla ;)