Развълнувани сме да върнем Transform 2022 лично на 19 юли и на практика от 20 до 28 юли. Присъединете се към AI и лидери на данни за проницателни разговори и вълнуващи възможности за работа в мрежа. Регистрирайте се днес!
До 2025 г. 85% от предприятията ще имат принцип на първо място в облака — по-ефективен начин за хостване на данни, отколкото локално. Преходът към облачни изчисления, подсилен от COVID-19 и дистанционната работа, означава цял набор от предимства за компаниите: по-ниски ИТ разходи, повишена ефективност и надеждна сигурност.
С тази тенденция, която продължава да процъфтява, нараства и заплахата от смущения в услугите и прекъсвания. Облачните доставчици са много надеждни, но те „не са имунизирани срещу провал“. През декември 2021 г. Amazon съобщи, че е видял множество засегнати API на Amazon Web Services (AWS) и за минути много широко използвани уебсайтове прекъснаха работа.
И така, как компаниите могат да намалят риска от облака, да се подготвят за следващия недостиг на AWS и да се приспособят към внезапни пикове на търсенето?
Отговорът е мащабируемост и еластичност – два основни аспекта на облачните изчисления, които са от голяма полза за бизнеса. Нека да поговорим за разликите между скалируемост и еластичност и да видим как те могат да бъдат изградени на ниво облачна инфраструктура, приложение и база данни.
Разберете разликата между мащабируемост и еластичност
И мащабируемостта, и еластичността са свързани с броя на заявките, които могат да бъдат направени едновременно в облачна система — те не се изключват взаимно; и двете може да се наложи да се поддържат отделно.
Мащабируемостта е способността на системата да остане отзивчива, докато броят на потребителите и трафикът постепенно се увеличава с течение на времето. Следователно стратегически планиран е дългосрочният растеж. Повечето B2B и B2C приложения, които се използват, ще изискват това, за да осигурят надеждност, висока производителност и непрекъсната работа.
С няколко незначителни промени в конфигурацията и щраквания върху бутони, за броени минути една компания може да мащабира облачната си система нагоре или надолу с лекота. В много случаи това може да се автоматизира от облачни платформи с коефициенти на мащаб, приложени на ниво сървър, клъстер и мрежа, намалявайки разходите за инженерен труд.
Еластичността е способността на системата да остане отзивчива по време на краткотрайни изблици или големи мигновени пикове в натоварването. Някои примери за системи, които редовно се сблъскват с проблеми с еластичността, включват приложения за билети на NFL, системи за търгове и застрахователни компании по време на природни бедствия. През 2020 г. NFL успя да разчита на AWS, за да предава на живо своя виртуален проект, когато се нуждаеше от много повече облачен капацитет.
Бизнес, който изпитва непредвидими натоварвания, но не иска предварително планирана стратегия за мащабиране, може да потърси еластично решение в публичния облак с по-ниски разходи за поддръжка. Това ще се управлява от доставчик трета страна и ще се споделя с множество организации, използващи обществения интернет.
И така, вашият бизнес има ли предвидими натоварвания, силно променливи или и двете?
Разработете опции за мащабиране с облачна инфраструктура
Когато става въпрос за мащабируемост, бизнесът трябва да внимава за свръх или недостатъчно предоставяне. Това се случва, когато техническите екипи не предоставят количествени показатели за изискванията за ресурси за приложенията или идеята за мащабиране в задния край не е съобразена с бизнес целите. За да се определи решение с правилен размер, текущото тестване на производителността е от съществено значение.
Бизнес лидерите, които четат това, трябва да говорят със своите технически екипи, за да разберат как откриват своите схеми за осигуряване на облак. ИТ екипите трябва непрекъснато да измерват времето за реакция, броя на заявките, натоварването на процесора и използването на паметта, за да наблюдават разходите за стоки (COG), свързани с разходите за облак.
Има различни техники за мащабиране, достъпни за организациите въз основа на бизнес нуждите и техническите ограничения. И така, ще увеличите или намалите?
Вертикалното мащабиране включва мащабиране нагоре или надолу и се използва за приложения, които са монолитни, често създадени преди 2017 г. и може да са трудни за преработване. Това включва добавяне на повече ресурси като RAM или процесорна мощност (CPU) към вашия съществуващ сървър, когато имате увеличено работно натоварване, но това означава, че мащабирането има лимит въз основа на капацитета на сървъра. Не изисква промени в архитектурата на приложението, тъй като премествате същото приложение, файлове и база данни на по-голяма машина.
Хоризонталното мащабиране включва мащабиране навътре или навън и добавяне на повече сървъри към оригиналната облачна инфраструктура, за да работят като единна система. Всеки сървър трябва да е независим, така че сървърите да могат да се добавят или премахват отделно. Това включва много архитектурни и дизайнерски съображения относно балансирането на натоварването, управлението на сесиите, кеширането и комуникацията. Мигриращите наследени (или остарели) приложения, които не са предназначени за разпределени изчисления, трябва да бъдат преработени внимателно. Хоризонталното мащабиране е особено важно за фирми с услуги с висока наличност, изискващи минимално време на престой и висока производителност, съхранение и памет.
Ако не сте сигурни коя техника за мащабиране е по-подходяща за вашата компания, може да се наложи да помислите за автоматизирана платформа за облачно инженерство на трета страна, която да ви помогне да управлявате вашите нужди, цели и внедряване за мащабиране.
Претеглете как архитектурите на приложенията влияят върху мащабируемостта и еластичността
Нека вземем едно просто приложение за здравеопазване – което се отнася и за много други индустрии – за да видим как то може да бъде разработено в различни архитектури и как това влияе върху мащабируемостта и еластичност. Здравните услуги бяха подложени на силен натиск и трябваше драстично да се разширят по време на пандемията от COVID-19 и можеха да се възползват от базирани на облак решения.
На високо ниво има два типа архитектури: монолитна и разпределена. Монолитните (или многослойни, модулни монолитни, конвейерни и микроядрени) архитектури не са изградени изначално за ефективна скалируемост и еластичност — всички модули се съдържат в основното тяло на приложението и в резултат на това цялото приложение се разгръща като едно цяло. Има три типа разпределени архитектури: управлявани от събития, микроуслуги и пространствено базирани.
Простото здравно приложение има:
Услугите на болницата са много търсени и за да подкрепят растежа, те трябва да разширят модулите за регистрация на пациенти и насрочване на срещи. Това означава, че трябва да мащабират само портала за пациенти, а не порталите на лекаря или офиса. Нека да разберем как това приложение може да бъде изградено на всяка архитектура.
Монолитна архитектура. Но това не е оптимално решение за фирми, изискващи мащабируемост и еластичност. Това е така, защото има един интегриран екземпляр на приложението и централизирана единна база данни.
За мащабиране на приложение, добавянето на повече екземпляри на приложението с балансиране на натоварването завършва с мащабиране на другите два портала, както и на портала за пациенти, въпреки че бизнесът няма нужда от това.
Повечето монолитни приложения използват монолитна база данни — един от най-скъпите облачни ресурси. Разходите за облак растат експоненциално с мащаба и това споразумение е скъпо, особено по отношение на времето за поддръжка за инженерите по разработка и операции.
Друг аспект, който прави монолитните архитектури неподходящи за поддържане на еластичност и скалируемост, е средното време до стартиране (MTTS) — времето, необходимо за стартиране на ново копие на приложението. Обикновено отнема няколко минути поради големия обхват на приложението и базата данни: Инженерите трябва да създадат поддържащите функции, зависимости, обекти и пулове за свързване и да осигурят сигурност и свързаност с други услуги.
Архитектура, управлявана от събития
Архитектурата, управлявана от събития, е по-подходяща от монолитната архитектура за мащабиране и еластичност. Например, той публикува събитие, когато се случи нещо забележимо. Това може да изглежда като пазаруване в сайт за електронна търговия по време на натоварен период, поръчване на артикул, но след това получаване на имейл, че е изчерпан. Асинхронните съобщения и опашките осигуряват обратен натиск, когато предният край се мащабира, без да мащабира задния край чрез заявки за опашка.
В този казус за приложение в здравеопазването тази разпределена архитектура би означавала, че всеки модул е свой собствен процесор за събития; има гъвкавост за разпространение или споделяне на данни в един или повече модули. Има известна гъвкавост на ниво приложение и база данни по отношение на мащаба, тъй като услугите вече не са свързани.
Архитектура на микроуслуги
Тази архитектура разглежда всяка услуга като услуга с едно предназначение, като дава възможност на бизнеса да мащабира всяка услуга независимо и да избягва ненужното потребление на ценни ресурси. За мащабиране на база данни, постоянният слой може да бъде проектиран и настроен изключително за всяка услуга за индивидуално мащабиране.
Заедно с управляваната от събития архитектура, тези архитектури струват повече от гледна точка на облачни ресурси от монолитните архитектури при ниски нива на използване. Въпреки това, с нарастващи натоварвания, мултитенантни реализации и в случаите, когато има изблици на трафик, те са по-икономични. MTTS също е много ефективен и може да бъде измерен за секунди благодарение на фините услуги.
Въпреки това, с големия брой услуги и разпределения характер, отстраняването на грешки може да е по-трудно и може да има по-високи разходи за поддръжка, ако услугите не са напълно автоматизирани.
Пространствено базирана архитектура
Тази архитектура се основава на принцип, наречен кортежна обработка — множество паралелни процесори със споделена памет. Тази архитектура увеличава максимално мащабируемостта и еластичността на ниво приложение и база данни.
Всички взаимодействия на приложения се осъществяват с мрежата с данни в паметта. Извикванията към мрежата са асинхронни и процесорите за събития могат да се мащабират независимо. При мащабирането на база данни има запис на фонови данни, който чете и актуализира базата данни. Всички операции за вмъкване, актуализиране или изтриване се изпращат до записващото устройство на данни от съответната услуга и се поставят на опашка, за да бъдат взети.
MTTS е изключително бърз, обикновено отнема няколко милисекунди, тъй като всички взаимодействия с данни са с данни в паметта. Всички услуги обаче трябва да се свържат с брокера и първоначалното зареждане на кеша трябва да бъде създадено с четец на данни.
В тази дигитална ера компаниите искат да увеличат или намалят ИТ ресурсите според нуждите, за да отговорят на променящите се изисквания. Първата стъпка е преминаването от големи монолитни системи към разпределена архитектура, за да спечелите конкурентно предимство – това са направили Netflix, Lyft, Uber и Google. Въпреки това изборът на коя архитектура е субективен и решенията трябва да се вземат въз основа на възможностите на разработчиците, средно натоварване, пиково натоварване, бюджетни ограничения и цели за растеж на бизнеса.
Сашанк е сериен предприемач с голям интерес към иновациите.
DataDecisionMakers
Добре дошли в общността на VentureBeat!
DataDecisionMakers е мястото, където експертите, включително техническите хора, работещи с данни, могат да споделят прозрения и иновации, свързани с данните.
Ако искате да прочетете за авангардни идеи и актуална информация, най-добри практики и бъдещето на данните и технологиите за данни, присъединете се към нас в DataDecisionMakers.
Може дори да обмислите да допринесете със собствена статия!
Прочетете повече от DataDecisionMakers
