Ajatusjohtajat

Valmistaudu nyt seuraavaan pilvipalvelun katkoksessa

mm
Lisää Unite.AI suosikkilähteisiisi Google-palvelussa

Suurten pilvipalvelujen häiriöt, kuten tämän viikon AWS:n häiriö, ovat väistämättömiä. Nämä neljä menetelmää voivat auttaa yritystäsi selviytymään.

Laskettujen tuotantotuntien kanssa, rahoitusjärjestelmien häiriintyminen miljoonille käyttäjille, ja mahdollisesti satojen miljardien dollarien menetys, tämän viikon AWS:n häiriö oli epäilemättä kamala päivä maailman IT-tiimille. Tietysti se oli myös pahin maailmanlaajuinen pilvipalvelujen katastrofi viimeisen kerran… ja kunnes seuraava.

Riippumatta siitä, oletko AWS:ää, GCP:ä, Azurea tai jotain muuta alustaa, suuret häiriöt ovat pilvipalvelujen todellisuuden osa. Mitä yrityksesi voi tehdä, jotta se voi vähentää iskun vaikutusta? Alla on neljä askelta, joita tiimisi voi tehdä välittömästi.

Tuo skeptisisyysi – ja tee kotitehtäväsi.

Usein tiimit kohtaavat onnettomuuden kävelemällä pilvipalvelujen sopimuksiin olettaen, että suuret pilvipalveluyritykset ovat luonnostaan luotettavia. Totuudenmukaisesti, luotetuimmat yritykset ovat ansainneet maineensa jostain syystä. Samalla, jokainen pilvi ja hyperscaler tarjoaa laajan valikoiman infrastruktuurivaihtoehtoja – AWS North America -alueella on 31 saatavuusvyöhykettä ja 31 reunaverkon sijaintia – ja joistakin vaihtoehdoista on paljon luotettavampia kuin toisista.

Todellakin, AWS:n US-EAST-1 -alue, joka aiheutti tämän viikon häiriön, oli aiheuttanut suuria häiriöitä vuosina 2020, 2021 ja 2023, ja se oli jo pitkään tiedetty tietyissä IT-piireissä vähiten luotettavana alueena. Monet yritykset ymmärsivät todennäköisesti tilanteen, mutta tekivät laskelmallisen riskin alueen matalan hinnan ja runsaiden tarjousten vuoksi. Mutta häiriön laajuuden vuoksi on mahdotonta olla ajattelematta, kuinka moni yritys oli täysin yllättynyt – ja olisi varmasti valinnut luotettavamman alueen, jos olisi ollut tietoinen vaihtoehtojen vaihtelusta. Olen henkilökohtaisesti tavannut IT-johtajia, jotka päättivät siirtyä muihin AWS-alueisiin vain sen jälkeen, kun heillä oli huonoja kokemuksia US-EAST-1 -alueella aiemmin.

Opetus tästä on tehdä kotitehtäväsi pilvipalvelujen infrastruktuurivaihtoehtojen suhteen, riippumatta siitä, mitä pilveä käytät. Paikkoja, joista aloittaa, ovat ilmaiset työkalut, kuten cloudprice, Cloudping, ja hyperskalerin tarjoamat Cloud Service Health -työkalujen historialliset näkymät.

Valitse siirrettävä pilvi yli cloud-natiivin.

Kun suunnittelet pilvipalvelujen konfiguraatioita, yksinkertaisin reitti on mennä cloud-natiiviin. Mutta vaikka on kätevää valita sovelluksia, jotka on valmistettu ja pilvipalveluntarjoajalle, nämä cloud-natiivit vaihtoehdot jättävät sinut alttiina, jos pilvesi menee pois.

Välttääksesi tämän ylimäisen kerroksen pilvipalvelujen riippuvuutta, valitse riippumattomia ja/tai avoimia lähteitä, missä mahdollista. Muutamia esimerkkejä korvikkeista ovat alla:

Kategoria

Alkuperäinen tarjous

Avoimet vaihtoehdot sisältävät…

Tunnistus ja identiteetti

AWS Cognito

Keycloak

Haku

Azure Monitor

Elasticsearch

Relaatiotietokannat

Google Cloud SQL

PostgreSQL

NoSQL-tietokannat

AWS DynamoDB

MongoDB

Säiliöiden orkestraatio

Azure Kubernetes Service (AKS)

Kubernetes

Valvonta ja havainnointi

Google Cloud Monitoring

Prometheus + Grafana

Viestijonot

AWS SQS/SNS

Apache Kafka

Objektien tallennus

Azure Blob Storage

MinIO

API-portti

Google Cloud API Gateway

Kong

Todellakin, rakentaa enemmän pilvipinoasi itse tarkoittaa enemmän työtä tiimillesi. Mutta kokemukseni mukaan, kun olet saanut infrastruktuurin toimimaan, ei ole juuri eroa lisätessäsi työmäärää vakiintuneeseen kotiinrakennettuun infrastruktuuriin tai toimintaan cloud-natiivisessa ympäristössä. Ja hyödyt kestävyyden suhteen – ei puhuen cloud-riippuvuuden vähentämisestä – tekevät riippumattomista vaihtoehdoista erittäin arvokkaita.

Suunnittele epäonnistumisen varalle.

Koska pilvipalvelujen häiriöt tapahtuvat, varmista, että suunnittelet tuotteidesi pilvipalvelujen häiriöitä ajatellen. Yksi esimerkki on Datadog: vuonna 2023 tapahtuneessa tapauksessa yritys menetti yhtäkkiä pääsyn yli puoleen tuotantoympäristönsä Kubernetes -solmuista ja suunnitteli uudelleen katastrofinsuunnittelunsa vastaavasti. Muutokset käsittivät arkkitehtonisten pullonkaulien poistamisen ja teknisen velan käsittelyn, jotta osittaiset häiriöt eivät leviäisi järjestelmän läpi, parantamalla dataa ottamista ja tallentamista suuremman datan saatavuuden aikana häiriöiden aikana, ja rakentamalla järjestelmiä, jotka voivat palautua automaattisesti suuressa mittakaavassa. Yksi hyvä paikka aloittaa matkallasi on seurata Datadogin suositusta “aloita siitä, mikä on tärkeää loppukäyttäjälle”, ja rakentaa suojausjärjestelmiä, jotka suojaavat sitä, mikä on tärkeintä.

Toimi vähintään kahdella pilvialustalla.

Todellakin, paras tapa välttää pilvipalvelujen riippuvuus on monipilviympäristön toimintavarmuus. Saavuttaminen todellista monipilviympäristön liikkuvuutta on valtava tehtävä monille yrityksille, koska on erittäin vaikea kääntää infrastruktuuria yhdestä pilvestä toiseen. Mutta rakentaminen infrastruktuuria vain kahdelle pilvelle on vahva – ja usein toteutettavissa – paikka aloittaa. Kriittinen tämän toimimiseen on, että sinulla on tiimi, jossa on asiantuntija kussakin pilvessä, jota käytät.

Todellakin, mitään ei voi suojella yrityksiä täysin massiivien häiriöiden vaikutukselta, kuten tämän viikon. Mutta oikean due diligence -tutkimuksen, siirrettävän pilviympäristön, epäonnistumisen suunnittelun ja “kaksoispilven” käytön avulla, joka on askel kohti todellista monipilviympäristöä, yritykset voivat olla paljon ketterämpiä, kun seuraava (ja valitettavasti väistämätön) suuri pilvipalvelujen häiriö tapahtuu.

Harshit Omar on FluidCloudin perustaja ja tekninen johtaja, jossa hän rakentaa pilvi-infrastruktuurin tulevaisuutta - mahdollistaen yritysten siirtää, monistaa ja optimoida työkuormia yli useiden pilviympäristöjen. Aikaisemmin hän oli Accuricsin ensimmäinen insinööri, jossa hän johti ydinkehitysponnisteluja sen käytäntömoottorille ja pilviturvallisuuspalvelimelle.

Syvällä asiantuntemuksella Go:ssa, Kubernetesissa, Terraformissa ja pilviturvallisuudessa, Harshit on viettänyt yli vuosikymmenen suunnittelemassa kestäviä järjestelmiä AWS:n, Azure:n ja GCP:n yli.

Hänen tehtävänsä nyt on poistaa pilvirajat ja tehdä infrastruktuurista yhtä siirrettävää ja kestävää kuin koodi.