APIt eli ohjelmointirajapinnat ovat yleisiä monissa arkisissa palveluissa. Kuluttajapalveluiden lisäksi APIt ovat monen yrityksen palveluiden tai arkkitehtuurin päärooleissa.
APIt mahdollistavat uudenlaisia palveluita, tapoja tehdä työtä ja ketteriä kehittämisen toimintamalleja – jopa täysin uusia tulonlähteitä. Oikeuksiinsa ne pääsevät mikropalveluarkkitehtuurissa. Lue siis lisää, miksi ja miten sinunkin kannattaisi hyödyntää ohjelmointirajapintoja saadaksesi arkkitehtuurista kehittyvän ja helpommin hallittavan kokonaisuuden.
Mikropalveluarkkitehtuurissa palvelut ja hallinta on pilkottu pieniksi
Niin mikä mikropalveluarkkitehtuuri? Mikropalveluarkkitehtuuri on ohjelmiston suunnittelussa käytetty arkkitehtuurimalli, jossa sovelluskokonaisuus on hajautettu ja jaettu itsenäisiksi prosesseiksi, usein eri palvelimille tai pilvipalveluun.
Toisinaan käytetään myös termiä minipalveluarkkitehtuuri. Tarkan määritelmän mukaan mikropalvelu on yhden toiminnon toteuttava kokonaisuus, jolla ei ole ulkoisia riippuvuuksia tai resursseja, vaan se käyttää ainoastaan omia sisäisiä ratkaisujaan. Se on yksittäinen, itsenäinen palvelukokonaisuutensa. Minipalvelu ei ole täysin eristetty, yksi palvelu, vaan sen kanssa voidaan hyödyntää jaettavia tietovarantoja ja palvelukokonaisuuksia.
Mikropalveluilla ketteryyttä – eli mitä?
Mikropalveluarkkitehtuurista puhutaan nyt paljon, koska se avulla voidaan kehittää parempia palveluita ja ketteröittää toimintaa.
APIen ja mikropalveluarkkitehtuurien kohdalla trendisana ketteryys tarkoittaa esimerkiksi:
- Palveluita tai niiden uusia versioita voidaan ottaa käyttöön nopeammin, kun esimerkiksi päivitykset eivät aiheuta automaattisesti massiivisia käyttökatkoja.
- Maailman ja teknologian muutoksiin on nopeampi reagoida.
- Toimimattomaksi osoittautuneita palveluita voidaan korvata uusilla ja paremmilla ilman, että kokonaisuus menee uusiksi.
Toisin sanoen ketterää toimintaa organisaation useille eri tasoille ja toiminnoille.
Muitakin iloja mikropalveluarkkitehtuurista tietenkin saa: esimerkiksi toimittajayhteistyö yksinkertaistuu, ja tiiviimmän yhteistyön myötä kehitys ja operointi tuottavat laadukkaampia palveluita.
Siirry vaiheittain mikropalveluarkkitehtuuriin
Kun monoliittisesta arkkitehtuurista siirrytään mikropalveluihin, tulee vastaan eräs tosiasia: monoliitit voivat olla hyvinkin suuria ja raskaita. Kokonaisuuden korvaaminen yhdellä rysäyksellä ei yleensä ole mahdollista eikä järkevää.
APIen avulla myös hyvinkin suurista monoliiteistä voidaan siirtyä mikropalveluarkkitehtuuriin. Strangler pattern kuvaa vaiheittaista siirtymää, jossa monoliitin yksittäisiä toimintoja korvataan uusilla mikropalveluilla, vähän kerrallaan. Esimerkiksi Patentti- ja rekisterihallituksen patenttihakemusten käsittelyjärjestelmän uudistus on monivuotinen hanke, jossa vanhaa ja uutta järjestelmään käytetään edelleen rinnakkain. Alfame on toteuttanut vanhan monoliittisen järjestelmän päälle API:n, jonka kautta hakemuksia voidaan reaaliaikaisesti migroida uuden järjestelmän välillä.
Vaiheittaisen siirtymän tavoitteena on lopulta luopua monoliitista kokonaan, mutta kehitys ei tietenkään pääty siihen: arkkitehtuurin, palveluiden ja APIen evoluutio jatkuu. Fiksu ei jumahda tietojärjestelmien tai arkkitehtuurin kehittämiseen, vaan tarttuu myös kehittäjäkokemuksen parantamiseen.
Haluatko kuulla lisää parhaita käytänteitä APIen rakentamiseen?
Heräsikö tiedonjano? Olemme koonneet näppärään oppaaseen asiantuntijoidemme parhaat opit mikropalveluarkkitehtuurin hyödyntämisestä ja esimerkiksi APIen kehittäjäkokemuksesta. Oppaan vinkeillä saat hyvät eväät ohjelmointirajapintojen helpompaan ja parempaan hallintaan ja kehittämiseen.
Lataa API-opas IT-päättäjille täältä!
