Pilven ohjaustaso
Pilven ohjaustaso on rajapintojen, API:ien ja palveluiden kerros, jonka avulla voit provisioida, konfiguroida ja hallita infrastruktuuria — erillään datatasosta, joka varsinaisesti ajaa työkuormiasi ja välittää liikennettäsi. Jokainen palveluntarjoaja toimittaa oman ohjaustasonsa; termi kattaa myös järjestelmät, jotka hallitsevat useita palveluntarjoajia yhtenä tasona.
Jokaisessa infrastruktuurissa on kaksi erillistä kerrosta. Datataso on itse infrastruktuuri: virtuaalikoneet, jotka ajavat sovellustasi, verkko, joka siirtää paketteja niiden välillä, ja levy, joka palvelee luku- ja kirjoituspyyntöjä. Ohjaustaso on kaikki se, minkä avulla päätät, miltä kyseisen infrastruktuurin pitäisi näyttää, ja teet siihen muutoksia — API, konsoli, CLI ja käyttöoikeusjärjestelmä, joka päättää, kenellä on lupa tehdä muutos. Kun luot virtuaalikoneen pilvikonsolissa, muutat levyn kokoa tai avaat palomuurin portin, käytät ohjaustasoa. Käynnistyvä instanssi, käyttöön tuleva lisäkapasiteetti, alkava liikenne — se on datataso, joka reagoi siihen, mitä ohjaustaso käski sen tehdä.
Erottelu käy hyödyllisemmäksi, kun tiimi käyttää useampaa kuin yhtä palveluntarjoajaa. AWS:llä on ohjaustaso. Samoin on Google Cloudilla, Azurella, Hetznerillä ja jokaisella muullakin palveluntarjoajalla — kullakin oma konsolinsa, oman muotoinen API:nsa, omat tunnuksensa ja oma käsityksensä siitä, mitä kutsutaan 'security groupiksi' tai 'firewall-säännöksi'. Tiimi, joka käyttää kolmea pilveä ja kahtakymmentä bare metal -palvelinta, käyttää todellisuudessa kolmea tai neljää erillistä ohjaustasoa rinnakkain, sen lisäksi mitä se käyttää niiden palvelimien hallintaan, jotka eivät ole missään pilvessä lainkaan. Mikään ei pakota noita ohjaustasoja olemaan yhteneviä keskenään, eikä mikään oman prosessin ulkopuolella pidä yhdessä ohjaustasossa tehtyä muutosta näkyvänä sille, joka katsoo toista.
'Pilven ohjaustasoa' käytetään myös suppeammassa merkityksessä — Kubernetesin sisällä ohjaustaso tarkoittaa API-palvelinta, ajoitinta (scheduler) ja controller-manageria, jotka päättävät, missä podit ajetaan, erotuksena kubeleteista ja konteista, jotka niitä tosiasiallisesti ajavat solmuissa (nodes). 'Multi-cloud'- tai 'yhtenäinen' ohjaustaso laajentaa saman ajatuksen useiden palveluntarjoajien yli: yksi paikka, josta näet ja voit hallita infrastruktuuria, joka fyysisesti sijaitsee useissa eri tileissä, alueilla ja toimittajajärjestelmissä, yhden palveluntarjoajakohtaisen käyttöliittymän sijaan. Se ei korvaa taustalla olevia palveluntarjoajien ohjaustasoja — pyyntö päätyy silti API-kutsuna AWS:ään, Hetzneriin tai bare metal -koneen fleet-agenttiin — vaan se asettuu niiden eteen, jotta muutoksen tekevän tarvitsee opetella vain yksi järjestelmä.
Miksi tällä erolla on operatiivista merkitystä
Useimmat infrastruktuuri-insidentit ja auditointiaukot juontuvat ohjaustason ongelmista, ei datatason ongelmista: muutos, jota kukaan ei kirjannut, käyttöoikeus, jota kukaan ei kumonnut, palomuurisääntö, joka avattiin yhden palveluntarjoajan konsolissa ja jota kukaan muu tiimissä ei näe. Kun jokaisella pilvellä on oma ohjaustasonsa ja oma auditointijälkensä, kysymyksestä 'kuka muutti tämän ja milloin' tulee kysymys, johon vastataan kirjautumalla kolmeen tai neljään eri konsoliin ja vertaamalla aikaleimoja käsin — tai johon ei vastata lainkaan. Tiimeille, joita sitovat vaatimustenmukaisuuskehykset kuten NIS2, tämä aukko ei ole vain hankala: muutoshistoria, pääsynhallinta ja insidenttien todistusaineisto ovat juuri sitä, mitä auditoija tai valvova viranomainen kysyy ensimmäisenä, ja hajanainen ohjaustaso on syy, miksi tätä todistusaineistoa ei usein ole koottuna yhteen paikkaan.
Miten Sencai sopii tähän
Sencai on ohjaustaso, joka asettuu natiivien ohjaustasojen yläpuolelle: se yhdistyy tileihin yhdentoista pilvipalveluntarjoajan ympäristöissä sekä on-premise- ja bare metal -palvelimiin kevyen fleet-agentin kautta, ja inventoi jo käynnissä olevat resurssit heti, kun tili yhdistetään — ilman migraatiota. Siitä eteenpäin instanssien provisiointi, käynnistäminen, pysäyttäminen, koon muuttaminen ja tuhoaminen toimii samalla tavalla palveluntarjoajasta riippumatta. Voit yhdistää olemassa olevia tilejä (mikään ei siirry, ja tunnukset pysyvät peruutettavissa palveluntarjoajan puolella) tai antaa Sencain provisioida ja laskuttaa kapasiteetti suoraan, ja yhdistellä molempia tapoja samassa organisaatiossa. Jokainen toimenpide jokaisessa yhdistetyssä palveluntarjoajassa kirjautuu yhteen ainoaan muuttumattomaan, hash-ketjutettuun auditointilokiin, joten 'kuka muutti tämän ja milloin' on kyselyn, ei tutkinnan, asia.
Katso inventointi ja provisiointi →