Jokainen sovellus, tietokanta, analytiikkaputki ja liiketoimintajärjestelmä, jota organisaatio käyttää, palautuu viime kädessä kolmeen fyysiseen resurssiin: laskentakapasiteettiin, tallennuskapasiteettiin ja verkon kaistanleveyteen. Infrastruktuuri on sitä tieteenalaa, jossa näitä resursseja tarjotaan, järjestetään ja käytetään niin, että niiden yläpuolella olevat kerrokset voivat toimia ikään kuin laitteisto olisi abstrakti ja ehtymätön hyödyke. Syy siihen, miksi tällä on nyt enemmän merkitystä kuin vuosikymmen sitten, on se, että IT-ympäristöön kohdistuvat vaatimukset ovat kasvaneet sekä suuremmiksi että huomattavasti vähemmän ennustettaviksi. Tietomäärät kasvavat nopeammin kuin budjetit, työkuormat piikkaavat tavoilla, joita eräajojen aikakauden suunnittelun ei koskaan tarvinnut ottaa huomioon, ja koneoppimisen sekä päättelytyökuormien saapuminen on tuonut takaisin raskaan, pitkäkestoisen resurssipaineen ympäristöihin, jotka olivat vuosia optimoineet kevyttä, transaktionaalista liikennettä varten.

Samaan aikaan itse IT-ympäristö on pirstaloitunut. Hyvin harva organisaatio käyttää yhtä ainoaa, yhtenäistä ympäristöä. Tyypillinen kuva on virtualisoitu paikallinen ydin, yksi tai useampi julkisen pilven vuokralaisuus, kourallinen software-as-a-service -riippuvuuksia ja usein jotakin vanhaa fyysistä laitteistoa, joka vastustaa konsolidointia lisensoinnin, viiveen tai sääntelyn vuoksi. Kullakin näistä on oma toimintamallinsa, omat vikaantumisominaisuutensa ja oma kustannusrakenteensa. Käytännön seuraus on, että infrastruktuurissa ei ole enää kyse konesalin pyörittämisestä; kyse on yhtenäisen ympäristön pyörittämisestä useiden omistus- ja hallintarajojen yli sekä tuon IT-ympäristön saamisesta käyttäytymään yhtenä järjestelmänä sitä käyttävien ihmisten näkökulmasta.

Miksi tällä on nyt merkitystä, on suoraviivaista. Infrastruktuurin epäonnistumisen hinta on noussut samaa tahtia organisaation siihen kohdistuvan riippuvuuden kanssa. Vähittäiskaupan tai logistiikan yritys, jonka järjestelmät ovat poissa käytöstä iltapäivän ajan, ei menetä iltapäivän verran tuottavuutta; se menettää tilauksia, luottamusta ja yhä useammin myös sääntelyn mukaisen asemansa. Infrastruktuuri on siirtynyt tukitoiminnosta tekijäksi, joka määrittää, kykeneekö liiketoiminta ylipäätään toimimaan, ja juuri tämä panosten muutos oikeuttaa sen kohtelemisen aidolla insinöörin täsmällisyydellä.

Hypervisoreiden, klustereiden ja kudosten sanaston alla infrastruktuuri antaa neljä lupausta, ja kaikki muu on keino niiden pitämiseksi. Se lupaa kapasiteettia, mikä tarkoittaa, että resurssia on saatavilla, kun työtä tulee. Se lupaa käytettävyyttä, mikä tarkoittaa, että palvelu jatkuu yksittäisten komponenttien väistämättömästä vikaantumisesta huolimatta. Se lupaa suorituskykyä, mikä tarkoittaa, että työ valmistuu ennustettavassa ja hyväksyttävässä ajassa. Ja se lupaa eheyttä, mikä tarkoittaa, että data säilyy vahingoittumattomana vikaantumisten ja ajan yli. Suunnitelma, joka ei kykene ilmaisemaan, miten se pitää kunkin näistä lupauksista ja millä kustannuksella, ei ole suunnitelma; se on toive.

Virtualisointi on tekniikka, joka uudelleenmuotoili kaikki neljä lupausta. Asettamalla hypervisorin käyttöjärjestelmän ja fyysisen koneen väliin virtualisointi irrottaa työkuorman siitä laitteistosta, jolla se toimii. Virtuaalikoneesta tulee tiedosto, jota voidaan siirtää, kopioida, tilannevedostaa ja käynnistää uudelleen eri fyysisillä isäntäkoneilla. Juuri tämä irrottaminen tekee nykyaikaisesta kapasiteetista ja käytettävyydestä käytännöllisiä: työkuormat voidaan konsolidoida harvempiin, paremmin hyödynnettyihin fyysisiin isäntäkoneisiin, ja ne voidaan siirtää pois vikaantuvasta tai ylikuormittuneesta laitteistosta ilman uudelleenrakentamista. Fyysinen ympäristö lakkaa olemasta joukko yksittäisiä, korvaamattomia palvelimia ja muuttuu keskenään vaihdettavissa olevaksi kapasiteettivarannoksi.

Hyperkonvergenssi ottaa saman logiikan ja soveltaa sitä tallennukseen ja jossain määrin verkkoon. Sen sijaan, että ylläpidettäisiin erillistä tallennusjärjestelmää, joka on kytketty erillisen kudoksen yli, hyperkonvergoitu infrastruktuuri eli HCI yhdistää laskennan ja tallennuksen samoihin solmuihin ja esittää niiden yhdistetyt paikalliset levyt yhtenä, ohjelmistomääriteltynä ja vikasietoisena varantona. Vetovoima on toiminnallisessa yksinkertaisuudessa: IT-ympäristöstä tulee joukko yhtenäisiä solmuja, joita voidaan lisätä vähitellen, ja tallennuskerros perii saman ohjelmistomääritellyn hallinnan kuin laskentakerros. Perusperiaatteiden näkökulma on, että virtualisointi ja hyperkonvergenssi eivät muuta sitä, mitä infrastruktuuri lupaa. Ne muuttavat sen rakeisuutta ja taloudellisuutta, miten nämä lupaukset pidetään, korvaten jäykät, yksitellen suunnitellut järjestelmät varannoitetulla, ohjelmistomääritellyllä kapasiteetilla, jota voidaan tarkastella kokonaisuutena.

Kolme virtausta muokkaa infrastruktuurikäytäntöä samanaikaisesti, ja aidot muutokset kannattaa erottaa hälinästä. Ensimmäinen on ohjelmistomääritellyn kaiken kypsyminen. Laskennan virtualisointi on jo kauan ratkennut, mutta tallennus ja verkko ovat seuranneet perässä, niin että nykyaikainen ympäristö määritellään ja sitä käytetään yhä enemmän ohjelmistoabstraktioiden kautta pikemminkin kuin järjestelmien ja kytkimien fyysisen kaapeloinnin kautta. Juuri tämä tekee hyperkonvergenssista toimivan mittakaavassa ja sallii infrastruktuurin kuvaamisen, versioinnin ja uudelleenrakentamisen koodina käsityönä kokoamisen sijaan. Käytännön hyöty ei ole uutuudessa vaan toistettavuudessa: ohjelmistona määritelty IT-ympäristö voidaan testata, auditoida ja rakentaa uudelleen sellaisella varmuudella, jota käsin rakennetut ympäristöt eivät koskaan tarjonneet.

Toinen virtaus on pilven taloudellisuuden raittiimpi uudelleenarviointi. Viime vuosikymmenen migraatioaalto perusteltiin usein oletuksella, että julkinen pilvi on luonnostaan halvempi. Joustaville, piikkaaville ja ennakoimattomille työkuormille se usein on, koska maksat vain siitä, mitä kulutat, ja vältät kapasiteetin varaamisen huippua varten, joka harvoin toteutuu. Tasaisille, ennustettaville, korkean käyttöasteen työkuormille laskutoimitus menee usein toisin päin, ja useat organisaatiot ovat havainneet, että tällaisten työkuormien palauttaminen hyvin hoidetulle paikalliselle tai hyperkonvergoidulle alustalle vähentää kustannuksia merkittävästi. Kypsä kanta ei ole pilvi ensin eikä paikallinen ensin vaan työkuorma ensin: kunkin työkuorman sijoittaminen on taloudellinen ja tekninen päätös, joka tehdään näytön eikä muodin pohjalta.

Kolmas virtaus on paine, jonka dataintensiiviset ja tekoälyyn liittyvät työkuormat kohdistavat IT-ympäristöön. Päättely ja koulutus vaativat pitkäkestoista, usein kiihdytettyä laskentaa sekä korkean läpisyötön tallennusta ja matalan viiveen verkkoa. Tämä tuo takaisin luokan resurssinnälkäistä, viiveelle herkkää työtä, jonka absorboimiseen yleiskäyttöisiä työkuormia varten optimoituja virtualisoituja ympäristöjä ei ollut suunniteltu. Se ohjaa uudistunutta huomiota tallennuksen suorituskykyyn, verkkokudoksen suunnitteluun ja rehelliseen kysymykseen siitä, mihin tällaiset työkuormat kuuluvat, mikä datan painovoiman ja kustannusten vuoksi on usein lähempänä organisaation omaa dataa kuin naiivi kaikki pilveen -asenne antaisi ymmärtää.

Hyvä infrastruktuuri on suunniteltu tapahtumaköyhäksi, ja se on suunnittelutavoite, jolla on konkreettisia seurauksia eikä pelkkä iskulause. Ensimmäinen periaate on yksittäisten vikaantumispisteiden poistaminen. Jokaisen merkittävän kerroksen, sähkönsyötön, verkkopolun, tallennuskopion ja laskentaisännän, tulisi kyetä menettämään komponentti menettämättä palvelua. Virtualisoidussa klusterissa tämä tarkoittaa mitoitusta, jossa yhden tai useamman isännän vikaantuminen jättää silti riittävästi kapasiteettia jokaisen työkuorman uudelleenkäynnistämiseen muualla, mikä yleensä ilmaistaan N+1- tai N+2-varana. Kapasiteettisuunnittelu, joka olettaa jokaisen solmun olevan aina käytettävissä, ei ole suunnittelua; se on katkoksen lykkäämistä.

Toinen periaate on, että vikasietoisuus on porrastettava työkuorman todelliseen arvoon. Kaikki ei ansaitse samaa suojausta, ja toisin teeskenteleminen tuhlaa rahaa merkityksettömiin järjestelmiin ja jättää kriittiset alisuojatuiksi. Tässä palautumistavoitteiden kieli ansaitsee paikkansa. Palautumisaikatavoite kuvaa, kuinka nopeasti palvelu on palautettava, ja palautumispistetavoite kuvaa, kuinka paljon datan menetystä siedetään. Maksujärjestelmä ja tulostuspalvelin sijaitsevat molempien asteikkojen vastakkaisissa päissä, ja kunkin tallennusreplikoinnin, varmuuskopioinnin tahdin ja vikasietosuunnittelun tulisi erota vastaavasti. Jokaisen työkuorman suunnittelu tiukimman tason mukaan on yhtä lailla insinöörivirhe kuin niiden kaikkien suunnittelu löyhimmän mukaan.

Kolmas periaate on havainnoitavuus ensiluokkaisena ominaisuutena eikä jälkiajatuksena. IT-ympäristöä, jota ei voida mitata, ei voida käyttää luottavaisin mielin, koska kapasiteetin ehtyminen, tallennusviiveen hivuttautuminen ja verkon kyllästyminen ilmoittavat itsestään mittareissa kauan ennen kuin ne ilmoittavat itsestään katkoksina. Kattavat mittarit, lokit ja jäljitys laskennan, tallennuksen ja verkon yli ovat sitä, mikä muuntaa toiminnan reaktiivisesta tulipalojen sammuttamisesta ennakoivaksi ylläpidoksi. Viimeinen periaate on standardointi. Yhtenäiset solmut, johdonmukaiset kokoonpanot ja koodina määritelty infrastruktuuri vähentävät sen pinta-alaa, joka voi ajautua, ja ajautuminen on suuren osan häiriöistä hiljainen alkulähde. Tylsä infrastruktuuri on standardoitua, instrumentoitua, anteliaasti vikaantumista varten mitoitettua ja sovitettua sen kantaman todelliseen arvoon.

Vikaantumistilojen ymmärtäminen on hyödyllisempää kuin parhaiden käytäntöjen luetteloiminen, koska sama kourallinen virheitä toistuu muutoin hyvin erilaisissa ympäristöissä. Hiljainen kapasiteetin ehtyminen on yleisin. Tallennustila täyttyy, muistin ylikäyttö saavuttaa rajansa tai virtualisointiklusteri kuormittuu pisteeseen, jossa yhden isännän vikaantumista ei enää voida absorboida. Järjestelmä toimii täydellisesti aina siihen hetkeen asti, kun se ei toimi, ja vikaantuminen on äkillinen juuri siksi, että varoitusmerkit olivat mittareissa, joita kukaan ei seurannut. Korjaus ei ole enemmän laitteistoa vaan rehellinen varan seuranta ja kurinalaisuus kohdella trendiviivoja sitoumuksina.

Korreloitunut vikaantuminen on virhe olettaa redundanssin olevan todellista, kun se ei ole. Kaksi samasta virtapiiristä syötettyä virtalähdettä, kaksi samassa solmussa olevaa tallennusreplikaa tai kaksi virtuaalikonetta, jotka ajastin on hiljaa sijoittanut samalle fyysiselle isännälle, ovat redundantteja vain paperilla. Aito vikasietoisuus edellyttää, että asian kopiot vikaantuvat toisistaan riippumatta, ja riippumattomuuden todentaminen on työlästä, epäkiitollista ja usein sivuutettua. Varmuuskopio, jota ei koskaan palauteta on tähän liittyvä ja tuskallisen yleinen vikaantuminen: varmuuskopiot ajetaan vuosikausia, ne näyttävät terveiltä ja osoittautuvat pahimmalla mahdollisella hetkellä puutteellisiksi, vioittuneiksi tai mahdottoman hitaiksi palauttaa. Varmuuskopio, jota ei ole palautettu harjoituksessa, on hypoteesi eikä turvatoimi.

Kokoonpanon ajautuminen rapauttaa ympäristöjä hitaasti. Kerran identtiset isännät erkanevat, kun manuaaliset muutokset kasautuvat, kunnes IT-ympäristön käyttäytymistä ei enää voida ennustaa sen dokumentaatiosta ja vianetsinnästä tulee arkeologiaa. Monimutkaisuus omana vaaranaan on hienovaraisempi vikaantuminen: jokainen ylimääräinen abstraktion, orkestroinnin ja automaation kerros lisätään hyvästä syystä, mutta kokonaisuudesta tulee järjestelmä, jota kukaan yksittäinen henkilö ei täysin ymmärrä, ja kerrosten väliset vuorovaikutukset tuottavat vikaantumisia, joita yksikään niistä ei ilmennä yksinään. Kaikkien näiden läpi kulkeva oppitunti on johdonmukainen. Infrastruktuuri vikaantuu harvoin siksi, että komponentti rikkoutuu, sillä komponenttien odotetaan rikkoutuvan ja niiden ympärille suunnitellaan. Se vikaantuu siksi, että oletus redundanssista, kapasiteetista tai palautettavuudesta osoittautuu testaamattomaksi.

Nashua lähestyy infrastruktuuria näyttöön perustuvana insinööritoimeksiantona eikä myytävänä tuoteluettelona. Lähtökohta on aina arviointi: selväsilmäinen inventaario olemassa olevasta ympäristöstä, sen työkuormista, niiden todellisesta käyttöasteesta ja niiden tosiasiallisista vikasietovaatimuksista. Suurta osaa infrastruktuurin päätöksenteosta heikennetään alusta alkaen työskentelemällä oletetun eikä mitatun kysynnän pohjalta, joten ensimmäinen tehtävä on korvata oletus datalla. Mikä on aidosti tasaista ja ennustettavaa, mikä on piikkaavaa ja joustavaa, mikä kantaa sääntelyyn tai viiveeseen liittyviä rajoitteita ja mikä on yksinkertaisesti vanhaa perintöä, joka jää voimaan inertiasta: nämä erottelut määrittävät jokaisen sitä seuraavan suunnittelupäätöksen.

Tuosta perustasosta Nashua suunnittelee juuri kyseiselle ympäristölle eikä viitearkkitehtuurille. Silloin kun konsolidointi ja ennustettavuus puoltavat sitä, se tarkoittaa virtualisoituja tai hyperkonvergoituja alustoja, jotka on mitoitettu rehellisellä vikaantumisvaralla ja työkuorman arvoon sovitetulla porrastetulla vikasietoisuudella. Silloin kun joustavuus tai kattavuus puoltaa julkista pilveä, työkuormat sijoitetaan sinne harkitusti, kustannusmalli etukäteen ymmärrettynä eikä laskusta löydettynä. Paikallinen vastaan pilvi -kysymykseen vastataan työkuorma kerrallaan sen taloudellisuuden ja teknisten rajoitteiden pohjalta, mikä on ainoa puolustettavissa oleva tapa vastata siihen. Kauttaaltaan havainnoitavuus suunnitellaan sisään alusta alkaen, koska IT-ympäristöä, jota ei voida mitata, ei voida käyttää sillä tasolla, josta organisaatio on riippuvainen.

Toimitus on tarkoituksellisen näyttämätöntä. Nashua suosii standardoituja, koodina määriteltyjä kokoonpanoja, jotka vastustavat ajautumista, harjoiteltuja eikä oletettuja varmuuskopiointi- ja palautusjärjestelyjä sekä kapasiteettisuunnittelua, joka kohtelee trendiviivoja sitoumuksina. Toimeksianto ei pääty luovutukseen. Infrastruktuuri on elävä ympäristö, jonka vaatimukset muuttuvat, ja Nashuan malli on jatkuvan käytön, seurannan ja säännöllisen uudelleenarvioinnin malli, niin että vara, vikasietoisuus ja kustannukset pysyvät linjassa todellisuuden kanssa organisaation ja sen työkuormien kehittyessä.

Ero, jonka Nashua tuo, ei ole yksittäinen teknologia vaan tapa ajatella infrastruktuuria kokonaisena järjestelmänä, jolla on velvoitteita sen varassa lepäävää liiketoimintaa kohtaan. Monet palveluntarjoajat osaavat asentaa hyperkonvergoidun klusterin tai siirtää työkuorman pilveen. Harvemmat osaavat kertoa organisaatiolle näyttöön perustuen, mitkä sen työkuormista kuuluvat minnekin, kuinka paljon vikaantumisvaraa se todellisuudessa kantaa ja kestäisivätkö sen varmuuskopiot kosketuksen todelliseen häiriöön. Tuo insinöörin täsmällisyyden ja rehellisen taloudellisuuden yhdistelmä, sovellettuna juuri kyseiseen ympäristöön eikä geneeriseen malliin, on siellä missä arvo kertyy, ja siksi Nashuan infrastruktuurityötä ei yleensä arvioida sinä päivänä, jona se toimitetaan, vaan niiden hiljaisten vuosien aikana, joina mikään ei mene pieleen.

Tähän liittyy myös käytännön 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 ripeästi, agenttipohjaisen suunnittelun kautta: se, mitä tarvitaan, kuvataan tavallisella kielellä ja generoidaan nopeasti, mutta aina lujien arkkitehtuuriperiaatteiden puitteissa ja tiukan laadunvarmistuksen alaisena, niin ettei nopeus koskaan tule johdonmukaisuuden, tietoturvan tai hallinnan kustannuksella. Vaikutus on strateginen eikä pelkästään kätevä. Se siirtää tee tai osta -rajaa, pitää valinnanvapauden halpana ja antaa arkkitehtuurin seurata strategiaa sen sijaan, että strategia taipuisi siihen, mitä sattui olemaan hyllyssä.

Mikä sitoo toimeksiannon yhteen, on vastuun jatkuvuus. Infrastruktuuri, joka on suunniteltu hyvin mutta jota käytetään huolimattomasti, taantuu samoihin vikaantumistiloihin, joiden välttämiseksi se rakennettiin, joten Nashua pysyy mukana käytön, seurannan ja uudelleenarvioinnin läpi sen sijaan, että kohtelisi rakentamista maaliviivana. Organisaatio saa IT-ympäristön, joka on tylsä parhaassa mielessä: kustannuksiltaan ennustettava, suunnittelultaan vikasietoinen, päästä päähän havainnoitava ja sen kantaman todelliseen arvoon sovitettu. Tuo hiljainen luotettavuus, ajan yli ylläpidettynä, on se ero, jolla on merkitystä, koska infrastruktuurissa korkein kiitos on se, ettei kenelläkään ollut syytä ajatella sitä lainkaan.