Jsme nadšeni, že můžeme Transform 2022 osobně přivést zpět 19. července a prakticky 20. až 28. července. Připojte se k lídrům v oblasti umělé inteligence a dat a získejte zasvěcené rozhovory a vzrušující příležitosti k vytváření sítí. Zaregistrujte se ještě dnes!
Do roku 2025 bude mít 85 % podniků princip cloud-first – efektivnější způsob hostování dat spíše než on-premise. Posun ke cloud computingu umocněný COVID-19 a vzdálenou prací znamenal pro společnosti celou řadu výhod: nižší náklady na IT, vyšší efektivitu a spolehlivé zabezpečení.
S pokračujícím boomem tohoto trendu roste také hrozba přerušení a výpadků služeb. Poskytovatelé cloudu jsou vysoce spolehliví, ale „nejsou imunní vůči selhání“. V prosinci 2021 společnost Amazon oznámila, že zaznamenala postižení několika rozhraní API Amazon Web Services (AWS) a během několika minut došlo k výpadku mnoha široce používaných webových stránek.
Jak tedy mohou společnosti zmírnit cloudová rizika, připravit se na další nedostatek AWS a uspokojit náhlé výkyvy poptávky?
Odpovědí je škálovatelnost a elasticita – dva základní aspekty cloud computingu, které jsou velkým přínosem pro podniky. Promluvme si o rozdílech mezi škálovatelností a elasticitou a uvidíme, jak je lze vybudovat na úrovni cloudové infrastruktury, aplikací a databází.
Pochopte rozdíl mezi škálovatelností a elasticitou
Škálovatelnost i elasticita souvisí s počtem požadavků, které lze v cloudovém systému provést současně – vzájemně se nevylučují; oba mohou být podporovány samostatně.
Škálovatelnost je schopnost systému reagovat na to, jak se počet uživatelů a provoz v průběhu času postupně zvyšují. Strategicky je proto plánován dlouhodobý růst. Většina B2B a B2C aplikací, které získávají využití, to bude vyžadovat pro zajištění spolehlivosti, vysokého výkonu a provozuschopnosti.
Po několika menších změnách konfigurace a kliknutí na tlačítka během několika minut může společnost snadno rozšířit nebo snížit svůj cloudový systém. V mnoha případech to lze automatizovat pomocí cloudových platforem s škálovacími faktory aplikovanými na úrovni serveru, clusteru a sítě, což snižuje náklady na inženýrskou práci.
Elasticita je schopnost systému zůstat reagovat během krátkodobých nárazů nebo vysokých okamžitých špiček zátěže. Některé příklady systémů, které pravidelně čelí problémům s elasticitou, zahrnují aplikace pro prodej vstupenek NFL, aukční systémy a pojišťovací společnosti během přírodních katastrof. V roce 2020 se NFL mohla opřít o AWS při živém vysílání svého virtuálního návrhu, když potřebovala mnohem větší cloudovou kapacitu.
Firma, která zažívá nepředvídatelnou pracovní zátěž, ale nechce předem plánovanou strategii škálování, může hledat elastické řešení ve veřejném cloudu s nižšími náklady na údržbu. To by bylo spravováno poskytovatelem třetí strany a sdíleno s více organizacemi využívajícími veřejný internet.
Má tedy vaše firma předvídatelné pracovní zatížení, vysoce variabilní, nebo obojí?
Vypracujte možnosti škálování s cloudovou infrastrukturou
Pokud jde o škálovatelnost, podniky si musí dávat pozor na nadměrné nebo nedostatečné poskytování. K tomu dochází, když technické týmy neposkytnou kvantitativní metriky týkající se požadavků na zdroje pro aplikace nebo když koncová myšlenka škálování není v souladu s obchodními cíli. K určení správné velikosti řešení je nezbytné průběžné testování výkonu.
Vedoucí obchodníci, kteří si toto přečtou, musí promluvit se svými technickými týmy, aby zjistili, jak objevují svá schémata poskytování cloudu. IT týmy by měly neustále měřit dobu odezvy, počet požadavků, zatížení CPU a využití paměti, aby sledovaly náklady na zboží (COG) spojené s náklady na cloud.
Organizace mají k dispozici různé techniky škálování založené na obchodních potřebách a technických omezeních. Tak co, zvětšíte se, nebo naopak?
Vertikální škálování zahrnuje škálování nahoru nebo dolů a používá se pro aplikace, které jsou monolitické, často vytvořené před rokem 2017 a může být obtížné je refaktorovat. Zahrnuje přidání dalších zdrojů, jako je RAM nebo výpočetní výkon (CPU) na váš stávající server, když máte zvýšené pracovní zatížení, ale to znamená, že škálování má limit založený na kapacitě serveru. Nevyžaduje žádné změny architektury aplikace, protože stejnou aplikaci, soubory a databázi přesouváte na větší stroj.
Horizontální škálování zahrnuje škálování dovnitř nebo ven a přidávání dalších serverů do původní cloudové infrastruktury, aby fungovaly jako jeden systém. Každý server musí být nezávislý, aby bylo možné servery přidávat nebo odebírat samostatně. Zahrnuje mnoho architektonických a designových úvah týkajících se vyvažování zátěže, správy relací, ukládání do mezipaměti a komunikace. Migrace starších (nebo zastaralých) aplikací, které nejsou navrženy pro distribuované výpočty, musí být pečlivě refaktorovány. Horizontální škálování je zvláště důležité pro podniky se službami vysoké dostupnosti, které vyžadují minimální prostoje a vysoký výkon, úložiště a paměť.
Pokud si nejste jisti, která technika škálování lépe vyhovuje vaší společnosti, možná budete muset zvážit platformu pro automatizaci cloudového inženýrství od třetí strany, která vám pomůže řídit vaše potřeby, cíle a implementaci škálování.
Zvažte, jak aplikační architektury ovlivňují škálovatelnost a elasticitu
Podívejme se na jednoduchou zdravotnickou aplikaci – která platí i pro mnoho dalších odvětví – abychom viděli, jak ji lze vyvíjet napříč různými architekturami a jak to ovlivňuje škálovatelnost. a elasticitu. Zdravotnické služby byly silně pod tlakem a během pandemie COVID-19 se musely drasticky rozšířit a mohly těžit z cloudových řešení.
Na vysoké úrovni existují dva typy architektur: monolitická a distribuovaná. Monolitické (nebo vrstvené, modulární monolity, potrubí a mikrokernel) architekturynejsou nativně vytvořeny pro efektivní škálovatelnost a elasticitu – všechny moduly jsou obsaženy v hlavní části aplikace a v důsledku toho je celá aplikace nasazena jako jeden celek. Existují tři typy distribuovaných architektur: řízené událostmi, mikroslužby a prostorově založené.
Jednoduchá zdravotnická aplikace má:
Služby nemocnice jsou velmi žádané a aby podpořily růst, potřebují rozšířit moduly registrace pacientů a plánování schůzek. To znamená, že potřebují škálovat pouze portál pacienta, nikoli portál lékaře nebo ordinace. Pojďme si rozebrat, jak lze tuto aplikaci postavit na jednotlivých architekturách.
Monolitická architektura
Technologické startupy, mimo jiné ve zdravotnictví, často využívají tento tradiční, jednotný model pro návrh softwaru kvůli výhodě rychlosti uvedení na trh. Není to však optimální řešení pro podniky vyžadující škálovatelnost a elasticitu. Je to proto, že existuje jediná integrovaná instance aplikace a centralizovaná jediná databáze.
Pokud jde o škálování aplikací, přidání dalších instancí aplikace s vyrovnáváním zátěže skončí škálováním dalších dvou portálů a také portálu pro pacienty, i když to podnik nepotřebuje.
Většina monolitických aplikací používá monolitickou databázi – jeden z nejdražších cloudových zdrojů. Náklady na cloud rostou exponenciálně s rozsahem a toto uspořádání je drahé, zejména pokud jde o dobu údržby pro vývojové a provozní inženýry.
Dalším aspektem, který činí monolitické architektury nevhodnými pro podporu elasticity a škálovatelnosti, je střední doba do spuštění (MTTS) – doba, kterou trvá spuštění nové instance aplikace. Obvykle to trvá několik minut kvůli velkému rozsahu aplikace a databáze: Inženýři musí vytvořit podpůrné funkce, závislosti, objekty a fondy připojení a zajistit zabezpečení a konektivitu k dalším službám.
Architektura řízená událostmi
Architektura řízená událostmi je pro škálování a elasticitu vhodnější než monolitická architektura. Například zveřejní událost, když se stane něco nápadného. Mohlo by to vypadat jako nakupování na webu elektronického obchodu během rušného období, objednání položky, ale pak vám přijde e-mail, že není skladem. Asynchronní zasílání zpráv a fronty poskytují zpětný tlak, když je frontend škálován bez škálování back-endu řazením požadavků do fronty.
V této případové studii zdravotnické aplikace by tato distribuovaná architektura znamenala, že každý modul je vlastním procesorem událostí; existuje flexibilita pro distribuci nebo sdílení dat v rámci jednoho nebo více modulů. Na úrovni aplikace a databáze existuje určitá flexibilita, pokud jde o rozsah, protože služby již nejsou propojeny.
Architektura mikroslužeb
Tato architektura nahlíží na každou službu jako na jednoúčelovou službu, což podnikům umožňuje škálovat každou službu nezávisle a vyhnout se zbytečné spotřebě cenných zdrojů. Pro škálování databáze lze perzistenční vrstvu navrhnout a nastavit výhradně pro každou službu pro individuální škálování.
Spolu s architekturou řízenou událostmi jsou tyto architektury dražší z hlediska cloudových zdrojů než monolitické architektury při nízké úrovni využití. S rostoucí zátěží, implementacemi s více nájemci a v případech, kdy dochází k dopravním nárazům, jsou však ekonomičtější. MTTS je také velmi efektivní a lze jej měřit během několika sekund díky jemnozrnným službám.
Vzhledem k obrovskému množství služeb a distribuované povaze však může být ladění obtížnější a mohou být vyšší náklady na údržbu, pokud služby nejsou plně automatizované.
Architektura založená na prostoru
Tato architektura je založena na principu zvaném tuple-spaced processing – více paralelních procesorů se sdílenou pamětí. Tato architektura maximalizuje jak škálovatelnost, tak elasticitu na úrovni aplikace a databáze.
Všechny interakce aplikací probíhají s datovou mřížkou v paměti. Volání do mřížky jsou asynchronní a procesory událostí se mohou škálovat nezávisle. Při škálování databáze je k dispozici zapisovač dat na pozadí, který čte a aktualizuje databázi. Všechny operace vložení, aktualizace nebo odstranění jsou odeslány do zapisovače dat příslušnou službou a zařazeny do fronty k vyzvednutí.
MTTS je extrémně rychlý, obvykle trvá několik milisekund, protože všechny datové interakce probíhají s daty v paměti. Všechny služby se však musí připojit k brokerovi a počáteční zatížení mezipaměti musí být vytvořeno pomocí čtečky dat.
V tomto digitálním věku chtějí společnosti podle potřeby zvýšit nebo snížit zdroje IT, aby vyhověly měnícím se požadavkům. Prvním krokem je přechod od velkých monolitických systémů k distribuované architektuře, abychom získali konkurenční výhodu – to udělaly Netflix, Lyft, Uber a Google. Výběr architektury je však subjektivní a rozhodnutí musí být přijímána na základě schopností vývojářů, průměrného zatížení, špičkového zatížení, rozpočtových omezení a cílů růstu podnikání.
Sashank je sériový podnikatel s velkým zájmem o inovace.
DataDecisionMakers
Vítejte v komunitě VentureBeat!
DataDecisionMakers je místo, kde odborníci, včetně technických lidí pracujících s daty, mohou sdílet poznatky a inovace související s daty.
Pokud si chcete přečíst o nejmodernějších nápadech a aktuálních informacích, osvědčených postupech a budoucnosti datových a datových technologií, připojte se k nám na DataDecisionMakers.
Dokonce můžete zvážit možnost přispět vlastním článkem!
Přečtěte si více od DataDecisionMakers
