Technology & Infrastructure Architecture
Teknologia- ja infrastruktuuriarkkitehtuuri on kerros, jonka useimmat huomaavat vasta silloin, kun se pettää, ja se sivuutetaan rutiininomaisesti putkitöinä, jotka on syytä minimoida ja ulkoistaa. Tämä ajattelutapa on kallis, sillä infrastruktuuriperusta muodostaa rajat kaikelle sen päällä olevalle: viiveet, jotka sovellukset voivat saavuttaa, vikatilanteet, joista ne selviävät, muutosvauhti ja yksikkötalous määrittyvät kaikki täällä. Ensiluokkaisena suunnittelunalana käsiteltynä siitä tulee omaisuuserä, joka kertyy korkoa korolle. Implisiittiseksi jätettynä se on syy siihen, miksi jokainen muu arkkitehtuuriponnistus hiljalleen pysähtyy.
Miksi perustasta on tullut pullonkaula
Suurimman osan viimeisistä kahdesta vuosikymmenestä infrastruktuuri oli hitaasti muuttuva perusta, jonka sovellustiimit saattoivat pitkälti ottaa annettuna. Palvelimet toimitettiin viikoissa, kapasiteettia ostettiin kysyntää ennakoiden, ja verkko oli kiinteä topologia, jota ylläpiti erikoistunut tiimi. Liiketoiminnan muutosvauhti oli riittävän matala, jotta tämä järjestely piti. Näin ei ole enää. Organisaatiot odottavat nykyään julkaisevansa tuotemuutoksia viikoittain, skaalaavansa palvelun kymmenkertaiseksi kausiluonteista huippua varten ja astuvansa uudelle markkinalle alueellisella jalanjäljellä, joka täyttää paikalliset tietojen sijaintia koskevat säännöt. Jokainen näistä odotuksista lankeaa lopulta infrastruktuurikerroksen kannettavaksi.
Samaan aikaan ympäristöstä on tullut aidosti heterogeeninen. Lähes yksikään mittavan kokoluokan yritys ei toimi yhdessä ympäristössä. On julkista cloudia, yleensä useammalta kuin yhdeltä palveluntarjoajalta yritysoston tai tietoisen strategian kautta. On yksityinen ympäristö, joka ei kadonnut, koska mainframe, erikoistunut laite tai datan painovoiman asettama rajoite pitää sen paikoillaan. On laajeneva reuna, joka koostuu toimipisteistä, tehtaista ja laitteista. Kiinnostavat arkkitehtoniset kysymykset eivät ole enää minkään yksittäisen ympäristön sisällä vaan niiden välisissä saumoissa: miten työkuormat sijoitetaan, miten identiteetti ja verkon luottamus ulottuvat rajan yli ja miten yhtenäinen toimintamalli säilyy jakautumisen läpi.
Kaksi voimaa tekee tästä kiireellistä eikä pelkästään tärkeää. Ensimmäinen on kustannus. Cloud-menoista on tullut yksi teknologiabudjetin suurimmista ja vähiten ymmärretyistä riveistä, ja joustavuus, joka myytiin säästönä, muuttuu usein vuodoksi, kun kukaan ei omista taloutta. Toinen on sääntely ja odotukset kestävyydestä. DORAn kaltaiset kehykset Euroopan finanssisektorilla ovat tehneet operatiivisesta kestävyydestä ja kolmannen osapuolen keskittymäriskistä hallitustason velvoitteita, joilla on todelliset seuraukset. Molemmat voimat ovat luonteeltaan arkkitehtonisia. Kumpaakaan ei ratkaista ostamalla parempi tuote. Ne ratkaistaan omaamalla tietoiset standardit sille, miten teknologiaperusta rakennetaan, sijoitetaan ja operoidaan, mikä on juuri tämän alan tehtäväkenttä.
Teknologiaperustan perusperiaatteet
Hyödyllinen tapa hahmottaa infrastruktuuriarkkitehtuuria on nähdä se tasojen pinona, joista kullakin on omat takuunsa, tuotteiden luettelon sijaan. Pohjalla on perusta: fyysiset ja virtuaaliset sijainnit, cloud-alueet ja saatavuusvyöhykkeet, paikalliset konesalit sekä yhteydet, jotka sitovat ne yhteen. Sen yläpuolella on resurssitaso, joka koostuu laskennasta, tallennuksesta ja verkosta, ilmaistuna yhä useammin abstraktioina laitteiston sijaan. Sen yläpuolella on alustataso, jossa nämä resurssit kootaan suoritusympäristöiksi: container-orkestrointi, hallitut datapalvelut, viestintä ja integraatiokudos. Liiketoiminnalle tärkeät sovellukset ja palvelut toimivat päällimmäisenä, hyödyntäen takuita, joita niiden ei koskaan pitäisi joutua itse kokoamaan.
Ydinperiaate on, että kunkin tason tulisi tarjota pieni, vakaa sopimus ylemmälle tasolle ja piilottaa mekanismi allaan. Sovellustiimin tulisi voida pyytää kestävää, salattua ja varmuuskopioitua tietovarastoa määritellyllä palautumistavoitteella tietämättä, mikä tallennusteknologia sen täyttää. Juuri tämä tekee perustasta korvattavan: kun sopimus on eksplisiittinen, toteutus voi muuttua ilman kaskadimaista uudelleentyöstöä. Kun se on implisiittinen, jokainen alempi valinta vuotaa ylöspäin ja ympäristö luutuu.
Kolme läpileikkaavaa huolenaihetta kulkee pystysuunnassa jokaisen tason läpi ja ansaitsee tulla käsitellyksi ensiluokkaisena alusta alkaen sen sijaan, että ne jälkiasennetaan. Identiteetti on todellinen kehä: työkuormat, ihmiset ja palvelut tarvitsevat kaikki todennettavan identiteetin ennen kuin verkkotopologialla on mitään merkitystä. Havainnoitavuus on ominaisuus, jonka avulla voi päätellä järjestelmästä, jonka rakentamista ei ole seurannut, ja se on suunniteltava sisään telemetriasopimuksina, ei kiinnitettävä päälle agentteina. Talous on kurinalaisuutta kohdistaa kustannus siihen, mikä sen aiheutti, jotta suunnittelupäätös ja sen taloudellinen seuraus ovat näkyvissä samalle henkilölle. Teknologiaperusta, joka kohtelee identiteettiä, havainnoitavuutta ja kustannusta jälkiajatuksina, on paperilla kestävä mutta käytännössä hauras.
Lopuksi, kaikki tämä tulisi ilmaista koodina ja referenssikuvioina tikettien ja hiljaisen tiedon sijaan. Infrastruktuuri koodina ei ole työkalumieltymys. Se on mekanismi, joka muuttaa arkkitehtuurin joksikin, jota voi tarkastaa, versioida, testata ja toisintaa. Standardi, joka on olemassa vain dokumentissa, on ehdotus. Standardi, joka on koodattu uudelleenkäytettäväksi moduuliksi, jonka tiimit instantoivat, on arkkitehtuuria.
Mikä ympäristössä on muuttumassa
Useat kehityskulut muokkaavat sitä, miten teknologiaperusta suunnitellaan, ja on syytä erottaa kestävät muutokset melusta. Selkein kestävä muutos on hybridi- ja monicloud-ympäristön normalisoituminen pysyväksi tilaksi migraatiovaiheen sijaan. Ala on ohittanut oletuksen, että kaikki päätyy lopulta yhteen julkiseen cloudiin. Työkuormien sijoittelusta on tullut eksplisiittinen suunnittelupäätös, jota ohjaavat datan painovoima, viive, suvereniteetti ja kustannus, mikä nostaa sellaisen arkkitehtuurin arvoa, joka voi käsitellä useita ympäristöjä yhteisen toimintamallin kautta sen sijaan, että ylläpidettäisiin erillistä mallia kullekin palveluntarjoajalle.
Platform engineering on organisatorinen vastaus tuohon monimutkaisuuteen. Sen sijaan, että jokaiselta sovellustiimiltä odotettaisiin infrastruktuurikerroksen koko syvyyden hallintaa, organisaatiot rakentavat sisäisiä alustoja, jotka tarjoavat valmiiksi asfaltoituja polkuja: mielipiteellisiä, itsepalvelullisia tapoja hankkia laskentaa, tallennusta, putkia ja ympäristöjä, jotka täyttävät jo valmiiksi turvallisuus-, kestävyys- ja kustannusstandardit. Hyvin tehtynä tämä on edellä kuvattujen tasosopimusten operatiivinen ruumiillistuma. Huonosti tehtynä siitä tulee vain yksi ylläpidettävä kerros vailla käyttöönottoa.
Suvereniteetti ja sääntelyllinen paikallisuus ovat siirtyneet erikoistapauksesta suunnittelua ohjaavaksi tekijäksi, erityisesti Euroopassa. Kysymys siitä, missä data fyysisesti sijaitsee, mikä oikeushenkilö operoi hallintatasoa ja voidaanko työkuorma eristää vieraasta lainkäyttöalueesta, on nykyään aito arkkitehtoninen rajoite, joka muovaa aluestrategiaa ja palveluntarjoajan valintaa. Tämä leikkaa kestävyysagendan kanssa: keskittymä yhteen palveluntarjoajaan on yhä useammin jotain, mitä organisaatioiden on kyettävä hahmottamaan ja joissakin tapauksissa aktiivisesti lieventämään.
Resurssitasolla abstraktiot jatkavat nousuaan. Serverless ja hallitut palvelut siirtävät enemmän operatiivista taakkaa palveluntarjoajalle, mikä on houkuttelevaa kunnes abstraktio vuotaa ja huomaat vaihtaneesi operatiivisen raadannan arkkitehtoniseen lukkiutumiseen. Viimeaikainen erikoistuneen laskennan kysynnän kasvupyrähdys, jota koneoppimisen ja päättelyn työkuormat vetävät, on tuonut takaisin laitteiston heterogeenisyyden ja kapasiteettisuunnittelun tiimeille, jotka olivat mielellään unohtaneet molemmat. Kestävä juonne kaiken tämän läpi on, että abstraktio ei koskaan poista alla olevaa huolenaihetta. Se siirtää vastuun paikkaa, ja hyvä arkkitehtuuri on tietoinen siitä, missä tuon vastuun tulisi sijaita.
Suunnitteluperiaatteet, jotka pitävät sen koossa
Kestävä, havainnoitava ja kustannustehokas perusta ei ole yhden nokkelan päätöksen tulos. Se syntyy kourallisesta johdonmukaisesti sovellettavia periaatteita. Ensimmäinen on suunnitella vika odotettavissa olevaksi tapaukseksi. Mittakaavassa komponentit vikaantuvat jatkuvasti, ja hyödyllinen kysymys ei ole, miten vika estetään, vaan miten sen vaikutussäde rajataan. Tämä tarkoittaa eksplisiittisiä vikadomaineja, redundanssia, joka ulottuu niiden yli, ja palautumistavoitteita, jotka on määritelty työkuormakohtaisesti ja jotka on todella testattu eikä oletettu. Palautumissuunnitelma, jota ei ole koskaan harjoiteltu, on hypoteesi, ei kyvykkyys.
Toinen periaate on, että infrastruktuurin tulisi olla muuttumaton ja toisinnettava. Palvelimet ja klusterit tulisi rakentaa versioiduista määrityksistä ja korvata paikallaan paikkaamisen sijaan, jotta toiminnassa oleva ympäristö vastaa aina kuvausta, jota voi tarkastella. Konfiguraation ajautuminen, hidas eroavaisuus sen välillä, mitä luulet olevan käytössä ja mitä todella on, on suhteettoman suuren osuuden tuotantohäiriöistä lähde, ja muuttumattomuus on rakenteellinen parannuskeino.
Kolmas periaate on havainnoitavuus sopimuksen kautta. Jokaisen palvelun tulisi lähettää määritelty joukko signaaleja, metriikoita, lokeja ja jälkiä, jotka on korreloitu johdonmukaisin tunnistein, jotta kysymyksiin voidaan vastata jälkikäteen instrumentoimatta paniikissa. Tavoite on kyky päätellä käyttäytymisestä, jota ei ennakoitu, mikä on vahvempi ominaisuus kuin kiinteän joukon tunnettuja olosuhteita valvominen.
Neljäs on vähimmän oikeuden periaate ja identiteettikeskeinen luottamus. Verkkosijainti on heikko perusta luottamukselle hajautetussa ympäristössä. Pääsyn tulisi seurata todennettua työkuorman ja käyttäjän identiteettiä, segmentoinnilla, joka olettaa kehän jo ylitetyksi. Viides on kustannustietoinen suunnittelu, jossa taloudellinen vaikutus on arkkitehtuuripäätöksen näkyvä ominaisuus kuukausittaisen yllätyksen sijaan, kohdistettuna riittävän puhtaasti, jotta valinnan tekevä tiimi näkee seurauksen. Yhdessä nämä periaatteet suosivat perustaa, joka on tylsä parhaassa merkityksessä: ennustettava, tarkastettava ja yllätyksetön paineen alla. Tavoite ei ole maksimaalinen hienostuneisuus. Se on pienin joukko hyvin ymmärrettyjä kuvioita, jotka täyttävät kestävyys-, havainnoitavuus- ja taloustavoitteet, sovellettuna poikkeuksetta, koska poikkeus on paikka, josta seuraava häiriö alkaa.
Miten perusta menee pieleen
Infrastruktuuriarkkitehtuuri pettää tunnistettavin tavoin, ja niiden nimeäminen on ensimmäinen puolustuslinja. Tahaton monimutkaisuus on yleisin. Ympäristöön kertyy palveluntarjoajia, työkaluja ja kertaluonteisia kuvioita, kukin paikallisesti perusteltu, kunnes yksikään henkilö ei kykene pitämään topologiaa päässään ja jokainen muutos kantaa tuntematonta riskiä. Syy on yleensä pakotetun referenssijoukon puuttuminen, joten jokainen tiimi ratkaisee saman ongelman eri tavalla. Parannuskeino on tarkoituksellisen pieni standardikirjasto kuvioita ja kurinalaisuus sanoa ei lisäyksille, jotka eivät ansaitse monimutkaisuuttaan.
Lift-and-shift ilman uudelleensuunnittelua on vika, joka muuttaa cloud-ohjelman pettymykseksi. Työkuormat siirretään sellaisenaan joustavaan ympäristöön säilyttäen kiinteän kapasiteetin oletuksensa, ja organisaatio perii cloud-hinnoittelun ilman cloudin hyötyjä. Kustannus nousee, kestävyys ei parane, ja migraatio arvioidaan epäonnistumiseksi, vaikka todellisuudessa epäonnistui päätös olla suunnittelematta arkkitehtuuria.
Havainnoitavuus jälkiajatuksena tuottaa ympäristöjä, jotka ovat hiljaisia kunnes eivät ole. Telemetriaa lisätään reaktiivisesti jokaisen häiriön jälkeen, kattavuus on epätasaista eivätkä signaalit korreloidu, joten diagnosointi riippuu niistä harvoista ihmisistä, jotka sattuvat tietämään, mihin ruumiit on haudattu. Tällaisesta järjestelmästä esitetyt kestävyysväitteet ovat todentamattomia.
Hiljainen lukkiutuminen on vika, joka tulee näkyväksi vasta, kun yrität lähteä. Palveluntarjoajan omisteisten palvelujen syvä käyttöönotto ilman rehellistä arviota poistumiskustannuksesta on legitiimi valinta, mutta vain jos se oli valinta. Siitä tulee vika, kun keskittymäriski, hinnoitteluvalta ja sääntelyaltistus kertyvät oletusarvoisesti eivätkä päätöksellä.
Kustannusentropia on tasainen vuoto ympäristöstä, jota kukaan ei omista taloudellisesti. Käyttämättömät resurssit, ylimitoitetut instanssit, unohdetut ympäristöt ja kohdistamattomat menot kertyvät, koska joustavuus, joka skaalaa ylös, on harvoin kytketty skaalaamaan alas, eikä kukaan tunne luomaansa laskua nahoissaan. Lopuksi, kestävyysteatteri, dokumentoitu vikasieto, jota ei ole koskaan testattu, antaa organisaatiolle luottamusta juuri siellä, missä sillä pitäisi olla epäilystä. Jokainen näistä vikatiloista on luonteeltaan arkkitehtoninen eikä operatiivinen. Niitä ei korjata tekemällä kovemmin töitä virheellisen rakenteen sisällä. Ne estetään rakenteella, ja kun ne kerran ovat läsnä, ne poistetaan vain tuomalla tietoisesti takaisin ne standardit, jotka ohitettiin.
Miten Nashua työskentelee tämän parissa
Nashua lähestyy teknologiaperustaa ensisijaisesti arkkitehtuuriongelmana ja vasta toissijaisesti teknologiavalinnan ongelmana. Toimeksiannot alkavat rehellisellä arviolla nykyisestä ympäristöstä: mikä on todella käynnissä ja missä, miten työkuormat on sijoitettu cloud-, hybridi- ja paikallisten ympäristöjen kesken, missä kestävyys- ja havainnoitavuusaukot sijaitsevat ja miten kustannus kiinnittyy mihinkin. Tämä tuottaa jaetun kuvan, joka on yleensä heterogeenisempi kuin organisaatio uskoi, ja se on välttämätön perusta millekään uskottavalle tavoitesuunnittelulle. Vastustamme kiusausta määrätä määränpää ennen kuin lähtökohta on ymmärretty.
Siitä eteenpäin työskentelemme organisaation kanssa määritelläksemme tavoitteellisen referenssiarkkitehtuurin: pienen joukon standardikuvioita laskennalle, tallennukselle, verkolle, identiteetille, havainnoitavuudelle ja kustannukselle, joita käytetään koko ympäristössä, ilmaistuna koodina ja uudelleenkäytettävinä moduuleina kalvosulkeisten sijaan. Tarkoitus on korvattavuus ja johdonmukaisuus. Tiimin tulisi voida hankkia vaatimustenmukainen, kestävä ympäristö valmiiksi asfaltoidun polun kautta keksimättä perustuksia uudelleen, ja arkkitehtuurin tulisi kyetä omaksumaan palveluntarjoajan tai alustan vaihdos ilman kaskadimaista uudelleentyöstöä. Kun platform engineering -kyvykkyys on perusteltua, autamme suunnittelemaan ja pystyttämään itsepalvelukerroksen, joka tekee standardeista vähimmän vastuksen polun.
Kohtelemme kestävyyttä, havainnoitavuutta ja taloutta insinöörityön tuotoksina, emme aikomuksina. Se tarkoittaa palautumistavoitteita, jotka on määritelty työkuormakohtaisesti ja testattu, telemetriasopimuksia, jotka tekevät ympäristöstä diagnosoitavan, verkatun identiteetin varaan rakennettua segmentointia ja sisään kytkettyä kustannuskohdistusta, jotta päätökset ja niiden taloudelliset seuraukset ovat näkyvissä yhdessä. Läpi työn työskentelemme organisaation omien insinöörien rinnalla emmekä heidän ohitseen, koska teknologiaperusta on vain niin kestävä kuin ne standardit, jotka sitä operoivat ihmiset ymmärtävät ja joihin he uskovat. Roolimme on jättää jälkeemme arkkitehtuuri, jota organisaatio voi laajentaa ja puolustaa omin voimin, yhdessä niiden referenssikuvioiden ja perustelujen kanssa, jotka tekevät siitä ylläpidettävän kauan toimeksiannon päätyttyä.
Missä Nashua tekee eron
Ero, jonka Nashua tuo, on arkkitehtonisen tarkkuuden ja operatiivisen todellisuuden yhdistelmä. Monet organisaatiot osaavat pukea sanoiksi tämän kirjoituksen periaatteet. Harvempi kykenee pitämään koko ympäristön, cloud-, hybridi- ja paikallisen, yhtenä johdonmukaisena kokonaisuutena pysyen samalla täsmällisenä niistä laskennan, tallennuksen, verkon ja alustan valinnoista, jotka tekevät siitä todellisen. Tuo johdonmukaisuus, hallitustason kestävyys- ja suvereniteettivelvoitteista aina referenssimoduuliin, jonka tiimi instantoi tiistaina, on paikka, jossa teknologiaperusta joko kertyy korkoa korolle tai kerää hiljaa riskiä.
Tästä seuraa myös käytännöllinen johdannainen, 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, agenttisen insinöörityön kautta: se, mitä tarvitaan, kuvataan selkokielellä ja generoidaan nopeasti, mutta aina lujien arkkitehtuuriperiaatteiden puitteissa ja tiukan laadunvarmistuksen alaisena, jotta nopeus ei koskaan tule johdonmukaisuuden, turvallisuuden 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 hyllyllä.
Tämä tuottaa teknologiaperustan, joka käyttäytyy ennustettavasti muutoksen ja paineen alla: kestävä, koska vika on suunnittelultaan rajattu, havainnoitava, koska diagnosoitavuus on rakennettu sisään eikä kiinnitetty päälle, ja kustannustehokas, koska talous on jokaisen päätöksen ominaisuus eikä kuukausittainen tilinteko. Yhtä tärkeää on, että se on perusta, jonka organisaatio omistaa, ilmaistuna kuvioina, jotka sen omat ihmiset ymmärtävät ja joita he voivat puolustaa. Nashuan tavoite ei ole tehdä itsestään korvaamaton. Se on jättää jälkeensä teknologiaperusta, joka on tietoinen eikä tahaton, ja organisaation sisäinen arkkitehtuurikäytäntö, joka kykenee pitämään sen sellaisena samalla kun ympäristö, sääntely ja työkuormat jatkavat muuttumistaan.
