Kysy kymmeneltä infrastruktuuritiimiltä, onko heillä pilvestä poistumisen strategia, ja yhdeksän vastaa kyllä. Kysy, mistä se koostuu, ja saat yleensä wiki-sivun, joka kirjoitettiin toimittajakatselmoinnin aikana ja joka listaa, mitkä palvelut ovat suljettuja ja mitkä siirrettävissä. Se on inventaario, ei strategia. Todellinen testi on vähemmän mukava: jos palveluntarjoajasi tuplaisi hintansa, vaihtaisi lainkäyttöaluetta tai jäädyttäisi tilisi tiistaiaamuna, kuinka monta viikkoa kestäisi ennen kuin palvelet liikennettä jossain muualla - ja kuka tiimissäsi osaa vastata siihen avaamatta taulukkolaskentaa?
Sääntelypaine tässä on todellinen, mutta se ei ole se mielenkiintoinen osa. Data-asetus poistaa vaihtomaksut, mikä vie talousosastolta sen tekosyyn. Schrems II ja CLOUD Act veivät lakiosastolta omansa jo vuosia sitten. Se, mikä jää jäljelle, on insinöörityön todellisuus, eikä mikään direktiivi korjaa sitä. Sääntelyviranomainen voi tehdä lähtemisestä halvempaa paperilla; se ei voi saada deploymentti-putkeasi, identiteettimalliasi, DNS-tietueitasi ja palautuspolkuasi toimimaan toisella palveluntarjoajalla. Se työ on sinun, ja se on koko kustannus.
Mitä pilvestä poistumisen strategia oikeasti on
Poistumisstrategia on arkkitehtuurisi mitattavissa oleva ominaisuus, ei dokumentti. Mittaus on suora: minkä osuuden käyvästä kalustostasi voisit pystyttää toisella palveluntarjoajalla, työkaluilla joita jo operoit, kirjoittamatta uutta koodia? Useimmille tiimeille rehellinen vastaus asettuu jonnekin neljänkymmenen ja seitsemänkymmenen prosentin väliin, eikä kuilu ole koskaan siellä, missä he odottivat. Se on harvoin sovellus. Se on hallittu tietokanta, jono, object storage -semantiikka, ja ne yksitoista pientä operatiivista tapaa, joita kukaan ei koskaan kirjoittanut ylös.
Vikatila on uskoa, että kahden palveluntarjoajan omistaminen todistaa mitään. Monet yritykset ajavat tuotantoa yhdellä hyperscalerilla ja unohdetulla testiprojektilla jossain muualla, ja kutsuvat tulosta multi-cloudiksi. Optionaalisuus ei ole toisen tilin olemassaolo; se on kyky käyttää sitä. Ennen kuin yksi todellinen workload - jolla on valvonta, varmuuskopiot, päivystysrota ja palautus, jonka olet oikeasti suorittanut - ajetaan jossain muualla kuin ensisijaisella palveluntarjoajallasi, sinulla on toinen lasku, ei toinen vaihtoehto.
Kolme asiaa, jotka tekevät lähtemisestä vaikeaa
Ensinnäkin data gravity, joka on tylsä ja ratkaiseva. Tavuja on halpa kopioida ja kallis siirtää johdonmukaisesti järjestelmän ollessa käynnissä. Sillä hetkellä kun datasi asuu suljetussa hallitussa palvelussa, poistumisesta lakkaa olemasta kopiointia ja siitä tulee kaiken sen uudelleenkirjoittamista, mikä puhuu sen kanssa. Siksi tiimit, jotka pitävät tilansa jossain, mitä voisivat ajaa itse - vaikka eivät tänään valitsisikaan niin tehdä - säilyttävät vaihtoehtoja, jotka täysin hallituilla pinoilla olevat tiimit menettävät hiljaa muutamassa vuodessa.
Toiseksi, operatiivinen lihasmuisti. Tiimisi tuntee yhden palveluntarjoajan identiteettimallin, yhden palomuuriabstraktion, yhden tavan nimetä verkkoja, yhden konsolin asettelun kello kolmelta yöllä. Siirry toiselle palveluntarjoajalle, ja jokainen niistä on vieras paineen alla. Kustannus ei ole migraatioviikonloppu; se on sitä seuraavat kuusi kuukautta, joina häiriöitä käsitellään hieman hitaammin ihmisten toimesta, jotka arvailevat. Kukaan ei laita sitä migraatioarvioon, ja se on yleensä sen suurin rivi.
Kolmanneksi, kustannusten attribuutio. Useimmat tiimit eivät osaa kertoa, mitä yksittäinen workload maksaa tänään, mikä tekee palveluntarjoajien vertailusta periaatteessa mahdotonta. Jos laskusi on yksi luku per palveluntarjoaja ja arkkitehtuurisi on neljäkymmentä palvelua, poistumiskeskustelu rappeutuu fiiliksiksi. Ennen kuin voit hinnoitella poistumisen, tarvitset kulutuksen eriteltynä palvelun, projektin ja ympäristön mukaan, jokaisen käyttämäsi palveluntarjoajan yli, mukaan lukien ne pienet, jotka unohdit. Se on epäglamouria pohjatyötä, ja se on edellytys jokaiselle muulle päätökselle tässä.
Miten välttää vendor lock-in EU:n pilvimarkkinoilla
Jos haluat välttää vendor lock-inin, EU:n markkina on paremmassa kunnossa kuin useimmat tiimit olettavat. Hetznerin hinta-suorituskyky saa hyperscaler-laskut näyttämään pyöristysvirheeltä väärään suuntaan. OVHcloud ajaa omia konesalejaan ja kuituverkkoaan ympäri Eurooppaa. Scaleway toimittaa aidosti modernin kehittäjäkokemuksen Ranskasta. UpCloud tarjoaa luotettavaa laskentatehoa Suomesta. Yksikään niistä ei korvaa jokaista hyperscalerin palvelua - mutta laskennassa, lohkotallennuksessa ja verkottamisessa, joihin suurin osa infrastruktuurirahasta oikeasti menee, ne ovat uskottavia ja vastaavat yksinomaan EU:n lainsäädännölle.
Rehellinen raja on hallitut palvelut. Jos tuotteesi on rakennettu suljetun serverless-tietokannan, tietyn event busin, tai koneoppimisalustan varaan, jolle ei ole vastinetta muualla, mikään määrä eurooppalaista innostusta ei muuta sitä yhden kvartaalin sisällä. Hyödyllinen liike ei ole sankarillinen kaikki-tai-ei-mitään-migraatio. Se on tietää tarkalleen, mitkä workloadit ovat tänään siirrettävissä, ajaa osa niistä siellä, missä lainkäyttöalue ja hinta sopivat sinulle, ja kohdella loppuja tarkoituksellisena, dokumentoituna päätöksenä historian sattuman sijaan.
Mitä poistumisharjoitus oikeasti tarkoittaa
Kohtele sitä kuin palautusharjoitusta, koska sitä se on. Valitse todellinen workload - ei markkinointisivustoa, vaan jotain, jolla on tila ja runbook. Pystytä se toiselle palveluntarjoajalle. Ohjaa murto-osa oikeasta liikenteestä sinne. Riko se tarkoituksella ja katso, toimivatko valvontasi, pääsymallisi ja päivystysrotasi myös siellä. Kirjoita sitten ylös kuluva aika ja kaikki, mikä yllätti sinut. Harjoitus, joka ei tuota yhtään yllätystä, tarkoittaa yleensä, että valitsit jotain liian helppoa.
Syy, miksi useimmat tiimit eivät koskaan harjoittele, ei ole laiskuus, vaan työkalut. Jokainen lisäpalveluntarjoaja tarkoittaa toista konsolia, toista kredentiaalimallia, toista laskutusvientiä, toista joukkoa opittavia erikoisuuksia - eikä pieni alustatiimi voi imeä sitä sisäänsä kerran per pilvi. Tämä on se operatiivinen vero, joka hiljaa muuttaa suvereniteettikeskustelun ensi vuoden ongelmaksi, joka vuosi. Se on myös, täsmälleen, se ongelma, jonka control planen on tarkoitus poistaa pöydältäsi.
Juuri sitä varten rakensimme Sencain. Yksi control plane yhdentoista palveluntarjoajan yli - Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamain Linode ja Oracle Cloud - sekä omat palvelimesi host-agentin kautta. Verkot, palomuurit ja DNS hallitaan siellä, missä ne oikeasti asuvat, palveluntarjoajalla, joten toisesta palveluntarjoajasta tulee laatta samassa käyttöliittymässä sen sijaan, että se olisi toinen alustatiimi. Kulutusta seurataan organisaatiokohtaisesti katoilla, joten poistumiskeskustelussa on lukuja mukana.
Voit ajaa tätä omilla palveluntarjoajatileilläsi, tai ostaa kapasiteetin meidän kauttamme ja pitää yhden laskun - molemmat ovat tuettuja, ja valinta on sinun muutettavissasi myöhemmin. Kummassakin tapauksessa toimitettava on sama, ja se on ainoa luku, joka kannattaa raportoida ylöspäin: kuinka kauan sinulta veisi olla käynnissä jossain muualla. Mittaa se kerran, ja se lakkaa olemasta pelko. Mittaa se joka kvartaali, ja siitä tulee neuvotteluvoimaa - neuvottelussa, hankintakatselmoinnissa, ja sinä päivänä kun jokin pakottaa kysymyksen esiin.