Kaikissa meissä asuu (kohta) pieni ohjelmoija

Sovelluskehitysrajapintatalous. Ihana sana. Kyse on siis jo pitkään valtavirtaa olevasta ilmiöstä, jonka juuret juontuvat ohjelmistojen yhteistoimintaan erilaisten rajapintojen kautta. Kokonaisuuden tavoitteena on levittää ja hyödyntää syntynyttä informaatiota paremmin, sitä kautta kehittää uusia palveluita ja loppuviimeeksi kasvattaa taloutta – joko firman tai yleisellä tasolla.

Tietoliikennepuolella valmistajat ovat jo vuosia rakentaneet erilaisia ajatuksia ohjelmisto-ohjatuista kokonaisuuksista. Liikkeelle lähdettiin konesaleista ja kaksi muuta isoa kokonaisuutta ovat jo jonkin aikaa markkinoilla nostetta saanut SD-WAN (Software-Defined Wide Area Network), sekä uusinpana tulokkaana SD-LAN (Software-Defined Local Area Network). Näissä toimintamallina on verkon konfiguraation ja toiminnan ohjaus erillisen kontrollerin kautta. Kontrollerin konfiguraatiosta huolehtii ihminen, mutta siihen voi kuulua joko perinteistä CLI-määrittelyä, skriptipohjaista määrittelyä tai pelkästään GUI-kliksuttelua.

Nykyisin suurin osa SD-maailmaan siirtyneistä organisaatioista on sillä tasolla että järjestelmät ovat pyörimässä ja verkon määritykset siirtyvät automaattisesti kontrollerilta verkkolaitteille. Tämä on mielestäni kuitenkin vain ensimmäinen askel tuotteiden hyödyntämisessä laajemmin.

Sovelluskehitysrajapinta

Kaikki SD-maailman kontrollerit ja nykyään moni perinteinenkin verkonhallintatyökalu tarjoavat erillisen sovelluskehitysrajapinnan, eli APIn (Application Programming Interface). API mahdollistaa kontrollerin ohjaamisen ohjelmallisesti. Tämä avaa kokonaan uusi näkymiä verkon toiminteiden määrittelyyn.

Yksinkertaisin tapa hyödyntää tarjottuja rajapintoja on rakentaa toimintaspesifisiä skriptejä. Esimerkkinä tästä on vaikkapa VLAN-määrityksen lisääminen kaikkiin lähiverkkojen kytkimiin. Skriptille annetaan parametriksi VLANin nimi ja numero, jonka jälkeen se komentaa APIn kautta kontrolleria ajamaan määrittely verkon laitteille. Toinen esimerkki on vaikkapa laiteinventaarion tallentaminen erilliseen tiedostoon raportiksi. Skripti käy kysymässä kontrollerilta sillä tiedossa olevat laitteet ja ohjaa saadun informaation haluttuun tiedostoon. Kolmantena esimerkkinä voisi olla uusien toimipisteiden suunnittelutietojen automaattinen hyödyntäminen suunnittelujärjestelmän ja kontrollerin välillä erillisen välittäjäohjelman avulla.

Huomattavasti monimutkaisempi ja enemmän aikaa vaativa tapa rajapintojen hyödyntämiseen on rakentaa palveluportaali tyypillisimpien asioiden tekemiseen käyttäjien toimesta. Esimerkiksi riittävän osaava lähituki voisi hyvin määritellä portaalin kautta yksittäisen kytkimen päätelaiteportin VLANin sen sijaan että siitä avataan tiketti, jonka sitten verkon ylläpitäjä käy hoitamassa. Samassa ajassa kun tiketti avataan, voitaisiin toimenpide jo suorittaa.

Palveluportaalin kehittäminen on haastavampaa, sillä se vaatii sekä käyttöliittymän, että sen alla olevan toimintalogiikan rakentamista. Tämän vuoksi se ei ole ihan jokaisen organisaation ensisijainen tavoite. Uskon kuitenkin, että portaalin kautta olisi saavutettavissa huomattaviakin kustannus- ja aikasäästöjä.

Sovelluskehitys

Miten edellä mainittu sitten liittyy tavalliseen verkon ylläpitäjään? Jos halutaan jatkaa “vanhassa maailmassa”, voidaan verkon konfiguroinnista huolehtia edelleen komentorivikäyttöliittymän kautta. Tässä ei ole mitään pahaa, tai väärää, mutta suhteellisen tehotonta ja hidasta se on. Tiketöidyt rutiinimuutokset työllistävät ylläpitoa, ja kaikki niihin käytettävä aika on poissa infrastruktuurin kehittämisestä.

Huomattavasti tehokkaampi ja erityisesti mielekkäämpi tapa on automatisoida rutiinitehtäviä mahdollisimman pitkälle. Yksittäisen ylläpitäjän näkökulmasta tämä tarkoittaa vähintään skriptitasoisten ohjelmien tuottamista. Tietojen ja taitojen karttuessa voidaan siirtyä skripteista laajempienkin kokonaisuuksien tekemiseen. Skriptit ovat kuitenkin hyvä lähtökohta, sillä ne ovat lyhyitä ja helppoja tehdä, jolloin kynnys aloittamiselle on pieni.

Kun skripteja alkaa sitten olla kertynyt riittävästi, eli pohjalla on perusmassaa erilaisten asioiden toteuttamiseen, voidaan harkita laajempaa kehitysvaihetta. Käytännössä aina päädytään portaalimalliin, jossa vähintään menupohjaisesti laitetaan skriptit tarjolle kaikkien oikeudellisten osapuolien hyödynnettäväksi.

Kehitys

Moni perinteinen verkkoammattilainen on syvästi juurtunut CLI-maailmaan. Kun on 10-20 vuotta hakannut konfiguraatiota rivi kerrallaan erilaisiin verkkolaitteisiin, on rutiinista vaikea luopua. Lisäksi ohjelmistokehittäjiä on totuttu katsomaan vähintäänkin sivusilmällä, jos ei ihan kulmat kurtussa. “Minusta ei ainakaan tule ohjelmoijaa”, on moni ajatellut vuosien aikana. Tämän vuoksi kynnys ohjelmoinnin – edes sen yksinkertaisen skriptaamisen – aloittamiseen on suhteellisen korkealla.

Helppo tapa madaltaa kynnystä on käydä kurssi. Elisa Santa Monicalle tulee syksyllä tarjolle “Verkkolaitteiden ohjelmoitavuuden perusteet” -koulutus, joka lähtee ihan nollasta liikkeelle ja on siten tarkoitettu aivan aloittelijalle. Läpi käydään yleisimmin käytettäviä mekanismeja ja tutustutaan Python-kielen toimintaan ja käyttöön skriptien tekemisessä ja API-rajapintojen hyödyntämisessä.

Useilla nykyisillä tekijöillä on vielä reilusti työaikaa jäljellä ennen eläkeikää, joka tuntuu koko ajan karkaavan kauemmaksi. Maailma muuttuu vinhaa vauhtia ja perustason ohjelmoitavuustaidot tulevat jatkossa olemaan rutiininomaisesti työpaikkailmoitusten vaadimme/toivomme-listassa. NYT voisi olla hyvä aika alkaa prepata itseään kohti uutta maailmaa ja siten varmistaa käyttöarvonsa myös tulevaisuudessa.

Kirjoittanut

Aki Anttila työskentelee Elisa Santa Monicalla infrastruktuurievankelistana.