Въпреки че безсървърните технологии бързо добиват популярност в последните години, все още съществуват много погрешни схващания и притеснения около тях. Зависимост от доставчика, инструменти, управление на разходите, студен старт, мониторинг и жизнен цикъл на разработката — всички тези теми активно се обсъждат, когато става въпрос за безсървърни технологии. В тази статия ще разгледаме някои от споменатите теми и ще споделим съвети и линкове към полезни източници на информация, с помощта на които начинаещите могат да изградят мощни, гъвкави и икономични безсървърни приложения.
Погрешни схващания за безсървърните технологии
Много хора смятат, че безсървърността и обработката на данни без сървър (, 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 е отличен инструмент с отворен код, който ви позволява да конфигурирате всичко с помощта на много мощни 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, които подобряват производителността и помагат значително при студени стартирания.
Зависимостта на безсървърните функции от събитията в началото може да затрудни координирането на бизнес логиката. В тази връзка опашките за съобщения и автоматите на състоянията могат да бъдат изключително полезни. Lambda функциите могат да извикват една друга, но правете това само ако не очаквате да получите отговор («изпрати и забрави») — вие не искате да получавате сметка за чакане на завършването на друга функция. Опашките за съобщения са полезни за отделяне на части от бизнес логиката, управление на тесните места в приложенията и обработка на транзакции (чрез FIFO опашки). AWS Lambda функциите могат да бъдат приписани на SQS опашки като опашки за
Заключение
В последните години безсървърните технологии се развиват с небивали темпове. С тази смяна на парадигмата са свързани определени заблуди. Благодарение на абстрахирането на инфраструктурата и управлението на скалируемостта, безсървърните решения предлагат значителни предимства: от опростяване на разработката и процесите на DevOps до значително намаляване на оперативните разходи.
И въпреки че безсървърният подход не е лишен от недостатъци, съществуват надеждни техники и дизайнерски шаблони, с помощта на които могат да се изградят устойчиви безсървърни приложения или да се интегрират безсървърни елементи в съществуващи архитектури.
Източник: habr.com
