Въпреки че безсървърните технологии бързо печелят популярност през последните години, с тях все още са свързани много заблуди и притеснения. Зависимост от доставчици, инструменти, управление на разходите, студен старт, мониторинг и жизнен цикъл на разработката — всички тези теми активно се обсъждат, когато говорим за безсървърни технологии. В тази статия ще разгледаме някои от споменатите теми и ще споделим съвети и линкове към полезни източници на информация, с които новаците могат да създадат мощни, гъвкави и икономични безсървърни приложения.
Заблуди относно безсървърните технологии
Мнозина смятат, че безсървърността и обработката на данни на сървър (, 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 решение.
- Какви езици за програмиране се поддържат (с динамично или статично типизиране, компилирани или интерпретирани, какви има бенчмаркове, каква е производителността при студено стартиране, каква е open source екосистемата и т.н.).
- Какви са вашите изисквания за сигурност (SLA, 2FA, OAuth, HTTPS, SSL и т.н.).
- Как да управлявате вашия CI/CD и цикли за разработка на софтуер.
- Какви предимства на решенията от клас infrastructure-as-code можете да използвате.
Ако разширявате съществуващото приложение и инкрементално добавяте безсървърни функции, това може да ограничи наличните възможности. Въпреки това почти всички безсървърни технологии предлагат някакви API (чрез REST или съобщителни опашки), позволяващи създаването на разширения независимо от ядрото на приложението и с лесна интеграция. Търсете услуги с разбираеми API, добра документация и силна общност и няма да сгрешите. Леснотата на интеграцията често може да бъде ключова метрика и вероятно това е една от основните причини за успеха на AWS откакто през 2015 г. беше пусната Lambda.
Кога е полезна безсървърността
Безсървърните технологии могат да се прилагат практически навсякъде. Въпреки това техните предимства не се ограничават само до начините на приложение. Прагът за влизане в облачните изчисления днес е толкова нисък именно благодарение на безсървърните технологии. Ако разработчиците имат идея, но не знаят как да управляват облачната инфраструктура и да оптимизират разходите, не им е нужно да търсят инженер за това. Ако стартъп иска да създаде платформа, но се страхува, че разходите могат да излязат извън контрол, лесно може да се обърне към безсървърни решения.
Благодарение на икономията на разходи и простотата на мащабирането, безсървърните решения са приложими и за вътрешни системи, и за външни, включително за уеб приложение с многомилионна аудитория. Сметките не се измерват по-скоро в евро, а в центове. Наемането на най-простия екземпляр на AWS EC2 (t1.micro) за един месец ще струва €15, дори ако не правите нищо с него (кой никога не е забравял да го изключи?!). За сравнение, за да постигнете такова ниво на разходи за същия период, ще ви трябва да стартирате Lambda с размер 512 Мб за 1 секунда около 3 милиона пъти. А ако не използвате тази функция, няма да плащате нищо.
Тъй като безсървърната технология зависи предимно от събития, можете доста лесно да добавите безсървърна инфраструктура към стари системи. Например с AWS S3, Lambda и Kinesis можете да създадете аналитична услуга за стара търговска система, която може да получава данни чрез API.
Повечето безсървърни платформи поддържат различни езици. Най-често това са Python, JavaScript, C#, Java и Go. Обикновено в тези езици няма ограничения относно използването на библиотеки, така че можете да използвате любимите си open source-библиотеки. Въпреки това, е желателно да не злоупотребявате със зависимости, за да могат функциите ви да се изпълняват оптимално и да не унищожават предимствата на огромната мащабируемост на вашите безсървърни приложения. Колкото повече пакети трябва да бъдат заредени в контейнера, толкова по-дълго ще отнеме студеният старт.
Студеният старт е, когато е необходимо първо да се инициализира контейнерът, средата за изпълнение и обработчикът на грешки, преди да бъдат използвани. Поради това забавянето на изпълнението на функциите може да достигне до 3 секунди, което не е най-добрият вариант за нетърпеливи потребители. Въпреки това, студените стартирания се срещат при първото извикване след няколко минути престой на функцията. Така че много хора считат това за незначително неудобство, което може да бъде заобиколено с помощта на редовно пинговане на функцията, за да я поддържат на празен ход. Или изцяло игнорират този аспект.
Въпреки че AWS издаде, SQL базите не са идеални за такова приложение, тъй като при изпълнението на транзакции те зависят от връзките, които бързо могат да станат тясно място при голям трафик на AWS Lambda. Да, разработчиците постоянно усъвършенстват Serverless Aurora и си заслужава да експериментирате с нея, но днес безсървърните системи са много по-подходящи за NoSQL решения като. Въпреки това, несъмнено, ситуацията ще се промени много скоро.
Инструментариумът също така налага немалко ограничения, особено в областта на локалното тестване. Въпреки че съществуват решения като Docker-Lambda, DynamoDB Local и LocalStack, те изискват грижливо внимание и значително количество конфигуриране. Въпреки това, всички тези проекти активно се развиват, така че е само въпрос на време, когато инструментариумът достигне необходимото ниво.
Влиянието на безсървърните технологии върху цикъла на разработка
Тъй като вашата инфраструктура представлява просто конфигурация, можете да зададете и разположите кода чрез скриптове, например shell-скриптове. Или може да се прибегне до решения от клас configuration-as-code като . Въпреки че този сервис не предоставя конфигурация за всички области, той позволява да се определят конкретни ресурси за използване като Lambda функции. Тоест, там, където CloudFormation няма да бъде достатъчен, можете да напишете свой собствен ресурс (Lambda функция), който да запълни тази празнина. По този начин можете да направите каквото и да е, дори да конфигурирате зависимости извън вашата AWS среда.
Тъй като всичко това е просто конфигурация, можете да параметризирайте вашите скриптове за разгръщане за конкретни среди, региони и потребители, особено ако използвате решения от типа infrastructure-as-code като 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 е отличен open source инструмент, който позволява конфигуриране на всичко чрез много мощни конфигурационни YAML файлове. Също така, Serverless Framework поддържа различни облачни услуги, така че го препоръчваме на тези, които търсят мултиоблачни решения. Има огромна общност, която е създала множество плъгини за всякакви нужди.
За локално тестване са подходящи open source инструменти като 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, които подобряват производителността и много помагат при студени стартове.
Зависимостта на безсървърните функции от събития в началото може да затрудни координацията на бизнес логиката. В това отношение, опашките за съобщения и крайни автомати могат да бъдат изключително полезни. Lambda функциите могат да извикват една друга, но правете това само ако не очаквате отговор ("изстреляйте и забравете") — не искате да плащате за времето за изчакване на завършването на друга функция. Опашките за съобщения са полезни за отделяне на части от бизнес логиката, управление на тесни места в приложенията и обработка на транзакции (чрез FIFO опашки). AWS Lambda функциите могат да бъдат свързани с SQS опашки като опашки за "зависнали" съобщения, които проследяват непризнати съобщения за последващ анализ. AWS Step Functions (крайни автомати) са много полезни за управление на сложни процеси, изискващи създаване на вериги от функции. Вместо да извиква една функция от друга, Step Functions могат да координират преходите на състояния, да предават данни между функциите и да управляват глобалното състояние на функциите. Това позволява определяне на условия за повторни опити или какво да се прави при специфична грешка — в определени условия, това е много мощен инструмент.
Заключение
През последните години безсървърните технологии се развиват с неведени темпове. С тази смяна на парадигмата са свързани определени заблуди. Благодарение на абстракцията на инфраструктурата и управлението на мащабируемостта, безсървърните решения предлагат значителни предимства: от опростяване на разработката и процесите на DevOps до значително снижаване на оперативните разходи.
И въпреки че безсървърният подход не е лишен от недостатъци, съществуват надеждни методики и шаблони за проектиране, с помощта на които могат да се създадат устойчиви безсървърни приложения или да се интегрират безсървърни елементи в съществуващи архитектури.
Източник: habr.com
