Internal Developer Platformit: DEVOPS CONFERENCE 2023 -paneelin opit

Huhtikuussa 2023 tapahtumassa esiintyi muun muassa puhujia, kuten Kelsey Hightower, Nicole Forsgren, Helen Baal ja Dom Price.

The DEVOPS Conference ei kuitenkaan ole vain puheenvuoroja tarjoava tapahtuma. Se on myös tiedon jakamiseen keskittyvä yhteisö. Tärkeä osa tapahtumaa oli interaktiivinen ohjelma, johon kuului takkatulikeskusteluja, avoimia keskusteluja ja live-demoja.

Sain kunnian juontaa paneelikeskustelua DevOpsista ja platform engineeringistä. Miten Internal Developer Platformien (IDP) rakentaminen tukee DevOpsia? Mitä hyötyjä ja haasteita niiden käyttöönottoon liittyy? Miten ne vaikuttavat kulttuuriin ja työskentelytapoihin? Näitä keskeisiä kysymyksiä käsittelivät paneelikeskustelijat:

Bjørn Hald Sørensen (Head of Technology, Lunar)

Tuomas Leppilampi (DevOps Consultant, Eficode)

Dan Grøndahl Glavind (DevOps Consultant, Eficode)

Osallistujat olivat aktiivisesti mukana kysymys- ja vastausosioissa. Teimme myös kyselyn selvittääksemme heidän taustaansa: yli 50 % yleisöstä ei tuntenut IDP:itä, noin 30 % oli ainakin aloittanut niiden parissa työskentelyn ja muut harkitsivat sellaisen rakentamista.

Tässä on yhteenveto paneelikeskustelusta pääteemoittain.

Paneelikeskustelu DevOpsista ja platform engineeringistä

Tarvitaanko IDP:itä todella?

Mario: Miksi näitä Internal Developer Platformeja ylipäätään tarvitaan? Vai onko kyse vain trendistä, jota seuraamme nyt, kuten Kubernetes oli muutama vuosi sitten? Mitä ajattelette?

Bjorn: Uskon, että kyse on ennen kaikkea ongelmista ja ohjelmistokehityksen tapojen kehittymisestä. IDP:t ja alustat yleisesti kehittyvät jatkuvasti. Ne kulkevat käsi kädessä sen kognitiivisen kuorman kanssa, jota asetamme kehittäjille.

Miten voimme organisoitua tehokkaampiin työskentelytapoihin? Uskon, että platform engineering on juuri nyt yksi niistä asioista, jotka voivat tuottaa kehittäjille merkittävää arvoa.

Tuomas: On suuri kilpailuetu, jos voit sanoa kehittäjillesi: ”Voitte keskittyä koodaamiseen, ongelmanratkaisuun ja siihen, mitä todella rakastatte tehdä, sen sijaan että joutuisitte esimerkiksi käsittelemään Jenkinsiä.”

Dan: DevOpsissa ajattelutapamme on ollut: ”Rakennat sen, käytät sitä.” Mutta mitä se oikeastaan tarkoittaa? Tarkoittiko se koko pinoa sovelluksistamme aina bare metal -tasolle asti? Siinä monimutkaisuus tulee mukaan. Yksi platform engineeringin lupauksista onkin tämä: ”Meidän ei tarvitse tuntea kaikkea tätä syvälle menevää monimutkaisuutta.”

Tekniset ja kulttuuriset näkökulmat

Mario: Kun katsoo kaikkia IDP:istä löytyviä blogikirjoituksia ja materiaaleja, vaikuttaa siltä, että tekninen näkökulma korostuu. Eikö kyse ole kuitenkin enemmän Developer Experiencen kehittämisestä? Miten näette teknisen näkökulman ja Developer Experiencen potentiaalin? Onko se IDP:ille ominaista, vai mikä on tässä tärkein näkökulma?

Tuomas: Hyötyjen näkökulmasta Developer Experience auttaa pitämään hyvät kehittäjät talossa. Ihmiset pysyvät mukana, ja se on todella tärkeä osa platform engineering -trendiä.

Minun näkökulmastani kyse on ennen kaikkea DevOpsista. Kyse on DevOpsista ja ketteryydestä, joita pyrimme kulttuurina saavuttamaan. Platform engineering ja Internal Developer Platformit ovat vain yksi tapa saavuttaa ja ylläpitää tällaista kulttuuria.

Bjorn: Kun vuosien mittaan yhä useammilta ihmisiltä odotetaan enemmän – esimerkiksi autonomisissa tiimeissä – monet uupuvat, jos heidän pitäisi tuntea kaikki asiat, jotka voivat mennä pieleen monimutkaisissa hajautetuissa järjestelmissä. Se ei ole tarkoitus. Se ei tuo kehittäjillemme iloa. Eikä se sitouta heitä tuottamaan arvoa liiketoiminnalle.

Minulle IDP ei ole vain yksi asia. Se ei ole alusta eikä tekninen ratkaisu, jonka voi ottaa hyllystä ja tarjota käyttöön. Se on pikemminkin kokonaisvaltainen näkemys kaikista asioista, joiden avulla kehittäjämme voivat tehdä sen, mitä heidän pitää tehdä.

Dan: Mielestäni se on ajattelumalli, jolla vastataan kyvykkyyksiin, joita haluamme kehittää sekä itsellemme että muille kehittäjille. Kyse on kokonaisvaltaisemmasta asiasta: siitä, miten voimme luoda ihmisille kyvykkyyksiä ja osaamista, jotta he voivat olla sekä tyytyväisiä että tuottavia.

Ylläpitokuorma ja nyrkkisääntö

Mario: IDP voi siis tuottaa paljon arvoa. Mutta jos se tarjoaa kaiken, eikö sen ylläpidosta ja hallinnasta tule vaikeaa? Ja tähän liittyvä kysymys: onko olemassa nyrkkisääntöä sille, kuinka monta kehittäjää yrityksellä yleensä pitäisi olla, jotta IDP:n rakentaminen olisi perusteltua?

Tuomas: Se voi olla vain joukko dokumentteja tai ohjeita parhaista käytännöistä. Siksi sillä ei ole väliä, onko kehittäjiä viisi vai kaksi. Se rakentaa mielikuvaa alustasta, jonka varaan voi tukeutua, kun alkaa luoda jotain uutta, kuten ominaisuutta, sovellusta tai palvelua. Kun tämä on olemassa, muiden on helpompi tulla mukaan.

Dan: Juuri tätä itsekin mietin. Missä määrin kehittäjän tarpeisiin vastataan build-tuotosten, CI/CD-työkalujen, mahdollisesti toimitusketjun tietoturvan ja vastaavien osalta – ja miten siirrytään pohtimaan, millainen käyttöönotto strategia valitaan.

Entä mitä voidaan kattaa havainnoitavuuden ja monitoroinnin sekä vastaavien asioiden osalta? Kaikki nämä alueet saatetaan pystyä kattamaan kerralla. Jos näin on, organisaatio voi ehkä kasvaa niin, että useammat alustatiimit tekevät yhteistyötä saman alustan parissa.

Bjorn: Aluksi teimme juuri sitä, mistä puhuit: oppaita siihen, miten asioita tehdään, miten uusi palvelu otetaan käyttöön ja miten ohjelmistojen kanssa työskennellään tehokkaasti – emme siis lähteneet liikkeelle vain perusteista. Rakensimme sitä vähitellen eteenpäin. Jossain vaiheessa kasvoimme siitä ulos. Se muistutti hieman DevOpsin kehitystä: tiimit itse kasvoivat siitä ulos, kun pyrittiin löytämään hyvä toimintatapa.

Perustimme siis kaksi uutta ydintiimiä pohtimaan tarkemmin, miten voisimme optimoida työnkulkuja, mitä voisimme automatisoida ja miten voisimme auttaa kehittäjiä heidän päivittäisessä työssään. Tämä on vuosien myötä kasvanut nykyiseen muotoonsa: kolme alustatiimiä tarjoaa Lunar-kehitysalustan. Palvelemme eri käyttäjäryhmiä.

Eli liikkeelle kannattaa lähteä pienestä, koska tarjottavan arvon määrittely on helpompaa, kun ongelma on selkeä: ”Haluamme tiimin ratkaisemaan tämän ongelman, ja ymmärrämme ongelman tämän kokoiseksi.” Siinä on arvo. Sen jälkeen täytyy pohtia, miten siitä tehdään alusta. Voimme tehdä yhden pienen työkalun ja sitten toisen, mutta ajan myötä asiaa on tarkasteltava kokonaisuutena, jotta kehittäjät tietävät, mistä löytää tietoa.

Lunarilla suhdelukumme on yksi kymmeneen: yhtä alustainsinööriä kohden on noin kymmenen kehittäjää. Suhdeluvut vaihtelevat yrityksittäin, mutta ne riippuvat muun muassa siitä, kuinka yhtenäisiä infrastruktuuri ja kehitysympäristöt ovat sekä millainen teknologiahistoria organisaatiolla on.

Kognitiivinen kuormitus

Mario: Kuinka suuri kognitiivinen kuormitus on kehittäjälle sopiva? Yksi näkökulma on, että kehittäjillä on yksi paikka, jossa he voivat tehdä varsinaista työtään. Mutta ratkaiseeko se kaiken kognitiivisen kuormituksen? Vai liittyykö kyse myös automaatioon? Miten nämä kaksi asiaa yhdistyvät?

Tuomas: Mielestäni se on hyvin henkilökohtaista. Juniorikehittäjän työ ohjelmistojen arkkitehtuurin uudistamisen ja refaktoroinnin parissa on erilaista kuin niin sanottujen ”UNIX-tyyppien” hyvin erikoistunut työ. Se riippuu paljon siitä, mistä olet intohimoinen. Millainen kehittäjä itse olet?

Bjorn: Mielestäni se on henkilökohtaista, ehdottomasti. Tyypillinen vastaus on ”se riippuu”, mutta kehittäjien kanssa on keskusteltava. Kysy heiltä: ”Mitkä ovat kipukohtanne? Missä koette tuhlaavanne aikaa? Mitkä asiat vievät sitoutumisenne pohjalukemiin, koska niiden parissa työskentely ei tunnu mielekkäältä?” Siinä kulkee kognitiivisen kuormituksen raja.

Se on kuin 80 prosentin sääntö: jos tarjoat ominaisuuksia, jotka kattavat 80 prosenttia teknologiasta, esimerkiksi organisaation tarpeista, emme ehkä käytä aikaamme oikein.

Jos vähennät kognitiivista kuormitusta vain yhdeltä tiimiltä, vaikka voisit tehdä sen kaikille, koska ratkaistavana on suurempiakin asioita, kannattaa aina työskennellä kaikkia hyödyttävien asioiden parissa. Tässäkin on kyse siitä, kuinka paljon kuormitusta tiimille voidaan asettaa.

Dan: Kognitiivisen kuormituksen teoriassa kuormitusta on eri lajeja. Sisäinen kognitiivinen kuormitus syntyy siitä, että käsillä oleva tehtävä on itsessään monimutkainen. Mutta vältettävä kuormitus on ulkoinen kognitiivinen kuormitus: jotain, mikä vain sysätään vastuullesi etkä välitä siitä lainkaan, kuten tylsä rutiinityö.

Ehkä vastaus on, että jos keksit pyörää uudelleen kerta toisensa jälkeen ja ajattelet, että joku voisi ratkaista asian kaikkien hyödyksi, se voi olla merkki siitä, että kannattaisi pohtia useampien tiimien auttamista. Ei kuitenkaan ole olemassa tarkkaa lukua sille, milloin kannattaa investoida tiimiin, joka ratkaisee yhteisiä ongelmia.

Platform Engineering ja DevOps

Mario: Mikä yhteys tällä alustatyöllä on DevOpsiin? Kuinka monta tiimiä tarvitaan? Tai provosoivammin sanottuna: väittäisin jopa, että alustatiimi on DevOpsin vastainen toimintamalli.

Tuomas: Tässä on tavallaan kolme eri aluetta. Ensimmäinen on kehittäjät, jotka käyttävät ja operoivat rakentamaansa ratkaisua: heillä on hyvä havainnoitavuus, mahdollisuus palautuksiin ja hallinta niihin operatiivisiin osa-alueisiin, jotka ovat heille olennaisia. Sitten ovat alustatiimit, jotka kehittävät alustaa, määrittävät konfiguraatiot ja kuuntelevat kehittäjiä sekä kolmatta osapuolta, jonka mielestäni tulisi olla managed services.

Alustatiimi keskittyy siis kuuntelemaan kehittäjiä ja hyödyntämään konfiguraatiota parhaalla mahdollisella tavalla. Kehittäjillä puolestaan säilyy riittävä pääsy operointiin, runtime-ympäristöön ja kaikkeen muuhun, jotta he voivat operoida rakentamaansa ratkaisua.

Bjorn: Juuri tässä Platform Engineering tulee mukaan. On varmistettava, ettei kehittäjiltä viedä vastuuta pois, vaan että heille annetaan paremmat edellytykset onnistua.

Suurin ero DevOpsia edeltäneen toimintatavan ja nykyisen Platform Engineeringin välillä on ajattelutavassa: luomme houkuttelevia sisäisiä tuotteita ja ymmärrämme, että olemme täällä palvellaksemme kehittäjiä.

Dan: Jos katsot kirjaa Team Topologies – se on todella hyvä kirja, jos et ole vielä lukenut sitä – siinä käsitellään tiimien välisiä vuorovaikutussuhteita. Alustatiimin tulisi tarjota alusta palveluna tai tuotteena. Yhteistyö on kuitenkin kaikkein kiinnostavin osa. Miten selvitämme, mitä teemme nyt ja mitä seuraavaksi?

Kehittäjäportaalin rooli

Mario: Olemme puhuneet siitä, että IDP:illä eli alustoilla on yksi yhteinen sisäänkäynti kehittäjille useimpien ohjelmistokehityksen elinkaareen liittyvien asioiden hoitamiseen. Yksi näistä on kehittäjäportaali. Kun tarkastelemme IDP-kontekstia, näemme Backstagen olevan de facto -ratkaisu. Onko Backstage kaiken kattava ratkaisu alustan eri sidosryhmien käyttöön? Miten sinä näet asian?

Bjorn: Kävimme sisäisesti keskusteluja siitä, että tarvitsimme paikan, johon ihmiset voivat mennä ja saada yhdestä näkymästä pääsyn kaikkeen muuhun tietoon. Päätimme siis varhain ottaa Backstagen käyttöön, jotta voisimme tehdä siitä keskeisen tietopisteen. Se ei kuitenkaan tarkoita, että se olisi alustan ydin. Se on pikemminkin sisäänkäynti.

Backstage auttaa meitä luomaan paikan, johon voi mennä ja aloittaa haun. Jos et löydä vastausta, voit siirtyä Slackiin ja kysyä tiimiltä. Alustaan liittyy kuitenkin paljon asioita, jotka eivät ole Backstagea, kuten CLI-työkalut. Kaikki tämä on edelleen hajallaan, mutta löydät siitä tietoa Backstagesta.

Tuomas: Mielestäni Backstage on erinomainen tapa aloittaa matka kohti yhtä yhteistä näkymää. Edetessäsi saatat kuitenkin huomata, että ytimenä toimii ehkä Continuous Delivery -alusta, koska sen kautta kaikki näkevät, miten tuotamme arvoa asiakkaalle. Siitä voi tulla ydin, vaikka aluksi ajattelit aloittaa templateista.

Dan: Kun tutustuin Backstageen ensimmäisen kerran, ihastuin siihen heti, koska se näytti ratkaisevan monia ohjelmistokatalogiin ja omistajuuteen liittyviä ongelmia. Siinä oli myös eräänlainen järjestelmämalli, mikä on mielestäni todella hienoa. Lisäksi siinä ovat tietysti templating-ominaisuudet, pluginit ja niin edelleen.

Bjorn: Ymmärsimme selvästi, että uusien palveluiden luominen aiheuttaa kehittäjille eniten hankaluuksia. Meillä oli Confluencessa dokumentti: jos tarvitset nämä paikat, klikkaa nämä ruudut, muista asettaa tämä nimi oikein ja niin edelleen. Olimme varmoja, että tästä tulisi se asia, jota kaikki kehittäjät rakastavat.

Kysyimme Slackissa: ”Mitä haluatte meidän rakentavan ensin?” Ohjelmistokatalogi sai eniten peukkuja ylöspäin – selvästi enemmän kuin seuraavaksi suosituin vaihtoehto. Kyse on siitä, mitä monet kehittäjät todella haluavat: omistajuudesta. Mitä meillä on? Keneltä voin kysyä? Halusimme vain ratkaista tämän yksinkertaisen asian.

Alustan hyötyjen mittaaminen

Mario: Kun alusta on käytössä ja kestävällä pohjalla, herää seuraava kysymys: miten Platform Engineeringin tulokset yhdistetään liiketoiminnan tuloksiin? Riittääkö se, vai onko mahdollista käyttää jonkinlaisia mittareita? Ovatko DORA-mittarit hyödyllisiä myös tässä yhteydessä? Miten voidaan todeta, onko alustatyö tuonut liiketoiminnalle arvoa vai ei?

Dan: Jos meitä alustatiiminä mitataan sen perusteella, miten mahdollistamme muiden tiimien työn, mittarit kuten läpimeno, vakaus ja luotettavuus ovat meille todella tärkeitä. Ehkä meidän pitäisi myös keskittyä siihen, miten voimme yhdistää ne sovelluksiin, jotka kehittäjämme tuovat käyttäjiensä käyttöön.

Suorituskyky, viestintä ja yhteistyö sekä virtauksen tehokkuus. DORA kattaa ehkä osan tehokkuuteen liittyvistä asioista. Kyse ei kuitenkaan ole vain konkreettisista määristä, vaan myös laadullisista ja koetuista asioista.

Bjorn: Alustan tuottama liiketoiminta-arvo pitäisi toivottavasti tunnistaa niiden ongelmien kautta, joita alustan on ratkaistava. Mielestäni on vaikeaa löytää KPI-mittareita, jotka kuukausittain vahvistaisivat, onko alustatiimi edelleen järkevä.

Tuomas: DORA-mittarit ovat yksi vaihtoehto. En kuitenkaan ole nähnyt niitä käytettävän käytännössä kovin paljon. Mielestäni viides mittari, jota on harkittu, on luotettavuus, joka liittyy tavallaan käyttäjälle näkyvään toimintaan: SLI:t, SLO:t ja runtime-osuus. Runtimen käyttökokemus ja toiminnallisuus.

Sopiiko Platform Engineering kaikille?

Mario: Gartner sanoo nyt, että IDP:t ovat välttämättömiä DevOps-panostusten skaalaamiseksi. Miten näet Platform Engineeringin DevOps-kypsyysmallin yhteydessä? Onko se vain huippusuoriutujille vai pitäisikö sen olla kaikkien yritysten käytössä? Miltä tilanne näyttää esimerkiksi viiden vuoden kuluttua? Onko meillä edelleen alusta vai jotain muuta? Onko DevOps edelleen olemassa vai ei?

Tuomas: Skaalaamisen kannalta on aivan ratkaisevaa, että voimme abstrahoida joitakin asioita pois. Silloin voimme todella keskittyä liiketoiminnan tuloksiin. Miten muutamme loppukäyttäjän elämää?

Olen mielestäni hyvin onnekas, sillä työskentelen toimistossa, jossa on paljon suunnittelijoita. Syömme lounasta ja juomme kahvia yhdessä. Olen oppinut paljon design thinkingistä ja palvelumuotoilun menetelmistä, jotka ovat auttaneet minua tunnistamaan yrityksen tai organisaation mahdollisia ongelmia.

Bjorn: Uskon, että ainakin jotain tulee olemaan, koska taustalla olevat ongelmat eivät katoa. Ne voivat kuitenkin näyttäytyä erilaisina abstraktioina.

Tarkastelemme jatkossakin seuraavaa suurta ratkaistavaa ongelmaa, emme seuraavaa ratkaisua tai trendiä. Sen jälkeen voimme tarkastella ratkaisuvaihtoehtoja: ”Mitä täällä on, mikä voisi auttaa meitä ratkaisemaan tämän ongelman? Onko se alustatiimi? Onko se sen sijaan tuotemainen ajattelutapa vai työkalu? Onko se jokin muu asia?” Kaikkea tätä. Meidän on kuitenkin ensin tunnistettava seuraava ongelma.

Dan: Kuinka paljon käytät aikaa ongelmien selvittämiseen, ja miten teette yhteistyötä muuttaaksenne ne konkreettisiksi ratkaisuiksi? Se on minusta kiinnostavaa.

Yhteenveto

Paneelissa käytiin erittäin kiinnostava keskustelu, jossa nousi esiin monia DevOpsiin ja Platform Engineeringiin liittyviä teemoja. Kävi selväksi, että alusta ei ole vain teknologiaa, vaan pyrkimys palvella kehittäjiä ja sujuvoittaa prosesseja.

Platform Engineeringillä tulee olla selkeät tavoitteet, sen tulee keskittyä Developer Experienceen ja edistää tiimien välistä yhteistyökulttuuria.

Jokainen yritys on erilainen, joten Platform Engineeringin tulee kohdistua ongelmakohtiin ja kerätä jatkuvaa palautetta useilta sidosryhmiltä – ei vain kehittäjiltä, vaan myös tuote- ja liiketoimintavastaavilta.