Безсерверні фреймворки. Мій рейтинг п’яти найкращих для 2023 року

Привіт! Мене звати Артур, я — Front-end-розробник у компанії ISSoft Ukraine. Я працюю у цій сфері протягом останніх чотирьох років. Мій досвід поєднує як розробку маленьких вебзастосунків з базовим API, так і великих проєктів зі складною інфраструктурою та великою кількістю операцій з даними.

Якщо маленькі проєкти не вимагали великої уваги до серверної частини, то великі застосунки потребують узгодженої роботи всіх компонентів, особливо у мікросервісній архітектурі. І в міру зростання проєкту дедалі частіше поставало питання побудови архітектури та інфраструктури для забезпечення максимальної швидкодії та мінімізації використання обчислювальних можливостей.

Проте всі рішення не проходили перевірку часом і проблема поставала знов і знов, з кожним витком масштабування проєкту. Як на мене, в цьому простежується певна закономірність. Я не беруся казати, що всі проєкти спіткає подібна доля, але частка тих, що мають подібні проблеми — левова.

Тож, ще у 2010 році починають з’являтись перші рішення, що дозволяють користувачам розробляти, запускати та обслуговувати застосунки на базі єдиної платформи. Пізніше це «явище» назвуть FaaS (Function as a Service), що дозволить стати йому на одному рівні з PaaS (Platform as a Service), що так добре прижився на той момент у світі розробки.

В багатьох речах ці два принципи схожі, але якщо у випадку PaaS на сервері має бути запущений хоча б один процес, і масштабування досягається завдяки збільшенню кількості таких процесів, то FaaS не вимагає такого підходу. Проте запит до такого серверу може виконуватись повільніше.

Хоча кешування даних, що мають відношення до певних запитів, дещо покращує ситуацію, в цілому розробник «платить» часом обробки запиту за можливість масштабування з мінімальними витратами.

Але варто розуміти, що «serverless» — це, швидше, не про відсутність сервера, як такого, а про зміщення фокуса з конфігурації сервера, його обслуговування, суто на розробку застосунку.

Наразі безсерверні технології доволі розповсюджені, і у цій статті ви дізнаєтесь про 5 найпопулярніших фреймворків, що дозволять збудувати власний serverless застосунок.

1. Serverless

Serverless framework — open-source фреймворк, що спочатку був створений для того, щоб допомогти розробникам будувати застосунки на базі AWS Lambda. Тепер це один з найпопулярніших фреймворків для розробки serverless-архітектури.

Фреймворк дозволяє розробляти та збирати застосунки для AWS, Azure, GoogleCloud та інших. Serverless використовує YAML для швидкого розгортання коду та інфраструктури. Розробка доступна на таких мовах, як Node.js, Java, Python, C#, Ruby, Kotlin, Swift, PHP, F# and Scala.

Вся інфраструктура, необхідна для розробки, може бути автоматично створена Serverless Framework. Якщо вам не вистачає якогось функціоналу out-of-box, середовище розробки може бути кастомізоване під ваші потреби за допомогою плагінів, які пропонує Serverless Inc.

Фреймворк настільки гнучкий у використанні, що може допомогти як у запуску декількох лямбда-функцій, так і для створення комплексних рішень, що налічують у собі сотні функцій.

Наразі Serverless Framework має 43 тисячі зірок на GitHub, що робить його найпопулярнішим серед інших.

2. AWS Chalice

AWS Chalice — фреймворк, що дозволяє створювати serverless-архітектуру для багатьох AWS сервісів. В основному сфокусований на створенні вебзастосунків та REST API. Фреймворк з’явився на ринку не так давно, та вже встиг заробити свою славу як одного з популярних фреймворків для розробки serverless-рішень.

Основна та поки єдина мова програмування для розробки в середовищі Chalice — Python, і планів додавати підтримку інших мов поки не спостерігається. Проте фреймворк, за допомогою власних декораторів, дозволяє інтегруватись з Amazon API Gateway, Amazon S3, Amazon SNS, Amazon SQS та іншими сервісами від Amazon.

Платформа Chalice дає змогу контролювати життєвий цикл застосунку протягом всього часу його існування. Фреймворк дозволяє швидко розгорнути REST API на AWS завдяки Chalice CLI, а створення пайплайнів для СI/CD тепер доступне у декілька команд, оскільки Chalice створює їх автоматично, використовуючи AWS CodeBuild та CodePipeline.

3. Claudia.js

Claudia.js — скоріше не фреймворк, а засіб для розгортання коду на AWS Lambda та API Gateway. Але за допомогою цього інструменту ви з легкістю зможете створити JS-середовище та автоматизувати кроки, пов’язані з конфігурацією та розгортанням коду на платформі.

Це означає, що розробник може почати розробляти мікросервіси для Lambda, не переймаючись за deployment-процеси.

Причиною появи даного інструменту розробники назвали складність створення середовищ AWS Lambda та API Gateway, навіть для найпростіших сценаріїв. Також їх розгортка недостатньо документована для початківців, тому Claudia.js автоматизує ці процеси.

Як видно з назви, Claudia.js підтримує тільки JavaScript як доступну мову для розробки. Також у документації на офіційному сайті є два додатки, що дозволяють реалізувати REST API на основі API Gateway або створити чат-бот. На додаток, Claudia дає змогу працювати над декількома версіями застосунку одночасно.

4. Zappa

Розглянемо ще один фреймворк для Python. Zappa дозволяє розробляти та розгортати безсерверні застосунки для AWS Lambda. Варто додати, що це не єдина заслуга Zappa. Фреймворк також дає змогу будувати проєкти та застосунки на основі WSGI (Web Server Gateway Interface).

Слоган фреймворку Zappa — «без постійної інфраструктури». Його опис говорить, що кожен сервер живе близько 40 мілісекунд. Після виконання запиту процес завершується, а сервер йде в downtime до наступного запиту.

Zappa також підтримує інші Python-фреймворки, як, наприклад, Django або Flask. Завдяки цій сумісності він є чудовим рішенням для складних вебзастосунків, як аналізатори тексту, зображень або складних обчислень.

Також фреймворк дозволяє реалізувати identity and access management (IAM) та аутентифікацію за замовчуванням.

Головна особливість, на мою думку, — можливість розгорнути або оновити застосунок всього однією командою.

5. Flogo

Flogo — фреймворк, що дозволяє розробляти безсерверні застосунки на основі Docker. На відміну від інших рішень, він має не тільки CLI, а й графічний вебінтерфейс для створення рішень для AWS Lambda.

Ядро Flogo написане на Golang. Фреймворк спочатку був розроблений, як комплексне рішення для декількох приватних компаній, але пізніше став open-source продуктом. Оскільки Flogo створений під конкретні потреби, найбільше його потенціал розкривається у роботі з machine-learning моделями. Застосунки, написані використовуючи Flogo, широко використовуються у IoT-девайсах.

Основна мета, для чого слід використати цей фреймворк — запровадження потоку даних між мікросервісами, його обробка та відповідна реакція на події з потоку. Тобто створивши обробник конкретних подій з потоку, Flogo дає змогу використовувати його в будь-якому місці, зменшуючи витрати часу на впровадження нового функціоналу та збільшуючи перевикористання раніше написаного коду або створених раніше компонентів.

Варто зазначити, що графічний інтерфейс дає змогу розробляти застосунки, не написавши при цьому ані рядка коду.

Висновок

Тож, ми розглянули декілька рішень для розробки безсерверного застосунку, які ви можете використати й у власних проєктах. Технології, описані вище, дозволять вам розгортати власні застосунки на необхідних cloud-платформах швидше та масштабувати їх з мінімальними витратами ресурсів. Розробники мають витрачати ідеї та натхнення на створення нових рішень, а не на інфраструктуру.

Безсерверні технології — новий щабель у розробці та розгортанні хмарних застосунків. Безперечно, з плином часу з’явиться ще більше інструментів для розробки безсерверних рішень, що не тільки дадуть змогу полегшити процес створення та публікації застосунків, а й зберегти кошти та робочі ресурси й запровадити нові ідеї до вже наявних.

Але вже зараз технології дозволяють нам створити щось зовсім нове, що значною мірою покращить продуктивність та полегшить повсякденне життя.

Корисні посилання:

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному12
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

У розділі про Claudia.js є згадування Chalice

Також їх розгортка недостатньо документована для початківців, тому Chalice автоматизує ці процеси.

воно там якось сумісно працює?

Велике дякую за Вашу уважність! Це різні інструменти, а згадка про Chalise — помилка.

Ви пропустили цілу плеяду faas імплементацій на основі куба.

Дякую за коментар! Не заперечую, поле для рішень — величезне. Можливо, ця стаття матиме продовження в майбутньому, то, думаю, ще буде можливість щось доповнити чи описати!

Щось з цього хоч якось інтегрується нормально з Terraform та працює на Kubernetes ?
Нормально, тобто не отак й хоча б отак з Knative, але у Flogo забагато накручених бенчмарків, й нема порівняння навіть з тим же knative-eventing, або ж навіть якимось Argo Events...

З хороших рішень можу відмітити хіба що з натяжкою Triggermesh та Temporal.

У Dapr дуже погана реалізація State Store та блокування через Redis.
Немає взагалі ніяких примітивів для роботи з CDC, та вони ніяк не синхронізують лічильники транзакцій з поточними лічильниками CRDT в відповідних EDA. По CQRS’у немає жодного життєздатного підходу керування AP/CP cховищами, разом з логом станів, реляціними проекціямі, та відповідними синхронізаційними примітивами (блокуюче читання/запис у різних рівнях ізоляції транзакцій).

Тобто, а де ж там у Dapr’і DBA ?

фреймворки класні)
маю питання щодо цього "

безсерверного застосунку

"
які переваги serverless якщо це application, а не мікрофункція ?
моє сприйняття було, що serverless це для once a day або on demand function адвантадж якої в тому, що вона швидко стартанула виконалася і погасла — зарахунок цього економляться гроші бо треба постійно тримати контейнер і платити за цього

google (firebase) cloud functions, azure functions, aws lambda мають свої нативні api для різних мов — мені не зрозуміло які переваги дає використання фреймворку :(

в теорії, перевага — ще менше налаштувань інфраструктури ніж в platform as a service

IaC нема — серйозно використовувати такі речі дуже ризиковано та безвідповідально...
Питання не в кількості налаштувань, а в атомарності їх змін, версіонованості, можливостях тестування та відкату... або «про те що DevOps то не посада, а методологія... а все інше — простo карго культ».

мені більше подобається мінідатацентр апроач де кубер кластер розгорнутий

Там не все так добре, бо навіть існуючі дистрибутиви kubernetes по типу ecs anywhere та RKE2 також не інтегровані з відповідними IaC рішеннями. Та й серед Сontainer Linux дистрибутивів по типу FlatCar та Bottlerocket є проблеми з ліцензуванням та повноцінною підтримкою selfhosted оточень, a coreos працює нормально лише з OpenShift... життєвий цикл кубів доволі складний й поновлення кластерів та сертифікатів — це перше з чого починається автоматизація керування відповідними оточеннями. До купи зараз майже ніхто те зліпив, бо треба стабільна конвенція розробки операторів.

Managed Kubernetes по типу EKS/AKS також мають проблеми з поновленнями та періодично відвалюються — мало чим відрізняються від того що люди збирають та автоматизують самостійно.

Куби то не відповідь на будь-яке питання, й не endgame, лиш фреймворк для побудови власної платформи з купою інструментів, які періодично відмирають та ламаються... й в нього особливо то й немає конкуренції.

Планую публікацію власного CNCF дистрибутиву (налаштовано ~40 різних інструментів поверх кубів) зі стеком операторів на Knative+Metacontroller та актуальними архітектурними підходами з CQRS-ES під PostgreSQL + ScyllaDB. Можливо зайду з ним в CNCF та можливо опублікую якихось статей на DOU, щоб розбавить посередність...

Думаю, тут застосунок у значенні «набір пов’язаних мікрофункцій».

Теоретично, немає серверної обв’язки усіх інфраструктурних складнощів типу роутінгу, логування, баз даних, мейл серверу і т.п.

Тобто, замість того, щоб кожен мікросервіс мав свій стек «база даних — API», тут пропонується розділяти сервіси, що є обв’язкою даних, та сервіси-контролери, що просто виконують бізнес-логіку у відповідь на якісь події.

Мабуть, така архітектура має зміст там, де застосунок не має чітких кордонів, де застосунок — це вся бізнес-сфера організації. Вона має зміст у lowcode-nocode платформах, де код писати все ж таки треба, але мейнтейнити важкий сервер не хочеться.

Думаю, тут застосунок у значенні «набір пов’язаних мікрофункцій».

Теоретично, немає серверної обв’язки усіх інфраструктурних складнощів типу роутінгу, логування, баз даних, мейл серверу і т.п.

Тобто, замість того, щоб кожен мікросервіс мав свій стек «база даних — API», тут пропонується розділяти сервіси, що є обв’язкою даних, та сервіси-контролери, що просто виконують бізнес-логіку у відповідь на якісь події.

Мабуть, така архітектура має зміст там, де застосунок не має чітких кордонів, де застосунок — це вся бізнес-сфера організації. Вона має зміст у lowcode-nocode платформах, де код писати все ж таки треба, але мейнтейнити важкий сервер не хочеться.

Так, ви праві, serverless — це про FaaS. Під «застосунком» я мав на увазі набір функцій, що використовуються у спільному контексті. В принципі, остання відповідь на Ваш коментар доволі влучно описує те, що я мав на увазі!

Дякую, чудовий огляд.

Підписатись на коментарі