Jarkko Enden, Partner, Head of Technology at Nortal, February 5, 2020
Monoliittien aikakausi on jäämässä taakse ja yritykset uudistavat arkkitehtuuriaan heterogeenisemmaksi. Heterogeeninen moderneihin teknologioihin perustuva kokonaisarkkitehtuuri ja ekosysteemilähestyminen tuovat selkeitä etuja liiketoiminnalle, mutta ne myös lisäävät arkkitehtuurin monimutkaisuutta. Ilman selkeää visiota tai kunnon työkaluja uudistus voi jäädä torsoksi tai pahimmillaan johtaa aiempaa hankalammin ratkaistaviin ongelmiin.
Jotta uudistamisella tavoiteltavat bisneshyödyt saavutetaan ja onnistutaan viemään hanke läpi sujuvasti, on hyvä noudattaa ainakin seuraavia periaatteita:
Vaikka mikropalvelut ovat päivän sana, kaikkea ei kannata rakentaa tyhjästä. Hallinnoi tuotevalintoja keskitetysti, suosi tuotteita, jotka tarjoavat korkealaatuiset rajapinnat ja vältä tuotteiden räätälöintiä. Älä myöskään julkaise tuotteiden natiivirajapintoja suoraan koko ekosysteemille. Näin tuotteista saadaan kaikki irti mahdollistaen samalla niiden saumaton päivittäminen ja vaihtaminen.
Mallinna liiketoiminnan logiikka Domain-Driven Design -periaatteiden mukaisesti. Keskity ydintoimintoihin ja niiden logiikkaan. Määritä myös toiminnalliset alueet ja niiden käsitteet sekä riippuvuudet. Jatkuva yhteistyö ja viestintä teknisten ja liiketoiminnan asiantuntijoiden välillä on myös olennaisen tärkeää.
Merkittävä osa mallinnuksen lopputulosta on domain API -kerros, joka tarjoaa liiketoiminnan tarvitsemat palvelut yhtenäisellä käsitteistöllä piilottaen samalla alla olevien tuotteiden monimutkaisuuden ja geneerisyyden.
Mikropalvelut ja API:t ovat nykyaikainen tapa rakentaa sovelluksia ja integraatioarkkitehtuuria. Martin Fowler on kiteyttänyt tämän ajatuksen muotoon “Smart endpoints and dumb pipes”, mikä tarkoittaa liiketoimintalogiikan keskittämistä erillisiin (mikro-)palveluihin massiivisen monoliittisen järjestelmän tai perinteisen ESB-ratkaisun sijaan.
Suosi siis kevyttä API-hallintaratkaisua, pidä mikropalvelujen määrä kohtuullisena ja laajenna ekosysteemin sisältämien tuotteiden kykyjä niiden avulla. Käytä moderneja API-teknologioita, kuten REST, WebSocket, gRPC ja MQTT, ja tuota yhtenäiset periaatteet API-suunnittelulle.
Liiketoiminnan mallinnuksen tuloksena syntyvä Domain API -kerros koostuu mikropalveluista, jotka sisältävät pääosan liiketoimintalogiikasta ja tarjoavat yhdenmukaisen käyttökokemuksen API-kerrosta hyödyntäville ekosysteemin osille (API design, virhekäsittely, auktorisointi). Samalla riippuvuus alempana oleviin tuotteisiin pienenee ja legacy-järjestelmiä pystytään kuristamaan asteittain ns. Strangler Patternia käyttäen.
Kuva: Domain API -kerroksen sisältävä API-arkkitehtuuri. Experience API -kerros hyödyntää Domain API -kerrosta ja tarjoaa optimoidut taustapalvelut ja API:t käyttöliittymille – ja tietyissä tapauksissa muille sovelluksille.
Älä pelkää pilveä vaan ota siitä kaikki hyödyt irti. Suurimpien toimijoiden pilvialustoja käyttämällä tavoitat skaalautuvuuden, joustavuuden, tuottavuuden sekä stabiliteetin edut. Näillä alustoilla on myös huomattavasti korkeampi kyky torjua kyberhyökkäyksiä.
Käyttämällä pelkästään IaaS-ratkaisuja saavutat vain rajalliset hyödyt, joten alustakumppanin tarjoamat PaaS-ratkaisut ovat oleellinen osa kokonaisratkaisua. Abstraktiotason nostaminen PaaS-palveluihin, kontteihin (Docker, Kubernetes) ja serverless-ratkaisuihin vapauttaa kehitystiimit ja IT-tuen keskittymään tulevaisuuden rakentamiseen palvelinten ylläpitämisen sijaan.
Mikropalveluita on käytännössä mahdoton hallita ilman korkealaatuista DevOpsia ja korkeaa automaatiotasoa, ja siksi mikropalvelut ja DevOps kulkevat käsi kädessä. Rakenna DevOps-putket huolellisesti ja luo uudelleenkäytettäviä malleja, joita voi hyödyntää useissa mikropalveluissa. On hyvä olla tietoinen myös siitä, että testiautomaation ja tietoturvatestauksen eli DevSecOpsin sisällyttäminen DevOpsiin tuo huomattavia etuja elinkaarikustannuksissa, vaikka niiden toteuttaminen saattaakin alkuvaiheessa hieman nostaa kuluja.
Lisäksi ympäristöjen hallinta kannattaa rakentaa saman tien IaC-ratkaisuilla (Infrastructure-as-Code) ja skriptata sovellusympäristöjen lisäksi myös muiden palveluiden pystyttäminen eli API management, verkkoratkaisut ja muut keskitetyt resurssit. Tämän jälkeen backup-ratkaisut täytyy rakentaa vain datalle, koska ympäristöt ja niiden konfiguraatiot ovat tallessa versionhallinnassa.
Pilvisiirtymä on käynnissä, mutta osa palveluista tulee säilymään vielä pitkään paikallisissa konesaleissa. Ota tämä huomioon ja rakenna kunnollinen hybridipilviratkaisu sen sijaan, että puhkoisit pilven ja on-premisen välille reikiä yksittäisissä projekteissa. Johtavat pilvialustat sisältävät kehittyneitä työkaluja ja ratkaisuja hybridipilven rakentamiseen.