Hallitsetko API:si?

API-hallinta on oleellinen osa integraatioita. Tero Kivisaari kertoo blogisarjansa toisessa osassa, milloin API-hallintaa tarvitaan, mitä tulee ottaa huomioon ratkaisun valinnassa ja millaisia tuotteita API-hallintaan on markkinoilla.

Tämä on toinen osa blogisarjassa, jossa käsitellään API-rajapintoja, API-hallintaa (API Management) ja API:en päälle rakentuvaa liiketoimintaa. Ensimmäisessä osassa käytiin läpi peruskäsitteitä ja selvennettiin, mitä REST API:t konkreettisesti ovat ja miksi asia on ajankohtainen. Tässä toisessa osassa keskitytään API-hallinnan perusteisiin aloittaen käsitteistä ja tyypillisestä arkkitehtuurista. Mitä API-hallinta on ja mitä se ei ole, milloin API-hallinnalle on tarvetta ja mitä sillä voi saavuttaa.

Peruskäsitteet haltuun

Selvennetään ensin, mistä koko asiassa on kyse. Lyhykäisyydessään API-hallinnassa on kyse API-rajapintojen systemaattisesta hallinnasta. Systemaattinen hallinta viittaa esimerkiksi seuraaviin kyvykkyyksiin: API-julkaisujen tekeminen ja API:en elinkaaren hallinta, API-dokumentaation automaattinen tuottaminen ja palvelurekisterin/portaalin ylläpito, yhteisten tietoturvapolitiikoiden hallinnointi ja hyödyntäminen, teknisen käyttäjärekisterin ylläpito (mikä client-sovellus on rekisteröitynyt minkäkin API:n käyttäjäksi), monetisaatio ja yhteismitallinen statistiikka ja analytiikka muutamia mainitakseni.

Näiden tärkeiden kyvykkyyksien lisäksi täytyy mainita seuraava puolittainen itsestäänselvyys: API-hallinta vaatii työtä ja kustannuksia. Jotta tämä olisi järkevää ja kannattavaa, täytyy hallinnoitavia API-rajapintoja (tai rajapintoja kutsuvia sovelluksia) olla vähintään kohtuullinen määrä, eli ainakin kymmeniä. Kohtuullinen määrä on tietysti yksilöllistä eikä sen suhteen kannata rajoittua nykyhetkeen, vaan miettiä, että mihin suuntaan yrityksen liiketoiminta ja integraatioarkkitehtuuri ovat kehittymässä.

API-hallinnan pääkomponentit

API-hallinnalle ei ole olemassa mitään vakiintunutta määritystä tai sen paremmin standardeja. Yleensä API-hallintajärjestelmät koostuvat kolmesta pääkomponentista, kutsutaan niitä nyt vaikka nimillä API-manager, API-gateway ja API-portal.

API-manager on keskeinen hallinnointiin käytetty järjestelmä. Sen avulla kuvataan yleensä Swagger 2.0 / OpenAPI -kuvauskielellä, mitä API-rajapintoja järjestelmällä hallitaan. Mitä fyysistä verkko-osoitetta ne kuuntelevat ja mitä backend-järjestelmää API:t kutsuvat. API-managerilla määritellään myös mahdolliset tietoturvapolitiikat, joita API:t noudattavat sekä muita yleisiä sääntöjä (esim. mihin kirjoitetaan lokit, mahdolliset transformaatiot, sanomien rikastaminen tai filtteröinti jne).

API-manager ei ole sovelluspalvelin, joka ajaisi operatiivisia API-palveluita. Se on hallintaväline, jolla kuvataan säännöt, jotka jossain muualla suoritetaan. API-manager sisältää yleensä myös jonkinlaisia analytiikkatoiminnallisuuksia, tosin ratkaisusta riippuen analytiikka saattaa myös olla kokonaan erillisessä järjestelmässä.

API-gateway on se varsinainen API-palvelin, jossa API-managerilla kuvatut ja julkaistut API:t sääntöineen ovat suoritettavana. “Suoritettavana” on ehkä vähän väärä sana, ennemminkin niin, että API-gateway tarjoaa ohuen proxy-kerroksen, jossa suoritetaan API-hallintaan liittyvät tehtävät ja kutsutaan varsinaista API-toteutusta.

API-gateway -ajattelun osalta on myös tiettyä variaatiota. Gateway-tyyppisen keskitetyn ratkaisun vastakohtana ovat myös agentti-perustaiset järjestelmät, joissa ei ole keskitettyä väylää, vaan jokaisen API-implementaation yhteyteen asennetaan agentti, joka hakee säännöstöt ja tietoturvapolitiikat keskitetyltä API-managerilta ja välittää sinne analytiikkatietoja takaisin. API-gatewaytä pidetään myös tietyllä tavalla kokonaisen API-hallintajärjestelmän kevytversiona, jossa voidaan toteuttaa lähinnä pääsynhallintaa ja yksinkertaisten sääntöjen ajamista yrityksen verkon reunalla (esim. Amazon API gateway). Viimeaikojen trendeihin kuuluvat kevyet Node.js-pohjaiset microgatewayt, jotka soveltuvat paremmin yrityksen sisäverkossa kuin DMZ-vyöhykkeellä käytettäväksi.

API-portaali on arkkitehtuurin kolmas komponentti, jolla on hyvin erityyppinen tehtävä edellisiin verrattuna. API-portaaliin kerätään automatisoidusti dokumentaatio julkaistuista rajapinnoista. Lisäksi portaalin avulla voi mahdollisesti rekisteröityä API:n kuluttajaksi tai vaikkapa testata julkaistua API-rajapintaa suoraan selaimesta. Kehittäjäportaaleista on paljon esimerkkejä ja ne vaihtelevat erittäin hienoista todella yksinkertaisiin (esim. Amazon developer, Twitter Developers, OneDrive API 2.0, Google APIs).

Pilveen vai omaan konesaliin?

Luultavasti lähes kaikkien yritysten osalta (noh, paitsi ehkä uusimpien ns. “pilvinatiivien”) alkaa olla ajankohtaista puhua hybrid ja pilvi -integraatioista. Osaa yrityksen järjestelmistä pyörii omissa datakeskuksissa ja osa erilaisissa pilviratkaisuissa, kuten AWS, Azure ja Google Cloud.

Miten sitten API-hallinta pitäisi sijoittaa hybridi-topologiaan, kun tarpeita on sekä on-premises-järjestelmillä että pilvisovelluksilla? Tähänkään ei ole yhtä oikeaa vastausta, ennemminkin vaihtoehtojen paljous.

Luultavasti jokaisen datakeskuksen (lokaali tai pilvi) verkon reunalle on syytä asentaa API-gateway, jonka kautta liikennettä pystytään hallinnoimaan. Se, missä sijaitsee API-manager -palvelin, jolla API-gatewaytä ja API-portaalia hallinnoidaan, onkin toinen kysymys. API-managerin voi asentaa omaan datakeskukseen, josta se hallinnoi useita API-gateway-palvelimia, tai yhtä hyvin se voi olla pilvessä ja hallinnoida sieltä myös paikallisen datakeskuksen API-gatewaytä. Kolmas vaihtoehto on olla asentamatta mitään ja valita iPaaS (integration Platform as a Service) -tyyppinen ratkaisu, jossa API-manager-palvelun voi provisioida pilvestä ja sillä voi hallinnoida useita gateway-palvelimia.

Markkinatilanne ja tuotteet

Jokainen itseään kunnioittava globaali integraatiotalo on putkauttanut API-hallintatuotteen markkinoille. IBM API Connect, Apigee, Oracle API Management, Microsoft Azure API Management, CA API Management, Mulesoft ja niin edelleen, muutamia mainitakseni. Vaihtoehtoja on myös avoimen lähdekoodin puolella (WSO2, Kong). API-hallintatuotteen valinta olisikin aiheena varmasti oman bloginsa arvoinen, ehkäpä palaan siihen toisella kertaa. Jos asia on ajankohtainen, kannattaa etsiä muutama omat toiminnalliset ja ei-toiminnalliset vaatimukset täyttävä potentiaalinen tuote ja tutkia, onko lisensointimalli sopiva, tukeeko tuote haluamaanne topologiaa (pilvi / on-prem) ja miten se istuu olemassa olevaan infrastruktuuriin.

Miten lähteä liikkeelle?

Sen jälkeen, kun paperiharjoituksen pohjalta alkaa selviämään, mitkä tuotteet mahdollisesti täyttävät omat kriteerit, ei kannata jäädä liikaa vatvomaan, vaan pyöräyttää jonkinlainen proof-of-concept käyntiin. Suuri osa API-hallintatuotteiden toimittajista tarjoaa ilmaisversioita joko paikallisesti asennettavaksi tai suoraan pilvestä provisoitavaksi. Tästä ensimmäisestä proof-of-conceptista yleensä saakin jo hyvin osviittaa tuotteen kypsyystasosta ja käyttökokemuksesta (jos tuntuu, ettei tuotteen kanssa pääse edes liikkeelle, niin tuskin se hirveästi helpommaksi muuttuu jatkossakaan).

Omalla kohdallani tässä tuli taas kerran pilven ylivoimaisuus hyvin esiin siinä, miten nopeasti päästään liikkeelle paikallisten kilkkeiden ja virtuaalikoneiden yms. asenteluun verrattuna. Ja jos haluat lähteä ihan teknisestä mielenkiinnosta testaamaan ja opiskelemaan API-hallintaa, niin esimerkiksi IBM Bluemix -palvelussa pääsee todella nopeasti liikkeelle. Jatko-opiskelumahdollisuuksia uusille tekijöille on tarjolla myös Digian tulevassa Integraatioakatemiassa! Ja jos osaamista löytyy jo omasta takaa ja uudet haasteet kiinnostavat, niin tsekkaapa avoimet työpaikkamme aiheen tiimoilta ja tule juttelemaan.

Tutustu integraatio- ja API -aiheiseen myös nettisivuillamme>>