Хоча безсерверні технології останніми роками швидко набирають популярності, з ними все ще пов'язано багато оман і побоювань. Залежність від вендора, інструментарій, управління витратами, холодний старт, моніторинг та життєвий цикл розробки — всі ці теми активно обговорюються, коли йдеться про безсерверні технології. У цій статті ми розглянемо деякі зі згаданих тем, а також поділимося порадами та посиланнями на корисні джерела інформації, за допомогою яких новачки зможуть створити потужні, гнучкі та економічні безсерверні програми.
Помилки щодо безсерверних технологій
Багато хто вважає, що безсерверність та позасерверна обробка даних (, 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 (кінцеві автомати) дуже корисні для керування складними процесами, які потребують створення ланцюжків функцій. Замість Lambda-функція викликала іншу функцію, Step-функції можуть координувати переходи станів, передавати дані між функціями і керувати глобальним станом функцій. Це дає змогу визначати умови повторних спроб або що потрібно робити при виникненні конкретної помилки — в певних умовах дуже потужний інструмент.
Висновок
Останніми роками безсерверні технології розвиваються небаченими темпами. З цією зміною парадигми пов'язані певні помилки. Завдяки абстрагуванню інфраструктури та управління масштабуванням безсерверні рішення пропонують значні вигоди: від спрощення розробки та DevOps-процесів до великого зниження операційних витрат.
І хоча безсерверний підхід не позбавлений недоліків, проте існують надійні методики патерни проектування, за допомогою яких можна створити стійкі безсерверні програми або інтегрувати безсерверні елементи в архітектуру.
Джерело: habr.com