Rakenna ketterästi

Vuosien 1960–1995 välillä rakennettiin pääasiassa monoliittisia tietojärjestelmiä, joissa tietoa jaettiin pääosin organisaation sisällä ja joissakin tapauksissa alihankkijoiden kanssa. Pöytätietokone oli yleisin tapa käyttää digitaalisia palveluita.

Internetin kehittyminen toi mukanaan uudenlaisen hajautetun tavan käsitellä tietoa. 1990-luvun lopussa palvelukeskeinen arkkitehtuuri (Service-Oriented Architecture, SOA) nousi suosioon. Sen tavoitteena oli tehokas ohjelmien ja tiedon uudelleenkäyttö liiketoiminnassa.

Palvelukeskeisen arkkitehtuurin ydinajatuksia ovat

• palvelulähtöisyys
• yhteentoimivuus
• heikot riippuvuudet.

Nämä mahdollistavat tietojärjestelmän osien helpomman ja aiempaa nopeamman muuttamisen.

Palvelukeskeinen arkkitehtuuri perustuu siihen, että ohjelmistot tarjoavat erilaisia palveluita, joilla on neljä keskeistä ominaisuutta:

1. palvelu toteuttaa liiketoimintaa, jolla on määritelty tavoite
2. palvelu toimii itsenäisesti
3. palvelu piilottaa sisäpuolellaan olevan monimutkaisuuden
4. palvelu voi koostua muista palveluista.

Palvelukeskeisessä arkkitehtuurissa palvelut kommunikoivat ohjelmointirajapintojen kautta.

Vuoden 2010 jälkeen yleistyneet mikropalvelut toimivat myös ohjelmointirajapintojen avulla, mutta ne ovat itsenäisempiä ja kevyempiä kuin SOA-palvelut.

Mikropalveluarkkitehtuuri ja API ensin -malli ovat mahdollistaneet nopeamman ja joustavamman kehityksen. Samalla älypuhelimista tuli uusi käyttöliittymä, mikä lisäsi käyttäjämääriä merkittävästi.

Mikropalvelut ja API ensin -malli tekevät järjestelmistä joustavampia ja helpommin päivitettäviä. Niiden avulla uusia ominaisuuksia voidaan toteuttaa nopeammin ja kustannustehokkaammin verrattuna suuriin monoliittisiin tietojärjestelmiin.

Vuodesta 2014 yleistynyt palvelimeton arkkitehtuuri (serverless) antaa pilvipalveluntarjoajan, kuten AWS, hallita automaattisesti palvelinresursseja. Tämä nopeuttaa kehitystä ja vähentää kustannuksia, koska resursseista maksetaan vain käytön mukaan.

Serverless-mallien käyttö on kasvanut voimakkaasti 2020-luvulla: niissä koodi suoritetaan tarpeen mukaan (esimerkiksi FaaS), ja monet serverless-ratkaisut perustuvat rajapintakutsuihin tai toimivat tapahtumaperusteisesti.

Yhteenvetona voidaan todeta, että ohjelmointirajapintojen merkitys on kasvanut jatkuvasti viime vuosikymmeninä.

Kuva: Ohjelmistoarkkitehtuurin valitsevat tyylit 1960-luvulta alkaen

Näytä kuva suurempana

API-suunnittelussa on tärkeää huomioida granulariteetti, eli kuinka hienojakoisesti toiminnallisuus ja informaatio jaetaan ohjelmointirajapinnan kautta.

• Liian laaja (coarse-grained) API voi palauttaa liikaa tietoa (over-fetching), mikä hidastaa sen käyttöä ja tekee siitä tehotonta.
• Vastaavasti liian pirstaleinen (fine-grained) API voi johtaa siihen, että asiakas joutuu tekemään monta erillistä kutsua saadakseen tarvitsemansa tiedot (under-fetching), mikä lisää monimutkaisuutta ja viivettä.

Tasapaino löytyy asiakaslähtöisellä suunnittelulla:

1. kuuntelemalla käyttäjien tarpeita
2. tekemällä yhteistyötä kumppaneiden kanssa
3. dokumentoimalla selkeästi
4. hallitsemalla versioita.

Kun granulariteetti on oikein valittu, API on helppokäyttöinen, tehokas ja laajennettavissa tulevaisuuden tarpeisiin.

Hyvin suunniteltu API parantaa ohjelmistokehityksen tehokkuutta ja kestävyyttä pitkällä aikavälillä. API ensin -malli tukee myös ohjelmiston testausta ja laadunvarmistusta hankinnan alusta lähtien.