Въпреки че безсървърните технологии бързо набраха популярност през последните години, все още има много погрешни схващания и страхове, свързани с тях. Зависимостта от доставчик, инструменти, управление на разходите, студен старт, мониторинг и жизнен цикъл на разработка са все горещи теми, когато става дума за безсървърни технологии. В тази статия ще проучим някои от споменатите теми, както и ще споделим съвети и връзки към полезни източници на информация, за да помогнем на начинаещите да създават мощни, гъвкави и рентабилни приложения без сървър.
Погрешни схващания относно безсървърните технологии
Много хора смятат, че обработката без сървър и без сървър (, FaaS) са почти едно и също нещо. Това означава, че разликата не е твърде голяма и си струва да се въведе новост. Въпреки че AWS Lambda беше една от звездите на разцвета на безсървърната архитектура и един от най-популярните елементи на безсървърната архитектура, тази архитектура е много повече от FaaS.
Основният принцип зад безсървърните технологии е, че не е нужно да се притеснявате за управлението и мащабирането на вашата инфраструктура, плащате само за това, което използвате. Много услуги отговарят на тези критерии - AWS DynamoDB, S3, SNS или SQS, Graphcool, Auth0, Now, Netlify, Firebase и много други. Като цяло без сървър означава използване на пълната мощ на облачните изчисления, без да е необходимо да управлявате инфраструктурата и да я оптимизирате за мащабиране. Това също означава, че сигурността на ниво инфраструктура вече не е ваша грижа, което е огромно предимство предвид трудността и сложността на спазването на стандартите за сигурност. И накрая, не е нужно да купувате предоставената ви инфраструктура.
Без сървър може да се счита за „състояние на ума“: определен манталитет при проектирането на решения. Избягвайте подходи, които изискват поддръжка на всякаква инфраструктура. С подход без сървър ние отделяме време за решаване на задачи, които пряко засягат проекта и носят ползи на нашите потребители: създаваме устойчива бизнес логика, разработваме потребителски интерфейси и разработваме адаптивни и надеждни API.
Например, ако е възможно да се избегне управлението и поддържането на платформа за безплатно търсене на текст, тогава това е, което ще направим. Този подход към изграждането на приложения може значително да ускори времето за излизане на пазара, защото вече не е необходимо да мислите за управление на сложна инфраструктура. Елиминирайте отговорностите и разходите за управление на инфраструктурата и се фокусирайте върху изграждането на приложенията и услугите, от които се нуждаят вашите клиенти. Патрик Дебоа нарече този подход , терминът е възприет в общността без сървъри. Функциите трябва да се разглеждат като връзка към услуги като модули, които могат да се разгръщат (вместо да се разгръща цяла библиотека или уеб приложение). Това осигурява невероятна детайлност за управление на внедряването и промените в приложението. Ако не можете да разположите функции по този начин, тогава това може да означава, че функциите изпълняват твърде много задачи и трябва да бъдат преработени.
Някои са объркани от зависимостта от доставчика при разработването на облачни приложения. Същото важи и за безсървърните технологии и това едва ли е погрешно схващане. Според нашия опит изграждането на безсървърни приложения на AWS, съчетано със способността на AWS Lambda да обединява други AWS услуги заедно, е част от силата на безсървърните архитектури. Това е добър пример за синергия, когато резултатът от комбинацията е повече от сбора на условията. Опитът да се избегне зависимостта от доставчика може да доведе до още повече проблеми. Когато работите с контейнери, е по-лесно да управлявате своя собствен абстракционен слой между облачни доставчици. Но когато става дума за безсървърни решения, усилията няма да се отплатят, особено ако рентабилността се вземе предвид от самото начало. Не забравяйте да разберете как продавачите предоставят услуги. Някои специализирани услуги разчитат на точки за интеграция с други доставчици и може да предоставят plug-and-play свързаност веднага. По-лесно е да предоставите Lambda повикване от крайна точка на API на шлюз, отколкото да прокси заявката към някакъв контейнер или екземпляр на EC2. Graphcool осигурява лесна конфигурация с Auth0, което е по-лесно от използването на инструменти за удостоверяване на трети страни.
Изборът на правилния доставчик за вашето безсървърно приложение е архитектурно решение. Когато създадете приложение, не очаквате един ден да се върнете към управлението на сървъри. Изборът на облачен доставчик не се различава от избора да използвате контейнери или база данни, или дори език за програмиране.
Обмисли:
- От какви услуги се нуждаете и защо.
- Какви услуги предоставят облачните доставчици и как можете да ги комбинирате с избраното от вас FaaS решение.
- Какви езици за програмиране се поддържат (с динамично или статично писане, компилирани или интерпретирани, какви са бенчмарковете, каква е производителността при студен старт, каква е екосистемата с отворен код и т.н.).
- Какви са вашите изисквания за сигурност (SLA, 2FA, OAuth, HTTPS, SSL и др.).
- Как да управлявате вашите CI/CD и цикли на разработка на софтуер.
- От кои решения за инфраструктура като код можете да се възползвате.
Ако разширите съществуващо приложение и постепенно добавите функционалност без сървър, това може донякъде да ограничи наличните възможности. Въпреки това, почти всички технологии без сървър предоставят някакъв вид API (чрез REST или опашки за съобщения), който ви позволява да създавате разширения, независими от ядрото на приложението и с лесна интеграция. Търсете услуги с ясни API, добра документация и силна общност и няма да сбъркате. Лесната интеграция често може да бъде ключов показател и вероятно е една от основните причини, поради които AWS е толкова успешна, откакто Lambda беше пусната през 2015 г.
Когато без сървър е добре
Безсървърните технологии могат да се прилагат почти навсякъде. Предимствата им обаче не се изчерпват само с един начин на приложение. Бариерата за навлизане на облачните изчисления днес е толкова ниска благодарение на безсървърните технологии. Ако разработчиците имат идея, но не знаят как да управляват облачната инфраструктура и да оптимизират разходите, тогава не е нужно да търсят някакъв вид инженер, който да го направи. Ако стартиращ бизнес иска да изгради платформа, но се страхува, че разходите може да излязат извън контрол, той може лесно да се обърне към решения без сървър.
Поради спестяване на разходи и лекота на мащабиране, безсървърните решения са еднакво приложими както за вътрешни, така и за външни системи, до уеб приложение с многомилионна аудитория. Сметките се измерват не в евро, а в центове. Наемането на най-простия екземпляр на AWS EC2 (t1.micro) за един месец ще струва €15, дори ако не правите нищо с него (кой никога не е забравил да го изключи?!). За сравнение, за да достигнете това ниво на разходи за същия период от време, ще трябва да стартирате 512 MB Lambda за 1 секунда около 3 милиона пъти. И ако не използвате тази функция, тогава не плащате нищо.
Тъй като безсървърната инфраструктура е предимно управлявана от събития, е сравнително лесно да се добави безсървърна инфраструктура към по-стари системи. Например, използвайки AWS S3, Lambda и Kinesis, можете да създадете услуга за анализ за стара система за търговия на дребно, която може да получава данни чрез API.
Повечето платформи без сървър поддържат няколко езика. Най-често това е Python, JavaScript, C#, Java и Go. Обикновено няма ограничения за използването на библиотеки на всички езици, така че можете да използвате любимите си библиотеки с отворен код. Въпреки това е препоръчително да не злоупотребявате със зависимостите, така че вашите функции да работят оптимално и да не отричат предимствата на огромната мащабируемост на вашите приложения без сървър. Колкото повече пакети трябва да бъдат заредени в контейнера, толкова по-дълго ще отнеме студеният старт.
Студеният старт е, когато първо трябва да инициализирате контейнера, времето за изпълнение и манипулатора на грешки, преди да ги използвате. Поради това забавянето на изпълнението на функциите може да бъде до 3 секунди и това не е най-добрият вариант за нетърпеливи потребители. Студените стартирания обаче се случват при първото повикване след няколко минути неактивна функция. Така че мнозина смятат това за незначително раздразнение, което може да се преодолее чрез редовно пингване на функцията, за да я поддържате на празен ход. Или напълно пренебрегват този аспект.
Въпреки че AWS пуснаВъпреки това SQL базите данни не са идеални за това приложение, тъй като те зависят от връзки за извършване на транзакции, което може бързо да се превърне в пречка с тежък трафик на AWS Lambda. Да, разработчиците непрекъснато подобряват Serverless Aurora и трябва да експериментирате с нея, но днес NoSQL решения като. Няма съмнение обаче, че тази ситуация ще се промени много скоро.
Инструментариумът също така налага много ограничения, особено в областта на локалното тестване. Въпреки че има решения като Docker-Lambda, DynamoDB Local и LocalStack, те изискват упорита работа и значително количество конфигурация. Всички тези проекти обаче се разработват активно, така че е само въпрос на време инструментариумът да достигне нивото, от което се нуждаем.
Влиянието на безсървърните технологии върху цикъла на разработка
Тъй като вашата инфраструктура е само конфигурация, можете да дефинирате и внедрите код с помощта на скриптове, като скриптове на обвивка. Или можете да прибегнете до решения за клас конфигурация като код като . Въпреки че тази услуга не предоставя конфигурация за всички области, тя ви позволява да дефинирате конкретни ресурси, които да използвате като ламбда функции. Тоест там, където CloudFormation ви проваля, можете да напишете свой собствен ресурс (функция Lambda), който ще запълни тази празнина. По този начин можете да правите всичко, дори да конфигурирате зависимости извън вашата AWS среда.
Тъй като всичко е само конфигурация, можете да персонализирате вашите скриптове за внедряване за конкретни среди, региони и потребители, особено ако използвате решения за инфраструктура като код като CloudFormation. Например, можете да разположите копие на инфраструктурата за всеки клон в хранилището, така че да можете да ги тествате напълно изолирано по време на разработката. Това драстично ускорява обратната връзка за разработчиците, когато искат да разберат дали кодът им работи адекватно в среда на живо. Мениджърите не трябва да се тревожат за разходите за внедряване на множество среди, тъй като те плащат само за действителното използване.
DevOps имат по-малко притеснения, тъй като трябва само да се уверят, че разработчиците имат правилната конфигурация. Вече не е необходимо да управлявате екземпляри, балансьори или групи за сигурност. Следователно терминът NoOps се използва все по-често, въпреки че все още е важно да можете да конфигурирате инфраструктурата, особено когато става въпрос за конфигурация на IAM и оптимизация на облачни ресурси.
Има много мощни инструменти за наблюдение и визуализация като Epsagon, Thundra, Dashbird и IOPipe. Те ви позволяват да наблюдавате текущото състояние на вашите безсървърни приложения, осигуряват регистриране и проследяване, улавят показатели за производителност и тесни места в архитектурата, извършват анализ на разходите и прогнозиране и др. Те не само дават на инженерите, разработчиците и архитектите на DevOps цялостен поглед върху производителността на приложенията, но също така позволяват на мениджърите да наблюдават ситуацията в реално време, с разходи за ресурси за секунда и прогнозиране на разходите. Много по-трудно е да се организира това с управлявана инфраструктура.
Проектирането на безсървърни приложения е много по-лесно, защото не е нужно да разполагате уеб сървъри, да управлявате виртуални машини или контейнери, да пачвате сървъри, операционни системи, интернет шлюзове и т.н. Като абстрахирате всички тези отговорности, безсървърната архитектура може да се фокусира върху ядрото - решението, нуждите на бизнеса и клиентите.
Въпреки че инструментариумът може да бъде по-добър (става по-добър всеки ден), разработчиците могат да се съсредоточат върху прилагането на бизнес логиката и най-доброто разпределяне на сложността на приложението между различни услуги в рамките на архитектурата. Управлението на приложенията без сървър е базирано на събития и се абстрахира от доставчика на облак (напр. SQS, S3 събития или DynamoDB потоци). Следователно разработчиците трябва само да напишат бизнес логика, за да отговорят на определени събития, и не трябва да се притесняват как най-добре да внедрят бази данни и опашки от съобщения или как да организират оптимална работа с данни в специфични хардуерни хранилища.
Кодът може да се изпълнява и отстранява грешки локално, както при всеки процес на разработка. Единичното тестване остава същото. Възможността за разгръщане на цяла инфраструктура на приложения с персонализирана конфигурация на стека позволява на разработчиците бързо да получат важна обратна връзка, без да мислят за цената на тестването или въздействието върху скъпите управлявани среди.
Инструменти и техники за изграждане на безсървърни приложения
Няма конкретен начин за изграждане на приложения без сървър. Както и набор от услуги за тази задача. AWS е лидер сред мощните безсървърни решения днес, но погледнете също , и . Ако използвате AWS, препоръчителният подход за събиране на приложения е (SAM), особено когато използвате C#, защото Visual Studio има страхотни инструменти. SAM CLI може да прави всичко, което Visual Studio може, така че няма да загубите нищо, ако преминете към друга IDE или текстов редактор. Разбира се, SAM работи и с други езици.
Ако пишете на други езици, Serverless Framework е отличен инструмент с отворен код, който ви позволява да конфигурирате всичко с много мощни YAML конфигурационни файлове. Serverless Framework също поддържа различни облачни услуги, така че го препоръчваме на тези, които търсят мулти-облачно решение. Има огромна общност, която е създала куп плъгини за всякакви нужди.
За локално тестване инструментите с отворен код Docker-Lambda, Serverless Local, DynamoDB Local и LocalStack са много подходящи. Безсървърните технологии все още са в ранен етап на развитие, както и инструментите за тях, така че когато настройвате за сложни тестови сценарии, ще трябва да работите усилено. Обаче простото разполагане на стека в среда и тестване там е невероятно евтино. И не е необходимо да правите точно локално копие на облачни среди.
Използвайте AWS Lambda Layers, за да намалите размера на внедрените пакети и да ускорите изтеглянията.
Използвайте правилните езици за програмиране за конкретни задачи. Различните езици имат своите предимства и недостатъци. Има много показатели, но JavaScript, Python и C# (.NET Core 2.1+) са лидерите по отношение на производителността на AWS Lambda. AWS Lambda наскоро представи Runtime API, който ви позволява да посочите желания език и среда за изпълнение, така че експериментирайте.
Поддържайте малки размери на пакети за внедряване. Колкото по-малки са, толкова по-бързо се зареждат. Избягвайте използването на големи библиотеки, особено ако използвате няколко функции от тях. Ако програмирате в JavaScript, използвайте инструмент за изграждане като Webpack, за да оптимизирате компилацията си и да включите само това, от което наистина се нуждаете. .NET Core 3.0 има QuickJit и Tiered Compilation, което подобрява производителността и помага много при студено стартиране.
Разчитането на функциите без сървър на събития може да затрудни координирането на бизнес логиката в началото. В това отношение опашките със съобщения и държавните машини могат да бъдат изключително полезни. Ламбда функциите могат да се обаждат една на друга, но правете това само ако не очаквате отговор („задействане и забравяне“) – не искате да ви таксуват за изчакване за завършване на друга функция. Опашките за съобщения са полезни за изолиране на части от бизнес логиката, управление на тесните места в приложенията и обработка на транзакции (използвайки FIFO опашки). Функциите AWS Lambda могат да бъдат присвоени на SQS опашки като опашки със заседнали съобщения, които следят неуспешните съобщения за по-късен анализ. Стъпковите функции на AWS (държавни машини) са много полезни за управление на сложни процеси, които изискват верижно свързване на функции. Вместо Lambda функция, извикваща друга функция, стъпковите функции могат да координират преходите на състоянията, да предават данни между функциите и да управляват глобалното състояние на функциите. Това ви позволява да дефинирате условия за повторен опит или какво да направите, когато възникне определена грешка - много мощен инструмент при определени условия.
Заключение
През последните години безсървърните технологии се развиват с безпрецедентни темпове. Има някои погрешни схващания, свързани с тази промяна на парадигмата. Чрез абстрахиране на инфраструктурата и управление на мащаба, безсървърните решения предлагат значителни предимства, от опростена разработка и DevOps процеси до масивни намаления на оперативните разходи.
Докато подходът без сървър не е лишен от своите недостатъци, има стабилни модели на проектиране, които могат да се използват за изграждане на стабилни приложения без сървър или за интегриране на елементи без сървър в съществуващи архитектури.
Източник: www.habr.com