Olemme innoissamme voidessamme tuoda Transform 2022:n takaisin henkilökohtaisesti 19. ja 20.–28. heinäkuuta. Liity tekoäly- ja datajohtajien joukkoon oivaltavaa keskustelua ja jännittäviä verkostoitumismahdollisuuksia varten. Rekisteröidy tänään!
Vuoteen 2025 mennessä 85 %:lla yrityksistä on pilvi-first-periaate, joka on tehokkaampi tapa isännöidä dataa kuin paikan päällä. COVID-19:n ja etätyön vahvistama siirtyminen pilvipalveluihin on merkinnyt yrityksille monia etuja: alemmat IT-kustannukset, lisääntynyt tehokkuus ja luotettava tietoturva.
Kun tämä trendi jatkaa nousuaan, myös palveluhäiriöiden ja katkosten uhka kasvaa. Pilvipalveluntarjoajat ovat erittäin luotettavia, mutta ne "eivät ole immuuneja epäonnistumiselle". Joulukuussa 2021 Amazon ilmoitti nähneensä useiden Amazon Web Services (AWS) -sovellusliittymien vaikutuksen, ja muutamassa minuutissa monet laajalti käytetyt verkkosivustot katosivat.
Joten, miten yritykset voivat pienentää pilviriskiä, valmistautua seuraavaan AWS-pulaan ja mukautua äkillisiin kysyntäpiikkiin?
Vastaus on skaalautuvuus ja joustavuus – kaksi pilvipalvelun olennaista näkökohtaa, joista on paljon hyötyä yrityksille. Puhutaan skaalautuvuuden ja joustavuuden eroista ja katsotaan, miten niitä voidaan rakentaa pilviinfrastruktuurin, sovellus- ja tietokantatasoilla.
Ymmärrä skaalautuvuuden ja joustavuuden välinen ero
Sekä skaalautuvuus että joustavuus liittyvät pyyntöjen määrään, jotka voidaan tehdä samanaikaisesti pilvijärjestelmässä – ne eivät sulje toisiaan pois. molempia on ehkä tuettava erikseen.
Skaalautuvuus tarkoittaa järjestelmän kykyä pysyä reagoivana, kun käyttäjien määrä ja liikenne kasvavat vähitellen ajan myötä. Siksi pitkän aikavälin kasvu on strategisesti suunniteltu. Useimmat B2B- ja B2C-sovellukset, jotka saavat käyttöä, vaativat tätä luotettavuuden, korkean suorituskyvyn ja käytettävyyden varmistamiseksi.
Muutamalla pienellä konfiguraatiomuutoksella ja painikkeiden napsautuksella yritys voi muutamassa minuutissa skaalata pilvijärjestelmää ylös tai alas helposti. Monissa tapauksissa tämä voidaan automatisoida pilvialustoilla palvelin-, klusteri- ja verkkotasolla sovellettavien mittakaavatekijöiden avulla, mikä vähentää suunnittelutyökustannuksia.
Elastisuus on järjestelmän kykyä pysyä reagoivana lyhytaikaisten purskeiden tai korkeiden hetkellisten kuormituspiikkien aikana. Joitakin esimerkkejä järjestelmistä, jotka kohtaavat säännöllisesti joustoongelmia, ovat NFL-lippusovellukset, huutokauppajärjestelmät ja vakuutusyhtiöt luonnonkatastrofien aikana. Vuonna 2020 NFL pystyi tukeutumaan AWS:ään suoratoistamaan virtuaalista luonnostaan, kun se tarvitsi paljon enemmän pilvikapasiteettia.
Yritys, jolla on arvaamattomia työkuormia, mutta joka ei halua ennalta suunniteltua skaalausstrategiaa, saattaa etsiä joustavaa ratkaisua julkisesta pilvestä pienemmillä ylläpitokustannuksilla. Tätä hallinnoisi kolmannen osapuolen palveluntarjoaja, ja se jaetaan useiden julkista Internetiä käyttävien organisaatioiden kanssa.
Joten, onko yritykselläsi ennakoitavissa olevia työkuormia, erittäin vaihtelevia vai molempia?
Harjoittele skaalausvaihtoehtoja pilviinfrastruktuurin avulla
Skaalautuvuuden osalta yritysten on varottava yli- tai alikäyttöä. Näin tapahtuu, kun teknologiatiimit eivät tarjoa kvantitatiivisia mittareita sovellusten resurssivaatimuksista tai skaalauksen taustaidea ei ole linjassa liiketoimintatavoitteiden kanssa. Oikean kokoisen ratkaisun määrittämiseksi jatkuva suorituskyvyn testaus on välttämätöntä.
Tätä lukevien yritysjohtajien on keskusteltava tekniikkatiimiensä kanssa saadakseen selville, kuinka he löytävät pilvipalveluiden kaaviot. IT-tiimien tulisi jatkuvasti mitata vasteaikaa, pyyntöjen määrää, prosessorin kuormitusta ja muistin käyttöä seuratakseen pilvikuluihin liittyviä tavarakustannuksia (COG).
Organisaatioiden käytettävissä on erilaisia skaalaustekniikoita, jotka perustuvat liiketoiminnan tarpeisiin ja teknisiin rajoituksiin. Joten, suurennatko vai vähennätkö?
Pystysuuntainen skaalaus sisältää skaalauksen ylös- tai alaspäin, ja sitä käytetään sovelluksissa, jotka ovat monoliittisia, usein rakennettu ennen vuotta 2017 ja joita voi olla vaikea heijastaa uudelleen. Se edellyttää resurssien, kuten RAM-muistin tai prosessointitehon (CPU) lisäämistä olemassa olevaan palvelimeesi, kun työmääräsi lisääntyy, mutta tämä tarkoittaa, että skaalauksella on raja, joka perustuu palvelimen kapasiteettiin. Se ei vaadi sovellusarkkitehtuurin muutoksia, koska siirrät saman sovelluksen, tiedostot ja tietokannan suurempaan koneeseen.
Horisontaalinen skaalaus tarkoittaa skaalausta sisään tai ulos ja palvelimien lisäämistä alkuperäiseen pilviinfrastruktuuriin toimimaan yhtenä järjestelmänä. Jokaisen palvelimen on oltava itsenäinen, jotta palvelimia voidaan lisätä tai poistaa erikseen. Se sisältää monia arkkitehtonisia ja suunnittelunäkökohtia, jotka liittyvät kuormituksen tasapainottamiseen, istunnonhallintaan, välimuistiin ja viestintään. Siirrettävät vanhat (tai vanhentuneet) sovellukset, joita ei ole suunniteltu hajautettuun tietojenkäsittelyyn, on muokattava huolellisesti uudelleen. Vaakasuuntainen skaalaus on erityisen tärkeää yrityksille, joilla on korkean käytettävyyden palvelut, jotka vaativat mahdollisimman vähän seisokkeja ja korkeaa suorituskykyä, tallennustilaa ja muistia.
Jos et ole varma, mikä skaalaustekniikka sopii paremmin yrityksellesi, sinun on ehkä harkittava kolmannen osapuolen pilvisuunnittelun automaatioalustaa, joka auttaa hallitsemaan skaalaustarpeitasi, tavoitteitasi ja toteutustasi.
Punnittele, miten sovellusarkkitehtuurit vaikuttavat skaalautumiseen ja joustavuuteen
Otetaan yksinkertainen terveydenhuollon sovellus – joka koskee myös monia muita toimialoja – nähdäksemme, kuinka sitä voidaan kehittää eri arkkitehtuurien välillä ja miten se vaikuttaa skaalautumiseen. ja joustavuus. Terveydenhuoltopalveluihin kohdistui kovia paineita, ja niiden oli laajennettava huomattavasti COVID-19-pandemian aikana, ja ne olisivat voineet hyötyä pilvipohjaisista ratkaisuista.
Korkealla tasolla arkkitehtuuria on kahdenlaisia: monoliittisia ja hajautettuja. Monoliittiset (tai kerrostetut, modulaariset monoliitti-, putki- ja mikroytimet) arkkitehtuurit eivät ole alkuperäisesti rakennettuja tehokkaan skaalautuvuuden ja joustavuuden takaamiseksi – kaikki moduulit sisältyvät sovelluksen pääosaan. ja tämän seurauksena koko sovellus otetaan käyttöön yhtenä kokonaisuutena. Hajautettuja arkkitehtuureja on kolmenlaisia: tapahtumapohjaisia, mikropalveluita ja avaruuspohjaisia.
Yksinkertaisessa terveydenhuoltosovelluksessa on:
Sairaalan palveluilla on suuri kysyntä, ja kasvun tukemiseksi niiden on skaalattava potilaiden rekisteröinti- ja ajanvarausmoduuleja. Tämä tarkoittaa, että heidän tarvitsee vain skaalata potilasportaalia, ei lääkärin tai toimiston portaaleja. Selvitetään, kuinka tämä sovellus voidaan rakentaa jokaiselle arkkitehtuurille.
Monoliittinen arkkitehtuuri
Teknologiset startup-yritykset, myös terveydenhuollon alalla, käyttävät usein tätä perinteistä, yhtenäistä ohjelmistosuunnittelumallia, koska niillä on nopeus markkinoille. Mutta se ei ole optimaalinen ratkaisu yrityksille, jotka vaativat skaalautuvuutta ja joustavuutta. Tämä johtuu siitä, että sovelluksessa on yksi integroitu esiintymä ja keskitetty yksittäinen tietokanta.
Sovellusten skaalausta varten lisäämällä useampia sovelluksen esiintymiä kuormituksen tasapainotuksella, kaksi muuta portaalia sekä potilasportaalia skaalataan, vaikka yritys ei sitä tarvitsekaan.
Useimmat monoliittiset sovellukset käyttävät monoliittista tietokantaa, joka on yksi kalleimmista pilviresursseista. Pilvikustannukset kasvavat eksponentiaalisesti mittakaavan myötä, ja tämä järjestely on kallis erityisesti kehitys- ja käyttöinsinöörien ylläpitoajan suhteen.
Toinen seikka, joka tekee monoliittisista arkkitehtuureista sopimattomia tukemaan joustavuutta ja skaalautuvuutta, on keskimääräinen käynnistysaika (MTTS) – aika, joka kuluu sovelluksen uuden esiintymän käynnistymiseen. Se kestää yleensä useita minuutteja sovelluksen ja tietokannan suuren laajuuden vuoksi: Insinöörien on luotava tukitoiminnot, riippuvuudet, objektit ja yhteysvarastot sekä varmistettava turvallisuus ja liitettävyys muihin palveluihin.
Tapahtumapohjainen arkkitehtuuri
Tapahtumalähtöinen arkkitehtuuri sopii monoliittista arkkitehtuuria paremmin skaalaus- ja joustavuussyistä. Se esimerkiksi julkaisee tapahtuman, kun jotain havaittavaa tapahtuu. Se voi näyttää siltä, että ostaisit verkkokauppasivustolla kiireisenä aikana, tilaat tuotteen, mutta sitten vastaanotat sähköpostin, jossa sanotaan, että tuote on loppunut. Asynkroninen viestintä ja jonot tarjoavat vastapainetta, kun etupää skaalataan ilman, että takapäätä skaalataan jonotuspyyntöjen avulla.
Tässä terveydenhuollon sovellusten tapaustutkimuksessa tämä hajautettu arkkitehtuuri tarkoittaisi, että jokainen moduuli on oma tapahtumaprosessori. on joustavuutta jakaa tai jakaa tietoja yhden tai useamman moduulin välillä. Sovellus- ja tietokantatasolla on jonkin verran joustavuutta mittakaavan suhteen, koska palveluita ei enää yhdistetä.
Mikropalveluarkkitehtuuri
Tämä arkkitehtuuri pitää jokaisen palvelun yksittäisenä palveluna, mikä antaa yrityksille mahdollisuuden skaalata jokaista palvelua itsenäisesti ja välttää arvokkaiden resurssien tarpeettoman kulutuksen. Tietokannan skaalausta varten pysyvyyskerros voidaan suunnitella ja määrittää yksinomaan kullekin palvelulle yksittäistä skaalausta varten.
Tapahtumalähtöisen arkkitehtuurin ohella nämä arkkitehtuurit maksavat pilviresursseina enemmän kuin monoliittiset arkkitehtuurit vähäisellä käyttötasolla. Kuitenkin lisääntyvien kuormien, useiden vuokralaisten toteutusten ja liikennepurskeiden vuoksi ne ovat taloudellisempia. MTTS on myös erittäin tehokas ja se voidaan mitata sekunneissa hienorakeisten palvelujen ansiosta.
Palveluiden suuren määrän ja hajautetun luonteen vuoksi virheenkorjaus voi kuitenkin olla vaikeampaa ja ylläpitokustannukset voivat olla korkeammat, jos palveluita ei ole täysin automatisoitu.
Avaruuspohjainen arkkitehtuuri
Tämä arkkitehtuuri perustuu periaatteeseen, jota kutsutaan tuple-spaced-käsittelyksi – useisiin rinnakkaisiin prosessoreihin jaetulla muistilla. Tämä arkkitehtuuri maksimoi sekä skaalautuvuuden että joustavuuden sovellus- ja tietokantatasolla.
Kaikki sovellusten vuorovaikutukset tapahtuvat muistissa olevan dataruudukon kanssa. Kutsut verkkoon ovat asynkronisia, ja tapahtumaprosessorit voivat skaalata itsenäisesti. Tietokannan skaalauksessa on taustatietojen kirjoittaja, joka lukee ja päivittää tietokannan. Vastaava palvelu lähettää kaikki lisäys-, päivitys- tai poistotoiminnot tietojen kirjoittajalle ja asettaa ne jonoon noudettavaksi.
MTTS on erittäin nopea ja kestää yleensä muutaman millisekunnin, koska kaikki tietovuorovaikutus tapahtuu muistissa olevien tietojen kanssa. Kaikkien palveluiden on kuitenkin yhdistettävä välittäjään ja välimuistin alkulataus on luotava tiedonlukijalla.
Tänä digitaaliaikana yritykset haluavat lisätä tai vähentää IT-resursseja tarpeen mukaan vastatakseen muuttuviin vaatimuksiin. Ensimmäinen askel on siirtyminen suurista monoliittisista järjestelmistä hajautettuun arkkitehtuuriin kilpailuedun saamiseksi – tämän ovat tehneet Netflix, Lyft, Uber ja Google. Arkkitehtuurin valinta on kuitenkin subjektiivinen, ja päätökset on tehtävä kehittäjien kykyjen, keskimääräisen kuormituksen, huippukuormituksen, budjettirajoitusten ja liiketoiminnan kasvutavoitteiden perusteella.
Sashank on sarjayrittäjä, joka on kiinnostunut innovaatioista.
DataDecisionMakers
Tervetuloa VentureBeat-yhteisöön!
DataDecisionMakers on paikka, jossa asiantuntijat, mukaan lukien datatyötä tekevät tekniset ihmiset, voivat jakaa dataan liittyviä oivalluksia ja innovaatioita.
Jos haluat lukea uusimmista ideoista ja ajankohtaisista tiedoista, parhaista käytännöistä sekä datan ja datatekniikan tulevaisuudesta, liity joukkoomme DataDecisionMakersissa.
Voit jopa harkita oman artikkelisi kirjoittamista!
Lue lisää DataDecisionMakersilta
