Ключові моменти
- Вже кілька років нам обіцяють, що безсерверні обчислення (serverless) відкриють нову епоху без конкретної ОС до виконання додатків. Нам говорили, що така структура вирішить безліч проблем масштабованості. Насправді все інакше.
- Хоча багато хто розглядає безсерверну технологію як нову ідею, її коріння можна простежити аж до 2006 року, коли з'явилися Zimki PaaS та Google App Engine – в обох випадках використовується безсерверна архітектура.
- Є чотири причини, через які безсерверна революція зайшла в глухий кут: від обмеженої підтримки мов програмування до проблем з продуктивністю.
- Безсерверні обчислення не такі вже й марні. Зовсім ні. Проте їх слід розглядати як пряму заміну серверів. Для деяких програм вони можуть бути зручним інструментом.
Сервер мертвий, нехай живе сервер!
Так звучить бойовий клич адептів безсерверної революції. Досить швидко переглянути галузеву пресу останніх кількох років, і можна легко дійти висновку, що традиційна серверна модель мертва і через кілька років ми всі будемо використовувати безсерверні архітектури.
Як відомо будь-кому в галузі, і як ми також вказували в нашій статті про , це не так. Незважаючи на безліч статей про переваги , вона так і не відбулася. Насправді, , Що ця революція, можливо, зайшла в глухий кут.
Деякі з обіцянок для безсерверних моделей, безперечно, були реалізовані, але не всі. Далеко не все.
У цій статті хочу розглянути причини такого стану. Чому відсутність гнучкості безсерверних моделей все ще є перешкодою для їх ширшого впровадження, хоча вони залишаються корисними в конкретних, чітко визначених обставинах.
Що обіцяли адепти безсерверних обчислень
Перш ніж перейти до проблем безсерверних обчислень, погляньмо, що вони повинні були забезпечити. були численними і часом дуже амбітними.
Для тих, хто не знайомий із терміном, ось коротке визначення. Безсерверні обчислення визначають архітектуру, в якій програми (або частини додатків) виконуються на вимогу в середовищах виконання, які зазвичай розміщуються віддалено. Крім того, безсерверні системи можна захистити у себе. Протягом кількох останніх років створення стійких безсерверних систем було головною турботою системних адміністраторів та SaaS-компаній, оскільки (як стверджується) ця архітектура пропонує кілька ключових переваг у порівнянні з «традиційною» клієнт-серверною моделлю:
- Безсерверні моделі не вимагають, щоб користувачі підтримували власні операційні системи або навіть створювали програми, сумісні з ОС. Натомість розробники створюють загальний код, завантажують його в безсерверну платформу та спостерігають за його виконанням.
- Ресурси в безсерверних фреймворках зазвичай оплачуються за хвилинами (або секундами). Це означає, що клієнти платять лише за час, коли вони фактично виконують код. Це вигідно відрізняється від традиційної хмарної VM, де машина більшу частину часу простоює, але за неї доводиться платити.
- Проблема масштабованості також вирішувалася. Ресурси в безсерверних фреймворках призначаються динамічно, тому система легко справляється з раптовими сплесками попиту.
Коротше кажучи, безсерверні моделі забезпечують гнучкі, дешеві рішення, що масштабуються. Дивно, що ми не здогадалися до цієї ідеї раніше.
Це справді нова ідея?
Насправді, ідея не нова. Концепція, що дозволяє користувачам платити тільки за той час, коли код фактично запускається, існує з того часу, як вона була введена в рамках в 2006 році, і приблизно в той же час Google App Engine запропонував дуже схоже рішення.
Насправді те, що ми зараз називаємо «безсерверною» моделлю, старшою за багато технологій, які зараз називають «нативними хмарними», і які забезпечують майже те саме. Як уже зазначалося, безсерверні моделі, по суті, є лише продовженням бізнес-моделі SaaS, яка існує вже кілька десятиліть.
Також варто визнати, що безсерверна модель не є архітектурою FaaS, хоч між ними є зв'язок. FaaS - це, по суті, орієнтована на обчислення частина безсерверної архітектури, але вона не представляє всю систему цілком.
Так до чого весь цей галас? Що ж, оскільки швидкість проникнення інтернету в країни, що розвиваються, продовжує стрімко зростати, одночасно зростає попит на обчислювальні ресурси. Наприклад, у багатьох країнах з секторами електронної комерції, що швидко зростають, просто немає обчислювальної інфраструктури для додатків на цих платформах. Ось тут і з'являються платні безсерверні платформи.
Проблеми безсерверних моделей
Загвоздка в тому, що безсерверні моделі мають... проблеми. Не зрозумійте мене неправильно: я не кажу, що вони погані власними силами або не забезпечують суттєвої цінності для деяких компаній у деяких обставинах. Але головне твердження «революції», що безсерверна архітектура швидко замінить традиційну, ніколи не реалізується.
Ось чому.
Обмежена підтримка мов програмування
Більшість безсерверних платформ дозволяють запускати лише ті програми, які написані певними мовами. Це серйозно обмежує гнучкість та адаптивність цих систем.
Вважається, що безсерверні платформи підтримують більшість основних мов. AWS Lambda та Azure Functions також надають оболонку для запуску програм і функцій мовами, що не підтримуються, хоча це часто пов'язано з витратами на продуктивність. Тож більшість організацій зазвичай це обмеження немає великого значення. Але ось у чому річ. Передбачається, що одна з переваг безсерверних моделей в тому, що маловідомі програми, що рідко використовуються, можна використовувати дешевше, оскільки ви платите тільки за час їх виконання. А маловідомі програми, що рідко використовуються, часто пишуться на... маловідомих, рідко використовуваних мовах програмування.
Це підриває одну із ключових переваг безсерверної моделі.
Прив'язка до вендору
Друга проблема з безсерверними платформами або принаймні з тим, як вони реалізуються в даний час, полягає в тому, що вони зазвичай не схожі один на одного на операційному рівні. Практично немає стандартизації у частині написання функцій, деплою та управління. Це означає, що міграція функцій з однієї платформи на іншу займає дуже багато часу.
Найважча частина переходу на безсерверну модель — це не обчислювальні функції, які зазвичай є просто фрагментами коду, а те, як програми пов'язані з підключеними системами, такими як сховище об'єктів, управління ідентифікацією та черги. Функції можна перемістити, але решту програми — ні. Це повна протилежність обіцяним дешевим та гнучким платформам.
Деякі стверджують, що безсерверні моделі з'явилися нещодавно, і не було часу стандартизувати їхню роботу. Але вони не такі вже й нові, як я вже зазначав вище, і багато інших хмарних технологій, таких як контейнери, вже стали набагато зручнішими завдяки розробці та широкому впровадженню добрих стандартів.
Продуктивність
Обчислювальну продуктивність безсерверних платформ важко виміряти, частково тому, що вендори прагнуть зберегти інформацію в таємниці. Більшість стверджує, що функції на віддалених безсерверних платформах працюють так само швидко, як і на внутрішніх серверах, за винятком кількох неминучих проблем із затримкою.
Проте окремі факти свідчать про протилежне. Функції, які раніше не запускалися на певній платформі або не запускалися протягом певного часу, потребують певного часу для ініціалізації. Ймовірно, це пов'язано з тим, що їхній код було перенесено на якийсь менш доступний носій даних, хоча, як і у випадку з бенчмарками, більшість вендорів не скажуть вам про перенесення даних.
Звісно, є кілька способів обійти це. Один з них полягає в оптимізації функцій для будь-якої хмарної мови, якою працює ваша безсерверна платформа, але це дещо підриває твердження про те, що ці платформи є «гнучкими».
Інший підхід полягає в тому, щоб забезпечити регулярне виконання критично важливих для продуктивності програм, щоб вони залишалися свіжими. Цей другий підхід, звичайно, трохи суперечить твердженню, що безсерверні платформи економічніші, тому що ви платите лише за час роботи ваших програм. Хмарні провайдери впровадили нові способи скорочення холодних запусків, але багато хто з них вимагає «масштабування до одного» (scale to one), що підриває первинну цінність FaaS.
Проблему «холодного запуску» можна частково вирішити шляхом запуску безсерверних систем самотужки, але це з власними витратами і залишається нішевим варіантом для добре забезпечених ресурсами команд.
Ви не можете запускати цілі програми
Зрештою, можливо, найважливіша причина, через яку безсерверні архітектури не замінять традиційні моделі найближчим часом: на них (як правило) не можна запускати цілі програми.
Точніше, це недоцільно з погляду витрат. Ваш успішний моноліт, ймовірно, не варто перетворювати на набір із чотирьох десятків функцій, пов'язаних вісьмома шлюзами, сорока чергами та дюжиною екземплярів БД. Тому serverless краще підходить для нових розробок. Практично жодну існуючу програму (архітектуру) не можна перенести. Ви можете мігрувати, але доведеться починати з нуля.
Це означає, що в переважній більшості випадків безсерверні платформи використовуються як доповнення до внутрішніх серверів для виконання завдань, що потребують великих обчислень. Це дуже сильно відрізняє їх від двох інших форм хмарних технологій – контейнерів та віртуальних машин, які пропонують цілісний спосіб виконання віддалених обчислень. Це ілюструє одну з проблем переходу від мікросервісів до безсерверних систем.
Звичайно, це не завжди є проблемою. Можливість періодично використовувати величезні обчислювальні ресурси, не купуючи власне залізо, може дати реальну і довготривалу користь багатьом організацій. Але якщо деякі програми знаходяться на внутрішніх серверах, а інші на безсерверних хмарних архітектурах, то управління виходить на новий рівень складності.
Хай живе революція?
Незважаючи на всі ці скарги, я не проти безсерверних рішень як таких. Чесне слово. Просто розробники повинні розуміти, особливо якщо вони вперше досліджують безсерверні моделі, що ця технологія не є прямою заміною серверів. Замість цього ознайомтеся з нашими порадами та ресурсами щодо і вирішіть, як найкраще застосувати цю модель.
Джерело: habr.com