Moderni Platform Engineering tekoälyvetoisen ohjelmistokehityksen aikakaudella

Tässä ensimmäisessä osassa tarkastelemme, miten Platform Engineering on kehittynyt tutuista DevOps-käytännöistä ja mitä se tarkoittaa suunnittelun, toteutuksen ja ajattelutavan kannalta. Nostamme esiin myös keskeiset trendit ja ajurit, որոնք muovaavat nykyistä Platform Engineering -kenttää.

Platform Engineeringin kehitys: keskeiset trendit ja ajurit

Voidaanko Platform Engineering modernisoida?

Laajamittaisen tietojenkäsittelyn alkuajoista lähtien kehityksen vauhti on vain kiihtynyt, eikä viime vuosina ole ollut poikkeusta. Yritykset kohtaavat nykyään kovempaa kilpailua, mikä lisää organisaatioiden painetta onnistua. Kun aikaa vapautuu ydinosaamiseen ja luovaan ajatteluun, Platform Engineering voi olla avain organisaatiosi menestykseen.

Mahdollisuus valita itselle sopivat työkalut on ollut jo vuosien ajan keskeinen keino pitää kehittäjät tyytyväisinä ja keskittyneinä. Tiimien tai työryhmien koostamisen joustavuus vähentää kehittäjien kognitiivista kuormaa, kun heitä perehdytetään mahdollisesti uuteen liiketoiminta-alueeseen. Erittäin kokeilevan vaiheen jälkeen työkalut ja käytännöt ovat pitkälti vakiintuneet, mutta yksittäisille tiimeille jää silti riittävästi tilaa mukauttaa niitä omiin tarpeisiinsa.

Tarkemmin tarkasteltuna: DevOpsin ja Platform Engineeringin muuttuva kenttä

Kun katsomme toimialamme suuria muutoksia taaksepäin, näemme, että kehityksen ja operoinnin tuominen lähemmäs toisiaan DevOps-käytäntöjen avulla on usein nopeuttanut markkinoillepääsyä. Sillä voi kuitenkin olla hintansa, kuten olemme vuosien varrella nähneet. Hinta ei aina ole rahallinen, vaan se näkyy usein kehittäjien kognitiivisena kuormituksena. Uudella työskentelyalueella nopeus, kognitiivinen kapasiteetti ja ketteryys luonnollisesti heikkenevät, kun uutta tietoa pitää omaksua ja käsitellä.

Vaikka ”You build it, you run it” on tärkeä periaate tiimien omistajuuden ja sitä kautta toiminnan kiireellisyyden kannalta, monet kehittäjät joutuivat opettelemaan operointikäytäntöjä, joista heillä ei ollut aiempaa kokemusta. Tarve syntyi siitä, ettei operointiosaamista ollut riittävästi vastaamaan sitä tarvitsevien tiimien määrän kasvuun. Siirtyminen pois perinteisen operointimallin tehtäväjonoista edellytti merkittävää ajattelutavan muutosta, johon kaikki organisaatiot eivät ole tarttuneet. Ajattelutavan muutos oli ja on edelleen avainasemassa, jotta ei palata siiloihin – ja joissain tapauksissa juoksuhautasotiin – jotka heikensivät organisaation kaikkien osien kilpailukykyä. DevOpsin kääntöpuolena kehittäjien on pitänyt kartuttaa osaamistaan pilviverkkojen perusteista, Kubernetesin konfiguroinnista ja sisällönjakeluverkoista. Näissä osa-alueissa onnistunut operointi, joustavuus ja kustannustehokkuus edellyttävät syvällistä asiantuntemusta.

Platform Engineeringistä on tullut johtava toimintamalli, jonka avulla kehittäjä voi keskittyä oman liiketoiminta-alueensa osaamiseen, hyvin arkkitehtuuriltaan suunnitellun koodin rakentamiseen ja luovaan vapauteen. Alustoja on rakennettu vähentämään kognitiivista kuormaa vastaamalla kehittäjien tarpeisiin ohjelmistojen kirjoittamisessa, buildauksessa, testaamisessa, käyttöönotossa ja operoinnissa. Tämä tarkoittaa, että yhtenäinen toimintatapa palauttaa osan vapaudesta. Se ei ole huono asia, kun Platform Engineeringin hyödyt tulevat esiin maailmassa, jossa myös hallinnon ja vaatimustenmukaisuuden vaatimukset kasvavat.

Mitkä ovat Platform Engineeringin modernisoinnin keskeiset ajurit?

Monet organisaatiot ovat siirtyneet pilveen, mutta samalla lähestymistapa on muuttunut Cloud Native -suuntaan. Tämä ei välttämättä tarkoita, että kaikki siirtyvät pilveen, vaikka monet ovatkin siirtyneet. Kyse on pikemminkin ajattelutavasta, jossa hyödynnetään teknologioita, jotka ovat olleet keskeisiä rakennuspalikoita nykyisille pilvipalveluille. Tähän voi sisältyä useita ohjelmistokehityksen arkkitehtuurimalleja, mutta virtualisointi, kontitus ja Kubernetes ovat epäilemättä olleet Cloud Native -matkan keskeisiä tekijöitä. Pienempien, rajattuun tarkoitukseen suunniteltujen palvelujen rakentaminen helpottaa virheiden selvittämistä, skaalaamista ja ylläpitoa – ja on yksi menestyksen avaimista. Tämä eroaa suuresti ajasta, jolloin yhteen palveluun pakattiin mahdollisimman paljon ja palvelimen viimeisetkin CPU- ja muistiresurssit pyrittiin hyödyntämään.

Organisaatioissamme käytetään nyt satoja, tuhansia tai jopa enemmän palveluja, ja luotamme alustaan, joka sijoittaa nämä palvelut tehokkaasti fyysisille palvelimille ja auttaa saamaan rahallisista investoinneista kaiken hyödyn irti.

Omaksumalla Platform Engineering -matkan voimme alkaa optimoida käytettävissämme olevien resurssien käyttöä, olivatpa ne omissa tiloissamme sijaitsevia palvelimia tai valitsemaltasi pilvipalveluntarjoajalta käyttöön otettuja klustereita. Ilman Platform Engineeringin omaksumista järjestelmiä voidaan toki käyttää, mutta niiden kannattava operointi edellyttää erikoisosaamista. Muuten rahat kuluvat helposti lukuisiin erillisiin klustereihin ja tukipalvelujen päällekkäiseen toteuttamiseen.

Analysoimalla alustojen datavirtoja voimme tehdä harkittuja toimenpiteitä, joilla parannamme ja laajennamme alustaa käyttävien ohjelmistokehittäjien käytettävissä olevia kyvykkyyksiä. Tämä on keskeinen perusta, joka on saanut viime vuosina yhä enemmän huomiota. Yhä useammat organisaatiot ovat ymmärtäneet, että alusta rakennetaan kehittäjiä varten ja sen tulee tukea heidän tarpeitaan. Olemme siirtymässä yhä enemmän siihen suuntaan, että alustoja johdetaan tuotteina. Emme kuitenkaan ole vielä perillä, sillä monet lähestyvät Platform Engineeringiä teknisenä haasteena, vaikka kyse on kokonaisuudessaan sosio-teknisestä harjoituksesta. Käyttäjäpalautteen kerääminen sekä määrällisin että laadullisin keinoin on tärkeää, jotta rakennamme oikeita asioita, niitä käytetään ja käyttäjät kokevat alustan kanssa työskentelyn mielekkääksi.

Viimeisenä mutta ei vähäisimpänä alalla on nähty kasvavaa kysyntää tekoälytyökuormien ajamiselle alustoilla. Tämä on herättänyt paljon keskustelua niin meidän alustoja rakentavien ja tietoturva-ammattilaisten keskuudessa kuin suurissa laitteistoyrityksissä, kuten NVIDIAssa. Miten rakennamme alustan, joka hyödyntää laitteiston potentiaalia ja toimii tavalla, joka sopii jaetun hostingin Cloud Native -lähestymistapaan?

Alkuvaiheessa laitteisto konfiguroitiin suoraan yksittäisiä työkuormia varten, mutta nyt siirrytään yhä enemmän malliin, jossa laitteisto jaetaan useiden työkuormien kesken. Tämä on ollut mahdollista jo jonkin aikaa, mutta alalle on nyt syntymässä standardeja, jotka tukevat pitkäjänteistä toimintaa.