Во последно време се крена голема врева околу архитектурата без сервери. Едни велат дека го менува начинот на кој апликациите се изградени, деплојментот на истите и последователно како се искористени. Додека други тврдат дека компјутингот без сервери не вреди до толку. Која е вистината?

Во овој блог пост, одлучивме одблиску да видиме што е архитектура без сервери, кои се вашите придобивки и што треба да очекувате исто така.

Што е архитектура без сервери?

Компјутинг без сервери или едноставно без сервери е тип на клауд архитектура која не вклучува управување со кој било сервер, виртуелни машини или контејнери. И покрај името, се разбира, секако сè уште има сервери, но задачата за нивно справување паѓа на грбот на вашиот провајдер на клауд инфраструктурата. Ова ви овозможува да го извршите кодот во форма на функции при автоматски обезбедена инфрастуктура и околина. Што се однесува до провајдерите на инфрастуктурата без сервери, имате повеќе опции. Денес, секој поголем клауд провајдер нуди архитектура без сервери:

• AWS Lambda
• Google Cloud Functions
• Microsoft Azure Functions
• IBM/Apache’s OpenWhisk
• Oracle Cloud Fn

Водечки провајдери без сервери

Што значи со и без сервер, можеби ќе ве интересира. Да се класифицира нешто како без сервер, AWS ги користи следниве 4 карактеристики:

• Нема сервиси за управување – како што утврдивме, физичките сервери, виртуелните машини и контејнери секако постојат, но корисникот не управува ниту пак има пристап до истите.
• Цена врз основ на употреба – плаќате само за потрошените ресурси, не капацитетот, што значи дека не плаќате за времето кога вашата апликација е во мирување.
• Автоматско скалирање – со самото проширување на капацитетите на вашата апликација како што растат побарувањата, таа треба да е во можност автоматски да се скалира. На пример, нашиот тим продолжи со миграција на Вивино во клауд, што ѝ овозможи на апликацијата да го задоволи зголемениот товар и денес да добие 36 милиони корисници повеќе.
• Вградена висока достапност и толеранција на грешки – достапноста, повторното воспоставување и толеранција на грешки не се ваша одговорност, бидејќи треба да се вградени.

Честопати се нарекува функција како сервис или FaaS. Но, тоа е само делумно точно. Архитектурата без сервери имплицира дека апликациите или се потпираат на сервиси од трети back-end страни (Backend како сервис или BaaS)  или прилагоден код кој работи во управувани, ефемерни контејнери (Функција како сервис или FaaS). На овој начин, веќе нема да мора да се грижите за компонентите на серверот. Ова е задача на провајдерот.

Кои се придобивките од архитектурата без сервери

Освен веќе кажаното, дека нема сервер за да управува, архитектура без сервери има и други примамливи страни:

• Намалена цена – on-demand модел на цени на архитектура без сервери значи дека плаќате по извршувањето на функцијата што е многу поефикасно отколку да платите фиксна цена на серверот, дури и ако не се користи. Ова и фактот дека не треба да одржувате сервери 24/7 значително ги намалува трошиците за развој.

• Ниско одржување – од перспектива на девелоперите, единственото нешто на кое треба да се фокусираат е кодот на апликацијата и бизнис логиката, додека останатото како одржување на сервер, конфигурација на скалирање, мониторинг или тековната околина, паѓа на грбот на провајдерот без сервери.

• Пократко време за продажба – со отстранување на непотребните напори за обезбедување на потребната инфраструктура за девелоперските тимови, архитектура без сервери доволно го намалува времето за продажба. Овозможува брзо пуштање на новата функционалност и отстранува блокади. Како резултат, станува идеално решение за PoC или стартапи.

• Скалабилност – архитектурата без сервери е лесна да се скалира кога е потребно, што е одлично кога има непредвиденo преоптеретување. Во случај кога нова карактеристика одеднаш станува популарна, околината без сервери автоматски овозможува зголемено или намалено скалирање. Значи, нема потреба да се подготвувате однапред.

• Безбедност и регулаторна усогласеност – провајдерите без сервери се одговорни за обезбедување на архитектура која е безбедна, ослободена од хакирање и напади. Дополнително, околината без сервери е во согласност со повеќето регулаторни барања како GDPR, PCI DSS, HIPPA, итн. Покрај тоа, клауд провајдерите може да ве предупредат за ситуации кои не се усогласени,  како што беше функционалноста имплементирана од нашиот тим кога ја анализираа дупката на усогласеност и работеа на санирање за HPE GreenLake; клауд провајдер кој управува со усогласеноста на клауд и контролата на трошоци при миграцијата на компанијата во клауд.

• Фокус на UX – без сервиси или не, инфраструктурата не е нешто за кое се грижат вашите клиенти. Тие сакаат одлично и безгрижно искуство и нови карактеристики. За среќа, архитектура без сервери го овозможува токму тоа.

Негативната страна на компјутингот без сервери

Колку и да е примамлива архитектурата без сервери, има и негативни страни за кои треба да знаете:

• Скапа за постојано, високо оптоварување – За жал, архитектурата без сервери не е идеално решение. Кога се зголемува оптоварувањето, понудата без сервер може да стане прилично скапа. Но, вообичаено, повеќето од претпоставките се веќе познати па додека да дојде до тоа треба да бидете сигурни дали сакате да ја задржите или не. Кога добивате постојано оптоварување, време е да се преселите во посветена инфраструктура за да заштедите.

•  Заклучување на вендорите – Штом вашиот код е имплементиран и зависи од неколку управувани сервиси, може да е тешко да се премести од клауд на on-premise центар за податоци затоа што ќе треба да изградите алтернативи за веќе користените управувани сервери. Дури и миграцијата од еден клауд на друг може да е болна точка поради разликите во API или функционалноста обезбедена од различни вендори.

• Ограничувања без сервер – Провајдерите без сервери поставуваат некои ограничувања за обработка. И, ако имате премногу задачи кои работат истовремено, некои од нив може да бидат блокирани и да не работат правилно и навремено. Згора на тоа, архитектурата без сервери подобро одговара за кратки процеси во реално време, како испраќање е-пошта, отколку долготрајни процеси (како поставување видео) кои можеби подобро функционираат на сервери.

• Тестирањето на интеграции е предизвик – Друг проблем на кој може да наидете е тестирање на интеграција, што е отежнето со апстракции без сервери и ефемерно постоење. Исто така, не се исклучени предизвиците со деплојмент, верзионирање и пакување.

Платформи без сервери на Amazon и нивни случаи на употреба

Најефикасниот начин за создавање на архитектура без сервери е да се одбере една од многутте платформи без сервери кои нудат многубројни можности. Главните играчи на пазарот денес се Amazon Web Services, Microsoft Azure и Google Cloud Platform. Имајќи огромен број на опции, овие провајдери на платформи нудат солидна основа за непречено патување без сервер и целосно развиени системи без сервер. Да разгледаме што нуди Amazon, еден од водечките провајдери без сервер и целосните можности за користење за изградба на веб апликација.

Случаи на употреба на компјутинг

Со воведувањето на AWS Lambda во 2014 година, концептот на компјутинг без сервери стана широко популарен. Подоцна беше брзо проследено со IBM OpenWhisk/Bluemix, Google Cloud Functions, и Microsoft Cloud Functions. Компјутинг без сервери значи дека задачата за извршување на кодот на апликацијата е растоварена во компјутинг платформа без сервери за различни придобивки, како што се: да не се грижите за време на хостирање, безбедносната страна да му ја оставите на провајдерот, лесна интеграција со други сервиси, и сè на сè економично и скалабилно решение. Ова е победничко решение како за софтверски вендор така и за сопственик на бизнис, бидејќи овозможува фокусот да е на кодот и го остава делот за извршување на провајдерот.

Првиот и најпопуларен избор тука е AWS Lambda. Може да се користи за да се изгради моќна веб страница и нуди многубројни придобивки, како на пример побрз развој, скалабилност, пониски оперативни трошоци и полесен оперативен менаџмент.

Но, кога станува збор за без сервери, времето е пари. И една од најголемите цели и предизвици е одбегнување на плаќање за времето кога Lambda не прави ништо. Најдобар начин да се оптимизира времето е да се користи асинхроно програмирање. Кога async е лошо извршено создава контролни функции кои чекаат сервисите на AWS  да направат нешто. И за да се искористи времето подобро, се користат настани или Step Functions за да се најде подобро и поефтино решение. Добриот async може да направи огромна разлика со паралелно извршување.

За дополнителни функции, како што е можноста за ограничување на корисници или барања, заштита од Distributed Denial или напади на сервис, или обезбедување на слој на кеширање за да се кешира одговорот од Lambda функцијата, API Gateway може да се примени како што направивме во случајот со AWS платформата за здравство која е заснована на клауд.

За извршување на едноставни, временски задачи како на пример испраќање на билтен на одредено време, чистење на кешот на базата на податоци во редовни интервали или за веб страници со сметки за членство со датум на истекување, може да се примени CRON или закажани работи.

Случаи на употреба на база на податоци

Кога станува збор за компјутинг без сервери, база на податоци без сервери не е само предуслов, туку и нешто кое бара внимателно разгледување. Брза и непромислена одлука може да ве чини дополнително или поради тековно одржување на базата на податоци или да мигрирате податоци кон друго решение.

Најмногу случаи на база на податоци може да се решат или со SQL или релациони бази на податоци (на пример, MySQL, PostgreSQL) или NoSQL или да се денормализираат (на пример, Dynamo DB, MongoDB, Cassandra). Тука изборот зависи во голема мера од вашите приоритети. Нормализираната база на податоци нуди поголема флексибилност, но на сметка на перформансите. За случаи кои бараат високи перформанси и хиперскалабилност NoSQL е подобра опција.

За апликациите што работат со AWS, најпопуларните избори во базата на податоци се DynamoDB или AWS Aurora.

DynamoDB доаѓа со многу придобивки како што е автоматско скалирање во согласност со оптоварувањето на апликацијата, моделот на цени за плаќање по употреба, низок износ за одржување и вообичаено се смета за лесен почеток. Сепак, исто така треба да се напоемене дека DynamoDB ја прави миграцијата кон друго решение многу предизвикувачка, вклучувајќи многу работа. Неговиот идеален случај е апликација со поставени шеми за пристап кои нема да се променат. Ако, сепак, очекувате некои промени во иднина, можеби треба да побарате други решенија.

Amazon Aurora е релациона база на податоци компатибилна со MySQl и PostgreSQL. Изведува до пет пати побрзо од MySQL и три пати побрзо од PostgreSQL базите на податоци. Нејзината автоматска, on-demand конфигурација значи дека базата на податоци започнува, го скалира капацитетот по барање на апликацијата и се исклучува ако не се користи. Бидејќи е целосно компатибилна со MySQL и PostgreSQL базите на податоци, можете лесно да ги мигрирате овие бази на податоци во Aurora. Нема потреба да се грижите за управување, поставување, конфигурација или бекап, бидејќи е веќе целосно управувано. AWS Aurora е идеално, високо безбедно и економично решение за наизменични, ретки и непредвидени оптоварувања.

Случаи на обработка на податоци

Друг популарен случај на употреба е обработка на податоци што е корисно кога има потреба да се обработат некои влезни барања помеѓу софтверските компоненти и затоа тие треба да комуницираат и да разменуваат информации. Со AWS, има три начини како да го направите тоа:

• Amazon Simple Queue Service (SQS) е сервис на редици на чекање (queueing service) кој овозможува раздвојување и скалирање на микросервиси, дистрибуирани системи и апликации без сервери. SQS овозможува испраќање, складирање и примање пораки во која било количина без да се изгубат пораките. Ова може да се примени за испраќање на огромни количини на е-пошта, транскодирање на видео датотеки по поставувањето, анализа на однесување на корисникот. Работи на следниот начин:

• Amazon Kinesis нуди управувани сервиси за стримање на соберени податоци и обработка. Може да се искористи за собирање податоци во реално време. Kinesis реагира веднаш, со обработка и анализирање на податоците веднаш штом пристигнат, наместо да чека додека сите податоци се соберат за да се започне со обработка. Може да се користи за внесување податоци во реално време, како што се аудио, видео, апликациски логови или преноси на кликови на веб страници.

За активирање на повеќе функции на Lambda за обработка на различни функционалности може да се користи техниката fan-out. Amazon Simple Notification Service (SNS) тука е многу популарен избор. Тоа е траен, безбеден сервис за пораки кој овозможува раздвојување микросервиси, дистрибуирани системи и апликации без сервери. Користејќи SNS, издавачките системи може да испратат пораки до голем број на крајни точки на претплатници за паралелна обработка (вклучувајќи SQS редици на чекање). Исто така, може да се искористи за испраќање нотификации до крајните корисници преку мобилен, СМС и е-пошта.  

Случаи на употреба на аналитика

Но, градењето на високо скалабилни апликации не е доволно. Со цел да го подобрите самиот продукт и делумно да го разберете однесувањето на корисникот, треба да вклучите аналитика. Услугите на Аmazon без сервиси може да ви помогнат околу тоа.

За да ги анализирате настаните во аналитиката и да ги претворите податоците во вреден увид можете да го користите Amazon Athena. Тоа ќе ви помогне да ги анализирате неструктурираните, полуструктурираните и структурираните податоци и може да се користи за генерирање извештаи или за истражување податоци со алатки за деловно разузнавање. Како решение без сервери, тоа бара големи количини на податоци и ги добива резултатите во само неколку секунди, а вие треба да платите само за скенираните податоци.

Како нетрадиционално решение, тоа е интегирано со AWS Glue Data Catalog, што овозможува да се создаде унифицирано складиште на метаподатоци низ разни сервиси, откривајќи шеми со ползечки податоци. Како дел од решенијата без сервери на AWS, Glue природно ги поддржува податоците зачувани во Amazon Aurora, што значи помалку мака.

Опсегот на платформата без сервери на Amazon покажува дека може лесно да изградите и да извршувате апликации без сервер. И ова е само еден провајдер; можете да одберете кој било друг од петте водечки играчи на пазарот и да ја откриете нивната еквивалентна понуда.

Дебатираме дали архитектурата без сервер e тоа што навистина ви е потребно?

Контактирајте нè и нашиот технички консултант ќе ви помогне да ја донесете вистинската одлука за клауд решенија за вашиот продукт, без разлика дали ви е потребна за градење клауд апликација од нула или за модернизација на вашата наследна апликација.