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.
Vaarana infrastruktuurinen sekasorto
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.
Seurannan ja monitoroinnin haasteellisuus
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.
Älä maksa turhasta vaan optimoi kustannukset
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ä:
- Aseta budjetti ja hälytykset. Tarkista laskut ja pyri ymmärtämään, mistä kustannukset syntyvät. Budjetoi Azuren tekeminen, jolloin voit kytkeä päälle hälytyksen kustannusten noustessa. Sen avulla voit säästyä maksamasta esimerkiksi kehittäjän testailuiden päätteeksi päälle unohtuneesta tarpeettomasta palvelusta.
- Älä maksa turhista toiminnoista. Kun Azuren hinnoittelulogiikat ovat tuttuja, sinun ei tarvitse maksaa mistään varmuuden vuoksi tai tulevaisuutta varten. Lähde pienestä liikkeelle ja kasvata kokonaisuutta ajan mittaa.
- Optimoi kustannuksia yhdistelemällä palveluita. Usein optimaalisin hinnoittelu löytyy, kun eri palveluita yhdistetään erilaiseen tekemiseen. Esimerkiksi hinnoittelu, joka perustuu suoritettujen tapahtumien määrään, on yksinkertaisissa ja harvoin toistuvissa integraatioissa hyvin kustannustehokas ratkaisu. Kustannukset saattavat kuitenkin nousta hetkessä, jos kehittäjille ei ole selvää, minkälaiset integraatiot nostavat maksuperusteena olevia tapahtumien suorituskertoja. Tällöin huomioi erityisesti usein toistuvat tai suurta tietomassaa pyörittävät integraatiot. Kiinnitä huomiota myös tiheästi toistuvaan ulkoisten palvelinten “pollaukseen” eli palvelinten tarkastamiseen uusien siirrettävien tiedostojen tai sanomien varalta.
