Webin teknisen toteutuksen historiasta ja nykytilasta – haastattelussa Jouni Heikniemi

Microsoft ei ole edelleenkään se teknologiatalo, joka tunnetaan parhaiten webin perusteknologioiden taustayhtiönä, mutta todellisuudessa Microsoft on iso vaikuttaja siihen, miten nykyaikainen internet rakentuu. Suomessa käytetään myös erittäin paljon Microsoftin tuotteita, joka väistämättä johtaa myös siihen, että monenlaisia asiointipalveluita ja web-sovelluksia toteutetaan Microsoft-teknologioilla.

Erityisesti Optimizely (aiemmin Episerver) on vaikuttanut siihen, että isojen yritysten verkkopalveluita on Suomessa edelleen paljon Microsoft-teknologioilla. Monien mobiilisovellusten ja asiointipalveluiden taustalta myös löytyy Microsoftin teknologiaa, vaikka startup-maailmassa ja pienempien digitoimistojen työkalupaleteissa sitä on vähemmän.

Nykyisin monessa paikassa on selkeä ero käyttäjille näkyvän kerroksen (frontend) ja taustasovellusten (backend) välillä, eikä näiden enää tarvitse olla automaattisesti jotenkin samasta puusta veistettyjä. Tämä on osaltaan lisännyt jopa Microsoftin teknologioiden käyttöä erilaisten web-sovellusten toiminnassa, koska kuten Heikniemi haastattelussa kommentoi, jos taustasovelluksia on enemmänkin Microsoftin teknologioilla, voi se vaikuttaa siihen, että myös sen asiointisovelluksen backend-sovellus kannattaa tehdä Microsoftin teknologioilla.

Microsoft-maailma voi myös herkästi tuntua jonkinlaiselta klaanilta tai jopa uskonnolta, koska yhteisön sisällä on vähemmän ”sekakäyttäjiä”, eli suurin osa tekee vain ja ainoastaan Microsoftin teknologioilla asioita. Tätäkin Heikniemi kommentoi haastattelussa, ja epäilemättä Microsoft Finlandilla ja sen kumppaniohjelmalla on tähän vaikutusta. Yritykset, jotka tekevät Microsoftin leluilla töitä, ovat usein täysillä Microsoft-kumppaneita eivätkä tee kovin paljon muilla teknologioilla asioita. Isojenkin integraattoreiden sisällä Microsoft-tiimit ovat Suomessa usein aika itsenäisiä ja omillaan toimivia ”yrityksiä yritysten sisällä”.

Haastattelussa nousee hyvin esiin se, miten ison askeleen koko internet ja webin tekeminen on ottanut 2000-luvulla. Hyvin sirpaleisesta ja bugien riivaamasta ympäristöstä on tultu merkittävästi standardoidumpaan ympäristöön, jossa käytetään samoja ohjelmistokehyksiä ja esitystekniikoita riippumatta taustasovellusten merkistä ja mallista.

”Full stack” -osaamisen vaatimusta myös sivutaan, ja vaikka sen vaatimuksia on tässäkin blogissa ajoittain kritisoitu, on Heikniemellä hyvä näkökulma aiheeseen: Suomessa tehtävät web-sovellukset ja verkkopalvelut ovat keskimäärin aika pieniä, jolloin on merkittävä tehokkuusetu, jos samat henkilöt pystyvät koskemaan niin fronttiin kuin backendiin.

Heikniemi nostaa esiin myös internetin kehittyvät käyttötavat, kun asiakkaina ovat myös sisältöjä lukevat AI-moottorit ja erilaiset agentit. Kulman takana on erityisesti lisääntyvä agenttinen käyttö, jossa joku AI-agentti käyttääkin sivustoa tai asiointipalvelua ihmisen puolesta. Web-palveluita toteuttavien ohjelmistokehittäjien pitää osata rakentaa verkkopalvelut tukemaan myös tällaista käyttöä, niin frontissa kuin rajapintojen tasolla.

Haastattelussa Jouni Heikniemi

Mitä Microsoft ajattelee nykyisin webin tekemisestä? Aiemminhan Microsoftilla oli hyvinkin vahvoja, aika omanlaisia tapoja tehdä webbiä, mihin se kaikki on kadonnut?

Microsoft on varsin monilla alueilla – webin ulkopuolellakin – tunnustanut, että avoimen lähdekoodin yhteisöissä on arvonsa ja luopunut omien ratkaisujen tekemisestä silloin, kun parempaa on valmiina olemassa. Osa tästä liittyy tekniseen realismiin (open source -ekosysteemin kypsyys esimerkiksi tukivaihtoehtojen osalta on kasvanut), osa taas alan kaupallisen asenteen muuttumiseen (asiakkaatkaan eivät välttämättä enää halua ostaa yhdellä lisenssisopimuksella kaikkea palomuureista UX-kirjastoihin).

Täytyy myös muistaa, että webiä on tehty vuosien saatossa hyvin monella tavalla ja taustalla. Microsoftin eksentrisimpien web-viritelmien taustalla oli pyrkimys tehdä webbikehityksestä saavutettavaa työpöytäsovellusten kehittäjille, joita tilaton client/server-arkkitehtuuri ja JavaScript-ohjelmointi pelotti. Ajatukselle on helppo nauraa nyt, mutta n. 20 vuotta sitten maailman suosituin web-selain oli Microsoftin Internet Explorer 6 yli 90 % markkinaosuudella, ja eri selainten erot poistava jQuery-kirjasto oli muutaman viikon vanha uusi voodoo-viritys. Tässä mielenmaisemassa on Microsoftin silloista full stack -maailmanvalloitushalua paljon helpompi ymmärtää.

Kun JavaScript, responsiivinen taitto, mobiililaitteet, DOM, CSS ym. alkoivat yleistyä ja kehittyä standardoituun suuntaan, Microsoftin kannatti suunnata resurssinsa muualle. Sen ihmeempää tarinaa tästä ei kannata etsiä, vaikka tietysti vanhojen vastakkainasettelujen näkökulmasta tuntuu ilahduttavalta, että Microsoft tuottaa nykyään jopa omaa Linux-jakelua.

Vaikuttavatko käyttäjälle näkyvän frontend-kerroksen vaatimukset ja teknologiat mielestäsi siihen, miten se web-sovelluksen backend-maailma pitää toteuttaa?

Varmasti, joskin vähemmän kuin ehkä haluttaisiin ajatella ja mitä kehittäjäpiireissä lobataan. Devaajan oma suosikki tuntuu usein parhaalta kaikessa, mutta todellisuudessa tiukkoja frontendin ja backendin välisiä riippuvuuksia on onneksi aika vähän. Suorituskyvyn kaltaiset seikat voivat ohjata toimintaa, mutta varsinkin Suomessa on äärimmäisen poikkeuksellista, että teknologiavalinta olisi tässäkään kriittinen – volyymit eivät vain ole riittävän suuria.

Kannustaisin valitsemaan teknologiat sen mukaan, mikä on ratkaisun elinkaaren, tiimien osaamisen ja muun synergian kannalta tarkoituksenmukaista. Backendin teknologiavalintaan vaikuttaa usein mahdollisen liittyvän sovelluksen koodipohja. Jos esimerkiksi rakennetaan extranet-toiminnot laajan Microsoft-teknologialla tehdyn sisäisen sovelluksen kylkeen, saattaa olla hyvinkin viisasta käyttää backendin toteutukseen Microsoft-teknologiaa, koska tällöin liiketoimintalogiikkaa ym. voidaan jakaa ratkaisujen välillä. Modernin frontin toteutus toisaalta tehdään kuitenkin pitkälti rajapintojen päälle, joten siinä teknologioilla ei pitäisi olla kovin suurta sidontaa toisiinsa: REST meidät rauhoittakoon.

Miksi Suomessa on niin vähän Microsoftin työkaluista pitäviä web-kehittäjiä? Mistä johtuu se, että web-kehittämisen ja frontend-toteutuksen maailma on niin vahvasti ihan jotain muuta kuin Microsoftia?

Koulumaailmassa Microsoft-sovelluskehitystä opetetaan nykyään melko vähän, moninaisista syistä. Tämä varmasti ohjaa osan porukasta suoraan ajattelemaan ensisijaisesti muita järjestelmiä. Lisäksi Microsoftin enterprise-maine ja markkina-asema eivät ehkä houkuta tarttumaan sen tuotteisiin aivan ensimmäisenä vaihtoehtona, vaikka mitään teknisiä esteitä ei olekaan – kaikki arjessa tarvittava on ilmaista ja avointa joka tapauksessa. Samaan aikaan toki on niin, että on vaikea löytää devaajaa, joka ei koskisi Microsoft-tavaraan työkalumielessä: Visual Studio Code ja GitHub ovat käytännössä jokaisen työkalupakissa.

Ammattiurallahan kyse on sitten paljolti yhteisöistä; harva pienempi yritys tekee Microsoft-ratkaisuja vain osittain. Joko niitä tehdään täysillä ja osana Microsoftin kumppaniohjelmaa, tai sitten keskitytään esimerkiksi Nodeen. Työkavereilla on usein hyvin samankaltainen osaaminen. Ensimmäinen työpaikka on usein osin sattumaa, mutta sen jälkeen kuplasta toiseen hyppääminen ei välttämättä innosta, varsinkin jos devaajaa ohjaa esim. toive palkkakehityksestä. Valtaosa seniorikehittäjän osaamisesta ei ole erityisen työvälinespesifiä, mutta ei se siltä tietysti tunnu, jos pitäisi loikata vakiintuneen ison projektin arkkarin paikalta (ja palkalta) tekemään jotain täysin vierailla välineillä.

Miten sinun näkökulmastasi web-sovellusten tekeminen on muuttunut 2000-luvulla, mitkä ovat olleet isoimpia muutoksia tekijöiden ja sovellusten ostajien näkökulmasta?

”2000-luku” on pitkä aika! Vuosituhannen vaihteessa meillä oli ajossa vielä C-kielisiä ohjelmia, jotka generoivat HTML:ää käsin, ja aidosti dynaamisia verkkopalveluita pidettiin vielä melkoisena taikuutena…. Isot virstanpylväät kehityksessä olivat minusta nämä:

• Hakukoneet: Googlen yleistyminen pakotti tekemään sisällön indeksoituvaksi, ja SEO syntyi.
• DOM/CSS-standardoituminen + jQuery: Fronttiohjelmointi lakkasi olemasta selainkohtaisten bugien kiertelyä
• Mobiililaitteet: Responsiivisuus, suorituskyky, sisällön tuominen keskiöön
• NPM, GitHub ym.: Avoimen lähdekoodin työvälineiden määrä räjähti, kun niiden jakelusta tuli helppoa
• Pilvi ja PaaS: Webbisivujen teknologia-alustan määrää yhä useammin kehittäjän tahto, koska ”serverien asentaminen” ei ole enää ongelma. Samalla kehittäjästä on tullut entistä enemmän full stack: Monesti devaaja päätyy konfiguroimaan verkot siinä samalla, kun se kerran helposti onnistuu…
• Isot fronttikirjastot kuten React: Vihdoin vakiintuneita tapoja tehdä myös sitä fronttipäätä!

Ostamisen puolella isoin muutos on tietysti se, että ensin siirryttiin isoista vesiputousprojekteista sprinttipohjaiseen agileen, ja sen jälkeen on lähdetty hakemaan arvoa usein entistä pienemmillä kanban-henkisillä pyräyksillä. Toisaalta verkkopalveluiden integraatioiden määrä on kasvanut, ja ne ovat yhä useammin osa laajoja IT-hankesalkkuja ja ekosysteemeitä; vastuu oikeasta suunnittelusta korostuu. Kevyemmän ostamisen ja kriittisemmän roolin välillä on myös looginen ristiriita, jos kokonaisuutta ei osata johtaa oikein.

Ja jos oikeasti koko 25 vuoden aikajännettä katsotaan, niin onhan verkkopalvelun ostamisen ja pyörittämisen kaupallinen ohjaus aivan eri tasolla: sellaiset käsitteet kuin asiakkuuden elinkaariarvo, konversiofunneli tai edes luotettava kävijämäärien seuranta eivät kyllä olleet hirveän vahvasti pöydällä Iso Kvartaali sitten, kun CRM:kin oli usein vielä mapissa…

Onko se hyvä asia, että on menty erilliseen fronttiin ja bäkendiin? Tässäkin blogissa on puhuttu paljon full stack developer -unelmista, onko sellainen edelleen lähinnä unelmointia? Vai eriytyvätkö frontend ja bäkend vain entisestään, kun väliin ovat tulleet rajapinnat eikä eri puolilla tarvitse välttämättä enää tietää toisesta puolesta niin paljon.

Tämä on varmasti ollut välttämätön kehityssuunta järjestelmien kasvaessa ja monipuolistuessa. Vuosikymmeniä vanhat web-sivustot on jo uudelleenkirjoitettu, ja web-sovelluksetkin enimmäkseen. Vanhat monoliitit käyvät hyvin raskaiksi ylläpitää, koska valitettavasti tiukka frontendin ja backendin yhteys näyttäytyy myös kankeutena: yhtä asiaa on vaikea muuttaa koskematta toiseen.

Sisäinen API-kerros frontendin ja backendin välissä antaa liikkumasauman, ja ilokseni olen nähnyt useammankin projektin, jossa vanhan backendin päälle on ehditty iteroimaan jo useampikin frontti – visuaaliset ja konseptuaaliset tarpeet kun tuppaavat muuttumaan selvästi nopeammin kuin backendiin leivotut prosessit ja datarakenteet. Toisaalta tässä tehdään se oletus, että projektin arkkitehti on aikanaan osannut piirtää backendin ja frontendin rajan oikein; huonosti tehtynähän tämä jako tuottaa pelkkää muutosvaikeutta ja lisäkustannuksia.

Kehittäjän full stack -osaaminen on toki loistava valtti: Valtaosa suomalaisista palveluista on kuitenkin niin pieniä, että erityisesti ylläpito- ja jatkokehitysvaiheessa on hyvin tehokasta, jos samat henkilöt pystyvät työstämään koko pinoa. Testaamisen, asentamisen, versioinnin, skaalaamisen ym. kannalta on silti monesti ihan hyödyllistä, että nämä moduulit ovat arkkitehtuurisesti erillään. Mutta onko se välttämätöntä? Tuskinpa, aivan isoimpia järjestelmiä lukuunottamatta. Jälleen katsoisin sitä, mitä tiimi osaa ja miten monimutkaiseen hallintaan realistisesti halutaan lähteä. A/B-testaukset sun muut liittyvät aiheeseen ja ovat monien unelmissa, mutta ei niitä kannata ottaa perusteluksi suunnitteluvaiheessa, jos käyttö ei tunnu mitenkään realistiselta.

Mitä hyvää on tapahtunut web-sovellusten alueella viime vuosina? Mikä on mennyt paremmaksi?

Onhan webin tekeminen keskimäärin kypsynyt aika paljon. Vuosikymmenen takainen perussaitti oli rumempi, epämääräisempi ja liiketoiminnasta irrallisempi kuin nykyratkaisut. Koen myös, että tietoturvassa on tapahtunut perustason parannus: Toteutamme yhä useammin perusratkaisutkin käyttäen valmiita laadukkaita komponentteja, jolloin huolimattomuusvirheiden määrä vähenee. Toki SQL-injektion tai XSS-haavoittuvuuden voi yhä tehdä, mutta lähtökohdat ovat silti paremmat.
Nostaisin esiin myös keskimääräisen arkkitehtuurin kypsymisen. Esimerkiksi sisältö ja muotoilu ovat nykyisin useammin selkeämmin erillään toisistaan, olkoonkin että välillä syy on ulkoinen – esimerkiksi päätös käyttää headless CMS:ää. Tämä erottelu on usein vaatinut lisätyötä projektivaiheessa, mutta siitä tulee olemaan vielä hyötyä. Yksi hyvä käyttökohde lähivuosille voi olla esim. valmistautuminen agenttiasiointia ja ylipäätään AI-tiedonhakua varten. On teknologia sitten NLWeb, MCP tai mikä tahansa muu, kyky nähdä sisällöt irrallaan html-muotoilusta on keskeinen osa tätä uutta web-paradigmaa.

Mitä huonoa on tapahtunut viime vuosina, mitkä asiat eivät tunnu menevän pelkästään parempaan suuntaan?

Teknisesti olen tietysti aina huolissani kasvavasta monimutkaisuudesta – tehdäänkö nyt varmasti niin yksinkertaista kuin mikä riittäisi, vai halutaanko tehdä mikropalvelut ja SSR:t ihan vain siksi koska olisi kiva? Lelulaatikon kasvaminen tuppaa johtamaan ylilyönteihin, ja devaajien täysin ymmärrettävä tarve pitää osaamisensa ja CV:nsä ajantasalla kannustaa teknoaggressioon. Asiakkaalle tässä on kuitenkin riski.

Eniten ehkä kuitenkin huolettaa se, miten varsinkin monimutkaisemmat sovellukset yhä useammin rakennetaan bodyshopping-tyyppisissä olosuhteissa – asia, josta puhuin jo Hesarissa pari vuotta sitten. Tässä ei itsessään ole mitään vikaa, mutta järjestelyssä missataan menetelmäkehitykseen panostavan työnantajan ja stabiilin tiimin edut. Valitettavasti auditointipuolella on tullut vastaan jo useampia sellaisia ratkaisuja, joissa tiimin lähtökohtien hajanaisuus on heijastunut lopputulokseen asti.

Ostamisen malli ei määrää lopputuloksen laatua, mutta sen pitäisi määrätä johtamisen ja rakennusvalvonnan tapa. Jos näin ei käy, Conwayn laki (”Järjestelmän rakenne muistuttaa sen tuottaneen organisaation rakennetta”) löytyy aika helposti lähdekoodista.

Moni asiakas keskittyy nykyisin lähinnä tiimin osaamiseen ja päivähintoihin, tuntuu että moni ei välitä lainkaan siitä, miten joku asiointipalvelu tai räätälöity sovellus käytännössä tehdään. Jopa ylläpidettävyydestä ja elinkaarikustannuksista tuntuvat jotkut ajattelevan, että ”ihan sama millä tehdään, kaikki maksaa saman verran ja kaikki saadaan kyllä skaalaamaankin” – onko tämä mielestäsi totta?

Jo 70-luvulla akateemisessa tutkimuksessa todettiin, että valtaosa ohjelmiston elinkaarikustannuksista syntyy tuotantoonsiirron jälkeen. Teknologia ei niitä kustannuksia määrää, mutta toteutusvaiheen johtaminen isolta osin kyllä. En haluaisi argumentoida, että jokin tietty toteutusväline johtaa onnistumiseen tai epäonnistumiseen muita helpommin, mutta väitän, että välinpitämättömyys toteutustavasta vaikuttaa lopputulokseen olennaisesti – tietenkin erityisesti isommissa projekteissa. Jos et itse ostajana osaa valvoa toteutustiimiä tai johtaa teknologiaa, ota tueksi joku joka osaa.

Jos olisit aloittava ohjelmistokehittäjä juuri nyt ja olisivat kiinnostunut web-sovellusten ja frontend-frameworkkien kanssa työskentelystä, niin mitä opiskelisit ja mihin keskittyisit? Ottaisitko selvää myös Microsoftin välineistä vai eikö sillä ole enää merkitystä?

Nyt aloittavalla kehittäjällä todennäköisesti on aikaa opiskella melko monialaisesti, sen verran hankala työtilanne on. Kyllä käyttäisin tätä aikaa osaamisen leventämiseen, olkoonkin ettei yksi webbiteknologiapino lisää siinä rinnalla teekään kenenkään CV:stä kultaista. Se voi kuitenkin olla hyvä erottautumistekijä jossain kisassa. Lisäksi useille teknologiapinoille altistuminen helpottaa sitä kuplasta toiseen hyppäämistä, josta jo aiemmin puhuttiin. Ei kukaan pysty kuitenkaan koko työuraansa tekemään samoilla välineillä – minullakin on vyön alla ne kymmenkunta ohjelmointikieltä lähinnä siksi, että viimeisen 30 vuoden aikana sekä kohteet että vaatimukset ovat muuttuneet aika monesti.

Samaan muutokseen kannattaa valmistautua jatkossakin.

>> Lisää Jounin ajatuksia voi kuunnella esimerkiksi Ikkunastudio-podcastista.

PS. Tilaa Vierityspalkin noin kerran kuukaudessa ilmestyvä uutiskirje.