Yritysten cloudin nykytila on laajan käyttöönoton ja epätasaisen tuoton tila. Lähes jokainen mittavan kokoluokan organisaatio ajaa nykyään tuotantokuormia yhdellä tai useammalla hyperskaalaajalla, ja moni on julistautunut linjauksissaan cloud-first-organisaatioksi. Paljon harvinaisempaa on cloud, joka käyttäytyy eri tavalla kuin sitä edeltänyt konesali. Infrastruktuuri on periaatteessa joustava mutta käytännössä staattinen: kertaalleen käsin provisioitu ja käyntiin jätetty, mitoitettu huipulle joka harvoin toteutuu, ja muutettu samojen hyväksyntäketjujen kautta jotka ohjasivat fyysisiä palvelimia. Lasku kasvaa, ketteryys ei.

Tällä on nyt merkitystä syistä, jotka ovat kaupallisia eivätkä teknisiä. Cloud-menoista on tullut yksi IT-budjetin suuremmista hallittavista kululajeista, niin suuri että talousfunktiot ovat alkaneet tarkastella sitä samalla tavalla kuin henkilöstömäärää. Samaan aikaan ensimmäiset migraatioaallot ovat kypsyneet, ja varhain liikkeelle lähteneet organisaatiot huomaavat, että lift-and-shift kerää tietynlaista velkaa: kuormia jotka eivät ole halvempia eivätkä kestävämpiä ja jotka vastustavat lisämuutoksia, koska kukaan ei pysty turvallisesti päättelemään miten ne rakennettiin. Helpot migraatiot on tehty. Jäljellä on vaativampi työ: hyvin operoiminen.

Mukana on myös osaamisen ulottuvuus. Cloud palkitsee organisaatiot jotka osaavat ilmaista infrastruktuurin ohjelmistona ja rankaisee niitä jotka eivät osaa, koska alustat olettavat automaation normaaliksi poluksi ja kohtelevat manuaalista konsolia varajärjestelmänä. Organisaatio joka provisioi klikkailemalla portaalin läpi käyttää supertietokonetta arkistokaappina. Kuilu niiden yritysten välillä jotka ovat sisäistäneet toimintamallin ja niiden jotka ovat vain vuokranneet kapasiteettia leveenee, ja se näkyy julkaisutaajuudessa, häiriöiden palautumisajoissa ja kaikkein näkyvimmin kuukausittaisessa laskussa. Cloudin ymmärtäminen toimintamalliksi, johdonmukaiseksi joukoksi käytäntöjä siitä miten infrastruktuuria pyydetään ja hallitaan, on kaiken seuraavan edellytys.

Toimintamalli vastaa pieneen joukkoon kestäviä kysymyksiä. Kuka saa luoda infrastruktuuria ja millaisten rajojen sisällä. Miten muutosta tuohon infrastruktuuriin ehdotetaan, arvioidaan ja otetaan käyttöön. Missä kirjaus siitä mitä on olemassa oikeasti sijaitsee. Kuka maksaa ja miten tuo kustannus tehdään näkyväksi niille jotka sen aiheuttavat. Perinteisessä ympäristössä näihin kysymyksiin vastataan menettelyillä ja itse laitteiston niukkuudella. Cloudissa niihin on vastattava eksplisiittisesti, koska muuten alusta antaa kenen tahansa tunnukset omaavan luoda lähes mitä tahansa, välittömästi ja kustannuksella.

Ensimmäinen periaate on, että infrastruktuuri kuvataan, ei koota. Järjestelmän tavoitetila, sen verkot, identiteetit, laskenta ja käytännöt, ilmaistaan koodina repositoriossa, ja ympäristö johdetaan tuosta kuvauksesta. Tämä kääntää ympäri vanhan suhteen, jossa käynnissä oleva järjestelmä oli totuuden lähde ja dokumentaatio oli jäljessä laahaava likiarvo. Kun kuvaus on määräävä, ympäristöstä tulee toistettava, arvioitava ja hävitettävä, kolme ominaisuutta joita manuaalinen provisiointi ei tarjoa mihinkään hintaan.

Toinen periaate on, että valtuudet delegoidaan suojarajojen (guardrails) kautta eikä portteina. Sen sijaan että keskitetty tiimi hyväksyisi jokaisen pyynnön, alusta määrittelee mikä on sallittua käytännöillä, ja tiimit toimivat vapaasti näiden rajojen sisällä. Itsepalvelu suojatussa tilassa skaalautuu tavalla jota ihmisen hyväksyntä ei koskaan kykene. Kolmas periaate on, että kustannus on ensiluokkainen tekninen signaali, samalla tasolla kuin latenssi tai virhetaso, koska cloudissa järjestelmän suunnittelu ja sen ajamisen hinta ovat sama päätös kahdesti ilmaistuna. Tiimi joka ei näe mitä sen valinnat maksavat optimoi jotain muuta.

Neljäs periaate on, että vastuu on hajautettu mutta standardit ovat yhteiset. Sovellustiimit omistavat kuormansa ja menonsa; alustafunktio omistaa valmiiksi viitoitetut polut, landing zonet ja suojarajat jotka tekevät omistajuudesta turvallista. Tässä on mallin ydin: ei keskittäminen, joka kuristaa toimituksen, eikä täysi vapaus, joka tuottaa hallitsematonta leviämistä, vaan pieni joukko vahvoja käytäntöjä joiden päälle monet tiimit rakentavat. Kun nämä periaatteet ovat kohdallaan, yksittäiset teknologiat muuttuvat vaihtokelpoisiksi. Kun ne menevät pieleen, mikään työkalu ei korvaa sitä.

Useat kehityskulut ovat yhdistyneet tehdäkseen toimintamallista konkreettisemman kuin se oli vielä muutama vuosi sitten. Merkittävin on alustainsinöörityön (platform engineering) vakiintuminen omaksi tieteenalakseen. Sen sijaan että jokainen sovellustiimi opettelisi cloudin peruspalikoiden koko syvyyden, alustatiimi kuratoi valmiiksi viitoitettuja polkuja: kantaaottavia, itsepalveluna toimivia malleja jotka koodaavat organisaation turvallisuus-, verkko- ja kustannuskäytännöt, niin että kehittäjä pyytää vaatimustenmukaisen ympäristön sen sijaan että kokoaisi sellaisen. Tämä vähentää kognitiivista kuormaa ja, mikä tärkeämpää, tekee hyvästä käytännöstä pienimmän vastuksen polun.

Käytäntö koodina (policy as code) on kypsynyt rinnalla. Suojarajat jotka aiemmin kirjoitettiin hallintodokumentteihin ilmaistaan nyt konevalvottuina sääntöinä jotka ajetaan provisiointiputkessa, hyläten muutos joka avaisi verkon julkiseen internetiin tai kohdistuisi hyväksymättömälle alueelle jo ennen kuin se ehtii tilille asti. Tämä siirtää hallintaa vasemmalle: tarkastuksesta joka havaitsee rikkomukset jälkikäteen kontrolliin joka estää ne muutoshetkellä. FinOps on kulkenut samaa polkua siirtyen talouden omistamasta kuukausittaisesta täsmäytysharjoituksesta jatkuvaksi tekniseksi käytännöksi, jossa kustannuspoikkeamista hälytetään, showback ja chargeback ovat automatisoituja, ja mitoituksen oikaisu on rutiininomainen osa toimintaa eikä vuosittainen siivousrupeama.

Multicloud on asettunut rehellisempään asentoon. Kunnianhimo kuormista jotka kelluvat vapaasti palveluntarjoajien välillä on suurelta osin väistynyt pragmaattisen mallin tieltä: vakioidaan toimintamalli ja työkalut palveluntarjoajien yli, mutta sijoitetaan kukin kuorma sinne missä se toimii parhaiten, ja hyväksytään tietty palveluntarjoajakohtaisuus vastineeksi kunkin alustan natiivien vahvuuksien hyödyntämisestä. Tämän rinnalla infrastruktuurityökalut ovat laajentuneet yhden deklaratiivisen kielen yli, ja orkestraattoreita, konfiguraatiojärjestelmiä ja yleiskäyttöistä ohjelmointia käytetään yhä useammin yhdessä. Aivan viime aikoina tekoälyavusteinen operointi on alkanut ilmaantua työkaluketjuun, luonnostellen infrastruktuurikoodia, tiivistäen ajautumaa ja ehdottaen mitoituksen oikaisuja, joskin nämä pysyvät avustajina jotka vaativat saman arviointikurin kuin mikä tahansa muu muutos. Kulkusuunta on johdonmukainen: yhä suurempi osa toimintamallista koodataan, valvotaan ja automatisoidaan, ja yhä pienempi osa jää yksittäisen harkinnan varaan.

Landing zone on toimintamallin arkkitehtoninen ilmaus: valmiiksi rakennettu, hallittu perusta johon kuormat sijoitetaan. Se määrittää tili- tai tilausrakenteen, identiteettimallin, verkkotopologian, lokituksen ja valvonnan perustason sekä käytäntöjoukon, niin että mikä tahansa siihen laskeutuva kuorma perii tunnetusti hyvän asennon eikä keksi sitä uudelleen. Yksittäinen tärkein suunnittelupäätös landing zonessa on tiliraja, koska tilit ovat vahvin eristys ja vaikutusalueen hallinta jonka cloud tarjoaa. Ympäristöjen ja usein erillisten sovellusten erottaminen omiin tileihinsä rajaa väärän konfiguraation tai vaarantuneen tunnuksen ulottuvuutta tavalla jota mikään tilinsisäinen oikeuksien hallinta ei vastaa.

Infrastruktuuri koodina on mekanismi joka tekee landing zoneista ja kuormista toistettavia. Ratkaiseva kuri ei ole pelkkä koodin kirjoittaminen vaan sen kohteleminen ohjelmistona: versionhallinta, vertaisarviointi, suunnitelman automatisoitu testaus ennen käyttöönottoa ja siisti erottelu uudelleenkäytettäviä malleja määrittävien moduulien ja ne tiettyyn ympäristöön instantioivien kompositioiden välillä. Tila (state), kirjaus siitä mitä koodi on tosiasiassa rakentanut, on säilytettävä keskitetysti, lukittava yhtäaikaista muutosta vastaan ja suojattava yhtä huolellisesti kuin tietokanta, koska turmeltunut tai eriytynyt tilatiedosto on yksi cloud-operoinnin tuskaisimmista palautumistilanteista.

Provisiointi kuvaa ympäristön; orkestrointi koordinoi muutosta monen ympäristön yli ajan mittaan. Suunnitteluperiaate joka tekee orkestroinnista turvallista on muuttumattomuus (immutability): sen sijaan että käynnissä olevaa resurssia muokattaisiin paikallaan, kuvauksesta rakennetaan uusi versio ja vanha korvataan, niin että jokainen ympäristö on tuore johdanne koodista eikä kertymä dokumentoimattomia muokkauksia. Tämä eliminoi konfiguraation ajautuman, hitaan eroaman sen välillä mitä koodi sanoo ja mitä oikeasti ajetaan, joka on toistettavuuden hiljainen tappaja. Putket ottavat muutokset käyttöön saman arvioidun, automatisoidun polun kautta jokaisessa ympäristössä, niin että tuotanto saavutetaan edistämällä identtinen muutos vaiheistuksen läpi eikä erillisellä manuaalisella teolla. Yhdistävä periaate kaiken tämän läpi on, että ihmisen tulisi ilmaista tahto ja koneen toteuttaa se, johdonmukaisesti, toistettavasti ja ilman improvisaatiota jonka manuaalinen provisiointi houkuttelee esiin.

Epäonnistumisen tavat ovat tunnistettavissa organisaatioiden ja toimialojen yli, ja useimmat niistä palautuvat konesalitottumusten tuomiseen ympäristöön joka rankaisee niistä.

Lift-and-shift joka kantaa velan mukanaan. Virtuaalikoneiden siirtäminen sellaisinaan, harkitsematta uudelleen miten ne on rakennettu tai mitoitettu, siirtää jokaisen olemassa olevan ongelman ja lisää uuden: mitatun laskun joutokapasiteetista joka aiemmin oli uponnut kustannus. Kuorma on nyt kalliimpi eikä yhtään kyvykkäämpi, ja koska mitään ei ilmaistu koodina, se on yhtä läpinäkymätön kuin ennen. Lumihiutaleympäristöt ja konfiguraation ajautuma. Kun infrastruktuuria muutetaan käsin konsolissa, ympäristöt eriytyvät hiljaa, vaiheistus lakkaa muistuttamasta tuotantoa, ja häiriöistä tulee toistamattomia koska kukaan ei pysty rakentamaan uudelleen sitä tarkkaa tilaa jossa ne tapahtuivat.

Kustannus havaittu eikä suunniteltu. Kun menoja tarkastellaan vain kuukausittaisessa laskussa, organisaatio reagoi aina viikkoja aiemmin tehtyihin päätöksiin. Merkitsemättömät resurssit tekevät kohdistamisesta mahdotonta, orvot levyt ja joutilaat instanssit kertyvät, ja vastaus muuttuu ajoittaiseksi hätäkarsinnaksi jatkuvan kurin sijaan. Hallinta portilla. Heikkojen suojarajojen kompensoiminen raskaalla manuaalisella hyväksynnällä hidastaa toimitusta siihen pisteeseen että tiimit kiertävät sen provisioimalla varjoinfrastruktuuria hallitun polun ulkopuolelle, mikä tuottaa juuri sen leviämisen jonka portin oli tarkoitus estää. Ylioikeutetut identiteetit. Mukavuuden vuoksi myönnetyt laajat, pysyvät tunnukset muuttavat yksittäisen vaarantumisen koko IT-ympäristön laajuiseksi häiriöksi; pienimmän oikeuden periaate on työlästä toteuttaa ja kallista jättää tekemättä.

Työkalut ilman toimintamallia. Infrastruktuuri koodina -teknologian käyttöönotto samalla kun organisaation päätösvalta, omistajuus ja standardit jätetään ennalleen tuottaa koodia joka automatisoi väärän prosessin nopeammin. Työkalu on välttämätön mutta ei koskaan riittävä. Useimpien näiden taustalla on yksi virhe: cloudin kohteleminen kapasiteetin hankintana eikä muutoksena siinä miten infrastruktuuria operoidaan. Kamppailevilta organisaatioilta harvoin puuttuu osaamista tai budjettia; niiltä puuttuu johdonmukainen malli, ja alusta vahvistaa uskollisesti minkä tahansa mallin, tai sen puutteen, joka sille annetaan.

Nashua aloittaa toimintamallista eikä migraatiosta, koska kuormien siirtäminen ennen kuin malli on vakiintunut vain siirtää olemassa olevan epäjärjestyksen. Ensimmäinen toimeksianto on arvio IT-ympäristöstä sellaisena kuin se oikeasti toimii: mitä kuormia on olemassa, miten ne ovat kytkeytyneet, mitä ne maksavat, miten niitä muutetaan tänään ja missä todelliset rajoitteet sijaitsevat. Tämä tuottaa suoran kartan siitä mitä pitäisi modernisoida, mitä voidaan siirtää uudelle alustalle kohtuullisella vaivalla, mikä aidosti ansaitsee suoraviivaisen migraation ja mikä pitäisi poistaa käytöstä eikä siirtää lainkaan. Tavoitteena on todistusaineistoon perustuva portfoliopäätös eikä yleisohje siirtää kaikki.

Sieltä Nashua suunnittelee ja rakentaa landing zonen kestäväksi perustaksi: tilirakenteen, identiteettimallin, verkkotopologian, lokituksen ja käytäntöjen perustason, ilmaistuna koodina alusta alkaen niin että perusta itsessään on toistettava ja arvioitava. Suojarajat toteutetaan käytäntönä joka ajetaan provisiointiputkessa, niin että hallinta valvotaan automaattisesti muutoshetkellä eikä tarkasteta jälkikäteen. Kuormat tuodaan sitten valmiiksi viitoitetuille poluille, itsepalveluna toimiville malleille jotka kantavat organisaation turvallisuus- ja kustannuskäytännöt, niin että tiimit provisioivat vaatimustenmukaista infrastruktuuria ilman että niiden tarvitsee hallita jokaista peruspalikkaa.

Kustannuskuri on rakennettu sisään eikä lisätty myöhemmin. Merkintästandardit, showback, poikkeamahälytykset ja rutiininomainen mitoituksen oikaisu vakiinnutetaan osaksi alustaa, niin että menot ovat näkyviä niille tiimeille jotka ne aiheuttavat ja niitä kohdellaan teknisenä signaalina ensimmäisestä päivästä. Kauttaaltaan Nashua pyrkii siirtämään kyvykkyyttä eikä luomaan riippuvuutta: koodi, käytännöt ja operatiiviset toimintaohjeet ovat asiakkaan, ja Nashuan insinöörit työskentelevät sisäisten tiimien rinnalla niin että toimintamallista tulee jotain jonka organisaatio omistaa ja voi laajentaa. Jos asiakas haluaa Nashuan operoivan alustaa jatkuvasti, se tehdään saman läpinäkyvän, koodatun ja hallitun mallin sisällä jonka se luovuttaisikin, niin että hallinnoitu operointi ja itse operointi ovat sama kuri eri miehityksellä.

Nashuan tuoma ero on kieltäytyminen kohtelemasta cloudia sijaintipaikkana. Monet palveluntarjoajat osaavat suorittaa migraation; paljon harvempi vaatii että toimintamalli vakiinnutetaan ensin, että suojarajat koodataan ennen kuin kuormat saapuvat ja että kustannus suunnitellaan eikä havaita. Nashuan asiantuntijat ovat operoineet riittävän monta ympäristöä niiden koko elinkaaren läpi, ensimmäisestä landing zonesta kiusallisiin toiseen ja kolmanteen vuoteen jolloin ajautuma, leviäminen ja kustannuspaine yleensä nousevat pintaan, suunnitellakseen noita vuosia varten alusta alkaen. Tuo pitkä katse erottaa cloudin joka kartuttaa arvoa siitä joka hiljaa muuttuu kalliiksi konesaliksi jonka sen oli tarkoitus korvata.

Mukana on myös käytännöllinen seuraus joka muuttaa sen mitä työ saa olettaa. Kun toimeksianto vaatii kyvykkyyttä jota ei vielä ole olemassa, sen ei tarvitse odottaa hankintasykliä tai toimittajan tiekarttaa. enterprise platform on rakennettu mukautumaan lähes mihin tahansa ominaisuuteen vauhdilla, agenttipohjaisen insinöörityön kautta: tarvittava kuvataan selkokielellä ja generoidaan nopeasti, mutta aina lujien arkkitehtuuriperiaatteiden puitteissa ja tiukan laadunvarmistuksen alaisena, niin että nopeus ei koskaan tule johdonmukaisuuden, turvallisuuden tai hallinnan kustannuksella. Vaikutus on strateginen eikä pelkästään kätevä. Se siirtää tee vai osta -rajaa, pitää optionaalisuuden edullisena ja antaa arkkitehtuurin seurata strategiaa eikä strategian taipua sen mukaan mitä sattui olemaan hyllyllä.

Se mitä asiakkaat säilyttävät toimeksiannon jälkeen ei ole riippuvuus vaan kyvykkyys: landing zone jonka he ymmärtävät koska se on ilmaistu koodina jota he voivat lukea, suojarajat jotka valvovat heidän omia standardejaan, provisiointipolku jota heidän tiiminsä voivat käyttää ilman eskalointia ja kustannusmalli joka tekee jokaisen valinnan näkyväksi siinä valuutassa joka sitä ohjaa. Nashua mittaa omaa menestystään sillä, pystyykö organisaatio toimimaan harkitusti ilman sitä, ja sillä, pysyykö IT-ympäristö johdonmukaisena sen kasvun alla joka paljastaa jokaisen oikotien. Cloudissa toimiminen tarkoituksella, tahto ilmaistuna koodina ja koneiden toteuttamana organisaation valitsemien rajojen sisällä, on koko tämän kurin ydin. Se on standardi jonka mukaan Nashua rakentaa, ja se ero jonka tekemiseen se palkataan.