Tämä blogiteksti on alunperin julkaistu Tivin kumppanisisältönä.
Microsoftin mainetta kerännyt pilvipalvelu Azure kuulostaa äkkiseltään täydelliseltä ratkaisulta yrityksen kuin yrityksen järjestelmäintegraatioihin. Palvelut ovat edullisia, ne on helppo ottaa käyttöön ja visuaalisten käyttöliittymien avulla aloittelevatkin integraatio-osaajat saavat juonesta kiinni.
Azure onkin toimiva vaihtoehto järjestelmäintegraatioiden toteuttamiseen.
Ensivaikutelma saattaa kuitenkin pettää. Azuren pinnan alla piilee sudenkuoppia ja haasteita, jotka askarruttavat kehittäjätiimejä ja yrityspäättäjiä. Paras hetki näiden haasteiden välttämiseen on heti suunnitteluvaiheessa.
Azure on kirjasto erilaisia palveluita ja tarjoamia. Jokainen asiakas kokoaa näistä palasista omia tarpeitaan vastaavan yhdistelmän. Kyseessä ei siis ole yksi valmis palvelu, vaan erilaisia palvelukategorioita löytyy kymmenittäin tekoälystä palvelinkapasiteettiin. Näiden alla tuotteita on vielä yli kaksisataa ja näistä jokaisella on oma hinnoittelunsa ja ominaisuutensa.
Tiedätkö, mitkä ovat yrityksenne pitkän tähtäimen tavoitteet Azurelle? Kuka vastaa siitä, että käyttöön valikoituu tavoitteen kannalta toimivin yhdistelmä palveluita? Entä keillä yrityksen toimittajista on pääsy mihinkin palveluihin ja kuka vastaa pääsynhallinnasta?
Kokemuksen kautta olemme huomanneet, että alkuvaiheen kotiläksyt jäävät harmillisen usein tekemättä. Sen sijaan palveluvalinnat Azuressa on tehty useiden kehittäjien toimesta testaillen eri palveluita yksittäisiin tarpeisiin tai omien mieltymysten perusteella.
Pian punainen lanka onkin kadonnut jo kokonaan näkyvistä. Helpoksi ajatellusta Azuresta on muodostunut monimutkainen kokonaisuus, jonka hallinnointiin hukataan resursseja niin toimittajien kuin tilaajien päässä.
Kun ote kokonaisuuden hallinnasta lipsuu, hukataan myös Azuren todellinen potentiaali integraatioalustana.
Kokonaishallinnan jakautuessa myös integraatioiden seuranta ja monitorointi käy vaikeaksi. Seurannan lokitiedot ja palveluiden monitoroinnin metriikka hajautuvat monelle eri toimittajalle, joista osa ei välttämättä kirjaa tietoja ollenkaan.
Loki on aikajärjestyksessä kirjattu tallenne, johon kerätään tieto tietojärjestelmien, sovellusten, tietoverkkojen sekä tietosisältöjen tapahtumista ja muutoksista. Lokitieto siis kertoo mitä, miksi ja milloin jotakin tapahtui.
Kun toimijoita on useampia, kannattaa seurannalle rakentaa yhteiset pelisäännöt. Tällöin kaikki tietävät mitä, milloin ja minne lokitetaan. Mitä suurempi kokonaisuus on, sitä tärkeämpää on estää tiedon hajautuminen ja varmistaa yhteinen näkymä kokonaisuuden eri osista vastaaville toimittajille sekä tilaajalle itselleen.
Käyttöönotossa lokitusten suhteen tulee pyrkiä löytämään kultainen keskitie: tietoa tarvitaan, mutta jos lokitus on säädetty liian raskaaksi, hyödyllisen tiedon löytäminen massan seasta voi olla vaikeaa.
Palveluiden hinnoittelu on yksi Azuren yleisistä sudenkuopista. Hinnoittelumalleja löytyy paljon jo pelkästään yleisimpiä integraatiossa käytettyjä palveluita tarkasteltaessa. Hinnoittelu voi perustua integraatiossa suoritettujen tapahtumien määrään, käytettyyn palvelinkapasiteettiin, tunti- tai kuukausiveloitukseen tai erilaisiin palvelutasoihin.
Lasku kasvaa helposti turhan suureksi, jos suunnitteluvaiheessa ei olla tietoisia siitä, mistä valittujen palveluiden kustannukset lopulta koostuvat.
Optimoi kustannuksia näillä vinkeillä: