Daugiadebesų Strategija: Nauda, Spąstai ir Kada Ji Iš Tikrųjų Prasminga
Darbo krūvių paskirstymo tarp AWS, Google Cloud ir Azure vienu metu idėja yra viliojanti. Nė vienas tiekėjas negali laikyti jūsų infrastruktūros įkaite, galite pasirinkti geriausią kiekvieno teikėjo paslaugą, o atkūrimo po nelaimės scenarijus rašosi pats. Bent jau taip skamba pasiūlymas. Praktikoje dauguma organizacijų, priėmusių daugiadebesų strategiją be aiškaus strateginio pagrindo, moka daugiau, juda lėčiau ir valdo įrankių paplitimą, kurio nė viena komanda iki galo nesupranta. Daugiadebesų strategija nėra savaime klaidinga — tačiau dažnai priimama dėl netinkamų priežasčių. Skirtumas tarp sąmoningos daugiadebesų architektūros ir atsitiktinio daugiadebesų paplitimo yra skirtumas tarp konkurencinio pranašumo ir pačių prisiimto operacinio mokesčio.
Tiekėjo Priklausomybės Paradoksas
Dažniausias argumentas už daugiadubesų strategiją yra tiekėjo priklausomybės vengimas. Logika tokia: jei statote ant vieno debesies, esate priklausomi nuo to teikėjo kainų pokyčių, paslaugų nutraukimo ir regioninių sutrikimų. Tačiau šis argumentas dažnai ignoruoja kritinį kontrargumentą — abstrakcijos sluoksnis, kurį kuriate debesies perkeliamumui, pats yra priklausomybės forma. Tampate priklausomi nuo savo abstrakcijos, o ne nuo debesies teikėjo. Kubernetes yra šio šablono pavyzdys. Komandos jį priima dėl debesies perkeliamumo, tik atranda, kad jų tikrosios priklausomybės — valdomos duomenų bazės, tapatybės sistemos, apkrovos balansavimo priemonės, objektų saugykla — visos yra giliai specifinės konkrečiam debesiui. Kubernetes sluoksnis perkeliamas; viskas, kas prie jo prijungta — ne.
Duomenų Gravitacija: Jėga, Laikanti Jus Viename Debesyje
Duomenų gravitacija yra bene labiausiai neįvertinta jėga debesų architektūroje. Koncepcija paprasta: duomenys pritraukia programas ir paslaugas. Kuo daugiau duomenų sukaupiate konkrečiame debesies regione, tuo stipresnė gravitacinė trauka, laikanti jūsų skaičiavimus, analitiką ir ML darbo krūvius kartu su tais duomenimis. Terabaitų perkėlimas tarp debesų yra ne tik brangus — išėjimo mokesčiai nuo 0,08 iki 0,12 USD už GB greitai kaupiasi dideliu mastu — jis taip pat lėtas ir įneša delsą, galinčią sugriauti realaus laiko apdorojimo konvejerius. Daugiadubesų strategija, dalijanti skaičiavimus tarp teikėjų, kai duomenys gyvena daugiausia viename debesyje, sukuria nuolatinį tarpdebesiinio duomenų perdavimo mokestį. Praktinė išvada: daugiadubesiai geriausiai veikia, kai darbo krūviai silpnai susieti ir nesidalija dideliais duomenų rinkiniais.
Kada Daugiadubesių Strategija Iš Tikrųjų Prasminga
Yra pagrįstų scenarijų, kuriuose daugiadubesių architektūra teikia tikrą vertę:
- Reguliavimo ir duomenų suverenumo reikalavimai — kai kurios pramonės šakos ir jurisdikcijos reikalauja, kad tam tikros duomenų kategorijos būtų konkrečiuose regionuose arba valstybės sertifikuotoje infrastruktūroje. Sveikatos priežiūros platforma, aptarnaujanti ES ir Artimųjų Rytų rinkas, gali turėti laikyti pacientų duomenis ES suvereniniame debesyje, kartu naudodama AWS skaičiavimams regionuose, kur joks vietinis debesis neatitinka sertifikavimo reikalavimų.
- Geriausių paslaugų pasirinkimas — Google Cloud BigQuery ir Vertex AI duomenų analitikai ir ML, AWS plačiausiam paslaugų katalogui ir brandžiai serverless ekosistemai, Azure glaudžiai Microsoft 365 ir Active Directory integracijai. Kai darbo krūviai yra tikrai nepriklausomi ir kiekvienas naudojasi konkretaus teikėjo unikaliomis stiprybėmis, sąmoninga daugiadubesių strategija gali suteikti galimybes, kurių nė vienas teikėjas atskirai nesiūlo.
- Susijungimai ir įsigijimai — kai dvi organizacijos susijungia, kiekviena su nusistovėjusia debesies infrastruktūra skirtinguose teikėjuose, skubaus perkėlimo į vieną debesį primetimas dažnai yra rizikingesnis ir brangesnis nei laikinas daugiadubesių veikimas palaipsniui konsoliduojant. Esminis žodis yra laikinai — tai turėtų lydėti apgalvotas migracijos planas, o ne nuolatinė daugiadubesių strategija kaip numatytasis pasirinkimas.
Abstrakcijos Sluoksniai ir Kaštų Optimizavimas
Jei pasirenkate daugiadubesų strategiją, abstrakcijos sluoksnis, kurį pasirinksite, apibrėš jūsų patirtį. Infrastruktūros lygmenyje Terraform išlieka auksiniu standartu — jo teikėjų modelis palaiko visus pagrindinius debesis su nuoseklia HCL sintakse. Programų lygmenyje Kubernetes su paslaugų tinklu, tokiu kaip Istio, užtikrina darbo krūvių perkeliamumą, nors aplinkinės valdomos paslaugos lieka specifinės debesiui. Besiformuojanti debesims agnostinių platformų kategorija — įrankiai kaip Pulumi, Crossplane ir Dapr — sumažina, bet nepanaikina abstrakcijos mokesčio. Kaštų optimizavimas daugiadubesėse aplinkose reikalauja specialių įrankių. Debesims savos kaštų priemonės mato tik savo teikėją. Daugiadubesių kaštų valdymo platformos, tokios kaip CloudHealth, Spot by NetApp ar Infracost, suteikia reikiamą vieningą matomumą. Bendri daugiadubesių kaštai apima ne tik debesies sąskaitas, bet ir inžinerinį laiką, skiriamą lygiagrečiai ekspertizei, įrankiams ir operacinėms procedūroms palaikyti.
Daugiadubesių strategija yra strategija, o ne architektūrinis šablonas. Sprendimas ją priimti turėtų būti grindžiamas konkrečiais verslo reikalavimais — reguliavimo atitiktimi, tikrais geriausių paslaugų poreikiais ar susijungimų ir įsigijimų realybe — o ne neaiškia baime dėl tiekėjo priklausomybės. Daugumai organizacijų gilus investavimas į vieno debesies teikėjo ekosistemą duoda geresnį našumą, mažesnius kaštus ir paprastesnes operacijas nei darbo krūvių paskirstymas tarp kelių teikėjų. OKINT Digital padedame organizacijoms objektyviai įvertinti savo debesies strategiją, projektuoti daugiadubesių architektūras ten, kur jos tikrai pagrįstos, ir kurti abstrakcijos sluoksnius, kaštų valdymą ir operacines praktikas, paverčiančias daugiadubesių strategiją valdoma, o ne nuolatinio trinties šaltiniu.
Norite aptarti šias temas nuodugniau?
Mūsų komanda pasiruošusi architektūros peržiūroms ir strateginėms sesijoms.
Suplanuoti konsultaciją →