Архітектура Serverless-First

Serverless-first погано підходить для довготривалих процесів, що перевищують 15 хвилин, навантажень, що вимагають постійних WebSocket з'єднань, застосунків зі стабільним трафіком високої пропускної здатності, де зарезервована потужність дешевша, і систем, що потребують низькорівневої конфігурації OS або мережі. MicrocosmWorks оцінює кожне навантаження щодо цих обмежень під час проектування архітектури та рекомендує гібридні підходи, де serverless обробляє API кінцеві точки та обробку подій, тоді як контейнери або VMs виконують навантаження, що потребують постійних обчислень. Цей прагматичний підхід дозволяє уникнути поширеної помилки примусового інтегрування кожного компонента в serverless, коли він не підходить.

MicrocosmWorks зменшує «холодні старти» Lambda за допомогою підготовленої одночасності для критичних кінцевих точок, оптимізації пакетів функцій для скорочення часу ініціалізації та стратегічного використання Lambda SnapStart для робочих навантажень Java, що скорочує «холодні старти» з секунд до мілісекунд. Ми також проєктуємо застосунки так, що чутливі до затримки шляхи використовують легковагові середовища виконання, такі як Node.js або Python, з мінімальними залежностями, утримуючи «холодні старти» нижче 200 мс навіть без підготовленої одночасності. Для кінцевих точок, де навіть така затримка є неприйнятною, ми використовуємо Lambda@Edge або CloudFront Functions для відповідей менш ніж 10 мс.

MicrocosmWorks налаштовує локальні середовища розробки, використовуючи такі інструменти, як SST (Serverless Stack), LocalStack або офлайн-режим Serverless Framework, які емулюють хмарні сервіси на машині розробника з майже виробничою точністю. Ми реалізуємо набори інтеграційних тестів, які запускаються в тимчасових хмарних середовищах, що створюються для кожного pull request, тому розробники можуть перевіряти роботу проти реальних сервісів AWS без спільного використання staging-середовища. Цей подвійний підхід забезпечує швидкі локальні ітераційні цикли для розробки, водночас виявляючи специфічні для хмари проблеми до того, як код потрапить у продакшн.

MicrocosmWorks виявила, що безсерверні рішення значно дешевші для застосунків зі змінними або піковими схемами трафіку — часто на 70-90% дешевше, ніж еквівалентні постійно активні розгортання контейнерів — але перевага у вартості зменшується при стабільній пропускній здатності понад 10-20 мільйонів викликів на місяць. Ми створюємо моделі прогнозування витрат під час проєктування архітектури, які порівнюють ціноутворення безсерверних рішень за виклик із зарезервованою потужністю контейнерів для ваших конкретних схем трафіку, включаючи приховані витрати, такі як плата за API Gateway та комісії за передачу даних. Наша служба оптимізації, доступна за консультаційними тарифами $10-$35/год, регулярно переглядає рахунки за безсерверні послуги для виявлення марнотратства через надмірно виділену пам'ять, надмірну тривалість функцій або непотрібне використання API Gateway.

MicrocosmWorks використовує проксі-сервери для пулінгу з'єднань, такі як Amazon RDS Proxy або PgBouncer, розгорнуті як постійний шар між функціями Lambda та базою даних, що мультиплексує тисячі з'єднань Lambda в керований пул фактичних з'єднань з базою даних. Ми також розробляємо бессерверні програми, щоб віддавати перевагу DynamoDB або іншим безз'єднаннєвим базам даних для робочих навантажень з високою паралельністю, де пулінг з'єднань все одно створював би вузькі місця. Для програм, які повинні використовувати реляційні бази даних, ми впроваджуємо ліміти масштабування, що враховують з'єднання, які обмежують одночасні виклики Lambda відповідно до ємності з'єднань бази даних.