AWS Lambda та Serverless-архітектура: коли сервери зникають

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт! Мене звати Сергій Чербаджи, я розробник із семирічним стажем. За цей час я набув цінного досвіду, працюючи більше п’яти років у компанії ProHabits, де я зараз обіймаю позицію технічного тимліда. Моє захоплення — це розбір та аналіз різноманітних технічних рішень.

Це моя друга стаття на DOU, з першою можете ознайомитись тут: «Мистецтво ефектних мініатюр для відео: вчимося у Netflix». Я планую серію статей на тему підключення різних баз даних та створення телеграм-бота. Це буде корисно для тих, хто не знав, як почати використовувати лямбди, а також для тих, хто хоче перейти з звичайного сервера на Serverless.

Ці статті допоможуть зрозуміти, як інтегрувати різні бази даних з AWS Lambda, а також як створити телеграм-бота, який може автоматизувати багато завдань. Кожна стаття буде містити детальні інструкції та приклади коду, щоб читачі могли легко застосувати отримані знання на практиці. Для тих, хто ще не знайомий з лямбдами, ці матеріали стануть відправною точкою, допоможуть освоїтися в нових технологіях і зробити перехід на Serverless-архітектуру простішим та зрозумілішим.

Вступ

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

Що таке безсерверна архітектура

Безсерверна архітектура — це як та невидима рука, що керує всім без зайвих зусиль розробника. Не треба вже нам піклуватися про сервери, адже хмарні сервіси беруть на себе цю ношу. Вони надають усі необхідні ресурси та автоматично підлаштовуються під навантаження. У цій архітектурі присутні функції (як-от AWS Lambda), API-шлюзи, бази даних та хмарне сховище.

AWS Lambda

AWS Lambda — це наче невидимий чарівник від Amazon Web Services, що дозволяє розробникам створювати функції, які з’являються у відповідь на різні події. Цей чарівник сам керує серверами та підлаштовує ресурси залежно від навантаження. Мови програмування, які він розуміє, — це Python, Node.js, Java та інші.

Процес створення AWS Lambda

Створимо просту функцію AWS Lambda, що повертає вітальне послання. Ось шлях до цієї мети:

Створення облікового запису в AWS Management Console:

  • Відвідайте AWS Management Console та створіть обліковий запис, якщо його ще немає.

Перехід до AWS Lambda:

  • У меню виберіть Services та знайдіть Lambda у розділі Compute. Перехід до AWS Lambda
  • Натисніть на Create function. Варто пам’ятати, що регіон впливає на ціну та видимість функції Lambda. Наприклад, якщо функція створена в регіоні us-east-1, вона не буде видима в інших регіонах. Про ціни поговоримо згодом.

Створення нової функції:

  • виберіть Author from scratch;
  • вкажіть ім’я функції, наприклад test;
  • виберіть середовище виконання (Runtime), наприклад, Node.js 20.x;
  • виберіть архітектуру arm64 (вона дешевша) або залиште x86_64;
  • у Advanced settings увімкніть Enable function URL, якщо бажаєте викликати Lambda за URL, і виберіть NONE у Auth type для публічного доступу до функції; Створення нової функції
  • натисніть Create function.

Перевірка роботи функції

Відкрийте URL у новому вікні та переконайтеся, щоб бачите відповідь від Lambda. Відкрийте URL у новому вікні Перейдіть до сервісу CloudWatch для перегляду логів. У меню виберіть Services та знайдіть CloudWatch у розділі Management & Governance. Перейдіть до Logs -> Log Groups -> /aws/lambda/test і виберіть потрібний Log Stream для перегляду логів. Перегляд логів

Приклад коду AWS Lambda

exports.handler = async (event) => {
    const path = event.resource; // or event.path
    const httpMethod = event.httpMethod;

    switch (path) {
        case '/users':
            if (httpMethod === 'GET') {
                // Handle GET request for /users
                return getUsersResponse();
            }
            // Add more HTTP methods as needed
            break;
        case '/posts':
            if (httpMethod === 'GET') {
                // Handle GET request for /posts
                return getPostsResponse();
            }
            // Add more HTTP methods as needed
            break;
        default:
            return {
                statusCode: 404,
                body: JSON.stringify({ message: 'Not Found' })
            };
    }
};

function getUsersResponse() {
    const users = [{ id: 1, name: 'Alice' }, { id: 2, name: 'Bob' }];
    return {
        statusCode: 200,
        body: JSON.stringify(users)
    };
}

function getPostsResponse() {
    const posts = [{ id: 1, title: 'Hello World' }, { id: 2, title: 'Serverless AWS' }];
    return {
        statusCode: 200,
        body: JSON.stringify(posts)
    };
}

Цей код представляє функцію AWS Lambda, яка обробляє HTTP-запити для двох різних ресурсів: /users та /posts.

Обробка подій

Функція exports.handler є основною точкою входу, яка обробляє події. Вона отримує параметр event, який містить інформацію про запит, зокрема шлях (path) і HTTP-метод (httpMethod).

Маршрутизація

Залежно від шляху (path) та HTTP-методу, код визначає, який обробник викликати. Якщо шлях /users і метод GET, викликається функція getUsersResponse. Якщо шлях /posts і метод GET, викликається функція getPostsResponse.

Функції-обробники

getUsersResponse: Повертає список користувачів у вигляді JSON. 
getPostsResponse
: Повертає список постів у вигляді JSON.

Статуси відповідей

Якщо шлях не відповідає жодному з оброблюваних, функція повертає статус 404 з повідомленням «Не знайдено».

Недоліки безсерверної архітектури (AWS Lambda)

  1. «Холодні» запуски: перший запуск функції може зайняти більше часу.
  2. Обмежене середовище виконання: існують обмеження за часом виконання та використанням пам’яті.
  3. Складнощі в налагодженні та моніторингу: налагодження та моніторинг можуть бути складнішими, ніж у традиційних архітектурах.
  4. Прив’язаність до постачальника послуг: використання специфічних сервісів може ускладнити перехід на інші платформи.
  5. Обмеження продуктивності: у деяких випадках продуктивність може бути нижчою порівняно з традиційними серверами.
  6. Мережева затримка під час взаємодії сервісів: взаємодія між різними сервісами може викликати додаткові затримки.

Переваги безсерверної архітектури

  1. Зменшення витрат на керування серверами: оплата тільки за фактичне використання ресурсів.
  2. Автоматичне масштабування ресурсів: автоматичне налаштування кількості ресурсів залежно від поточного навантаження.
  3. Економічна ефективність: зниження витрат на інфраструктуру та експлуатацію.
  4. Збільшення швидкості розробки застосунків: спрощення процесу розгортання та керування застосунками.
  5. Поліпшення безпеки та надійності застосунків: менше вразливостей, пов’язаних з керуванням інфраструктурою.

Приклади використання AWS Lambda

  1. Створення RESTful API: швидке створення та розгортання API без необхідності керування серверами.
  2. Обробка зображень та відео: автоматична обробка медіафайлів під час завантаження.
  3. Аналіз даних та створення звітів: реалізація функцій аналізу даних, запуск яких ініціюється за розкладом або за подіями.
  4. Обробка даних у реальному часі: обробка потоків даних з IoT-пристроїв або логів.

Ціни на AWS Lambda

Ціноутворення AWS Lambda базується на двох ключових компонентах: кількість запитів та тривалість виконання.

  1. Кількість запитів: перший мільйон запитів на місяць безкоштовно. Після цього $0.20 за мільйон запитів.
  2. Тривалість виконання: ви оплачуєте час виконання вашої функції, округлений до найближчої мілісекунди, і кількість пам’яті, яку ви виділили для функції. Перші 400,000 ГБ-секунд на місяць безкоштовно. Після цього $0.0000166667 за ГБ-секунду (залежить від регіону).

Приклад:

  • Якщо ваша функція використовує 128 MБ пам’яті та виконується секунду, ви заплатите $0.000002083 за один запуск.
  • Якщо у вас мільйон таких запусків на місяць, це коштуватиме $2.08.

Докладну інформацію про ціни можна знайти тут.

Які аналоги AWS Lambda існують

AWS Lambda є одним з лідерів на ринку безсерверних рішень, але існують інші сервіси, що пропонують схожі можливості:

  • Google Cloud Functions: аналог від Google Cloud Platform, що також дозволяє запускати функції у відповідь на події. Підтримує багато мов програмування та інтеграцію з іншими сервісами Google Cloud.
  • Azure Functions: рішення від Microsoft Azure, що підтримує кілька мов програмування та тісну інтеграцію з екосистемою Azure, зокрема підтримку DevOps та інструментів моніторингу.
  • IBM Cloud Functions: заснований на платформі Apache OpenWhisk, пропонує аналогічні можливості та інтеграцію з іншими сервісами IBM Cloud.
  • Oracle Functions: побудований на базі Fn Project, підтримує запуск функцій у відповідь на події та інтеграцію з сервісами Oracle Cloud.
  • Alibaba Cloud Function Compute: аналогічний сервіс від Alibaba Cloud, що пропонує схожі можливості для запуску функцій у відповідь на події.

Висновок

Безсерверна архітектура та AWS Lambda відкривають нові можливості для розробників, дозволяючи їм створювати потужні та масштабовані застосунки без необхідності керування серверами. Ця стаття з’явилася завдяки моєму відео на YouTube. Не забудьте підписатися на канал, щоб не пропустити нові відео та залишатися в курсі найсвіжіших новин і корисних порад!

👍ПодобаєтьсяСподобалось16
До обраногоВ обраному10
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

Забули ще про таку проблему, як коннекшени до бази даних. Якщо база реляційна (Postgres) то купа лямбд піднімає таку ж купу з’єднань з базою даних. Треба прикручувати ще RDS Proxy. Але у нас все одно в одному [доволі критичному] мікросервісі були проблеми через конекшени тому перевели той сервіс на DynamoDB.

Згоден, якщо у вас багато користувачів, то так, треба оптимізувати. Гарне доповнення. Дякую.

Зникаючі сервери Шрьодінгера. Вони начебто зникають, але все ще сервять.

AWS Lambda — це наче невидимий чарівник від
Amazon Web Services,

Згадав шкільні твори у 6 класі=)

Автор, свалюй з того болота де ти гребеш. Перед тим здай сертифікації aws dev, aws architect)

Щось ви років на 7 запізнилися зі статтею. Останні тренди — лямбди відстій, мікросервіси — відстій, вендор лок — відстій; великі багатоцільові сервіси — ftw, круто якщо сервіс можна задеплоїти on prem, без переписування половини кодової бази.

круто якщо сервіс можна задеплоїти on prem, без переписування половини кодової бази.

бывают кейсы конгда да, круто. Бывает и наоборот: поднятие всей инфры onprem стоит дурных денег и никому не нужна. Классический пример в которых клауда уделывают onprem: нерегулярные пиковые нагрузки в единицы-десятки раз выше средних.

Після слів «Сьогодні розглянемо цю дивовижну новацію», закінчив читання.

Згоден. Тяжко назвати це

дивовижной новаюцією

. Перейменував, можете продовжувати читання.

і статтю, і коменти ТСа вочевидь пише чатжпт

Переклад покрокового офіційного мануала?

Автор мабуть переплив тису і подається на візу таланту О1

Как админ/девопс/саппортер (Aws certified solution architect associate level) после прочтения статьи я так и не понял «Безсерверна архітектура та AWS Lambda відкривають нові можливості для розробників» какие новые возможности для разработчика, именно для разработчика?

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

В самой же статье указаны недостатки как и лямбды так и без серверной архитектуры. И вопрос целесообразности выбора серверной или бессерверной архитектуры, и если без серверной то лямбда или другие безсерверные решения такие как Fargate или EKS или ECS вне компетенции и разработчиков и sysops. Это преррогатива Solution Architect, а если касается денег, то FinOps.

Автор приколіст, там логарифмічна шкала єсішо, з логарифмічною шкалою паралельні лінії — це різниця в 10х-ки раз :)

Плюс архітектура серверлесс грає велику роль. Лямбди чи azure functions чи якийсь самопал це неефективний лінивий підхід.

Норм серверлесс це в ідеалі на v8 isolates чи щось подібне.

О, оказывается cloudflare workers на них реализованы, любопытно

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

Ще два недоліки на великому enterprise scale та великій кількості лямбд:

— Ліміт кількості Layers/Extensions на одну функцію для складних enterprise use cases. За дизайном Лямбда має все-таки бути невеликою та простою, але завжди знаходяться розробники які намагаються туди покласти якийсь Java моноліт 🥲

— IP exhausting при роботі з ресурсами в VPC

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

Тож воно піходить до дуже простих скриптиків чи якихось хрон джобів, також не дуже складних, чи ловити вебхуки від інших апі і потім вже класти у чергу месаджі.
Але для навіть простого апі серверу, ажур функції то потрукам треба бити :-)

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

Найбільший кайф це ажур функції на пайтоні:) Там і гівняне логування і баги з версіями залежностей і баги при деплої, особливо durable функції які можуть назавжди зафрізнутись на якійсь activity і нічого не відригнути у відповідь:)
Коротше кажучи, як ex. Microsoft Certified Azure Architect Expert можу впевнено сказати що cloud agnostic на кубернетесі — топ за свої гроші:)

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

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

Це як? І на якій платформи ви пишите?

Помилка що джейсон версії 7,0,0,0 не завантажився, навіть якщо ти додаси в нагет пакет. Короч вилазило пару раз, не допомагали основні рецепти зі стек оверфлоу та чат жпт, я не мав багато часу на колупання тож просто замінив лібу на іншу і воно запрацювало, було давненько хоч і на 4 версії. Дотнет 6. Вобщем ажур функція звісно прикольна штука але якщо вона дуже примітивна, в іншому випадку потенційно буде купа проблем.

Це не виглядає як проблема технології, а скоріше специфічний кейс того як ліби виростовувались на проекті — якщо зміна залежностей вирішила проблему. Version downgrade(якщо я вірно зрозумів) може виникнути для будь якого проекту де є кросс-залежності і буде конфлікт десь у version requirements.

У технології(serverless) є очевидний use cases який вона буде вирішувати краще ніж всі альтернативі разом взяті — це можливість в пару строк коду з атрибутими інтегрувати різні cloud services і побудувати workflow з мінімальним залученням в управління оточення виконання. Цього достатньо щоб отримати очевидну користь на проектах де стараються максимізувати вихлоп від того що називають cloud native solutions. Хостити у функціях багатоцільові додатки не розбиваючи їх на прості є неробочим підходом очевидно, якщо слідувати базовим положення з документації для розробників.

Лямбда це один з найдорожчих сервісів в AWS, якщо ви її замість EC2 чи якогось EKS використовуєте то вашого CTO в кінці місяця має серце прихопити, і так кожен місяць :)
А так то да — зручно, якщо якийсь скріптік поганяти

Дякую за ваш коментар! Згоден, що AWS Lambda може бути дорогою, особливо якщо не оптимізувати її використання. Але в багатьох випадках, для коротких і рідкісних завдань, вона залишається зручною і ефективною. Вибір завжди залежить від конкретних потреб проєкту.

для коротких і рідкісних завдань

Для таких завдань байдуже, що лямбди, шо якийсь дешевий сервер взяти.

По грошах выходить що якесь реальне навантаження, ну там 10M запитів на добу (128MB по 0.2 sec) будуть коштувати 180 баксів/month, то вже дуже норм ціна. Але там ще треба доплатити за provisioned concurrency, бо воно зара пусто, а через секунду 500 rps.

Хоча, бази окремо, redis окремо, kafka та elasticsearch окремо (чи cloud аналоги цього), сервера ci/cd окремо, victoria та графана чи інший моніторинг, cdn, сторедж спецс і т.д. Хз скільки там економія реальна буде.

сам принцип «запусти контейнер в к8s бо там нещасна функція для реквеста» це фейл архітектури

Важко уявити дорожчу вартість за ресурси ніж цілий мільйон секунд аж 128мб пам’яті за «всього» 2 бакси на місяць :)

У нас проект на лямбдах, більше 20 мікросервісів, і СТО ходить всюди хвастається що ми за все це платим копійки, коли аналогічні проекти платять кілька тищ доларів в місяць

Кул, добре коли є профіт.
«Один знайомий» розповідав що в них прайс на application сервера (там де крутиться виключно backend логіка) це десь 1/50 від всього cloud прайсу, і якщо він стане 0, то принципово нічого не зміниться, порівняно з іншими затратами dou.ua/...​rums/topic/49698/#2866988

Воно реально від масштабу залежить, бо 100M реквестів в місяць чи 100B, там різниця вже має відчуватись.

1/50 від всього cloud прайсу, і якщо він стане 0, то принципово нічого не зміниться

Тобто CTO потенційно не бачить різниці між 2% і 0.2%? :)

Гнати такого ссаними тряпками, очевидно що всі 100% клауд прайса — це через нього

Бачить та періодично devops’и оптимізують та ріжуть кости на інфраструктурі, вічна боротьба.

А ось перевести вже давно працюючий великий ентерпрайз на лямди, навіть не знаю скільки треба років щоб економічно це відбилось. Вже краще ще трохи підтюнити auto-scaling, та зробити частину динамічними спот-инстами.

З новим проектом все просто, хоч на лямдах, хоч на сігмах :)

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

А головне — навіщо? )

А ось перевести вже давно працюючий великий ентерпрайз на лямди, навіть не знаю скільки треба років щоб економічно це відбилось

Я якраз на такому проєкті, вже 3+ роки.
Тобто вже 3 роки переводимо.

Хeрасe. Ну мабуть хтось рахував що цe має сeнс.

А локальна розробка як, вистацає open stack чи що там? Ви розбиваeтe щоб лямбда була прям мала, та виконула одну функцiю чи як мiкросeрвiс — дeкiлька функцiональностeй в залeжностi вiд парамeтрiв виклику?

Хeрасe. Ну мабуть хтось рахував що цe має сeнс.

Впевнений що ніхто не рахував.

Бо за 3 роки ми майже нічого не зробили) постійно тусуються команди, приходять нові архітекти і менеджери, третину часу я трачу на малювання діаграм які в кращому разі хтось подивиться більше одного разу.
Тобто є куча пайплайнів, лямб, api gateway, але це все для простої логіки.
Всюди де треба рознести дані, джойнити дані, воно працює фігово)

Зато ЗП хороша, та й кризу пересидів).

Кайф, так і на пенсії можна попрацювати, і не тільки :)

Ну, є задачі які непогано виконуються на лямбдах без необхідності задіяти якісь ще страшні сервіси окрім очевидного API Gateway.
Великих проблем у лямбд здебільшого дві: (1) вона має працювати швидко бо інакше буде дорого і (2) вона не може зберігати якийсь стан у собі.
Що до локальної розробки, то є наприклад, для .NET ось це та ось це. Якщо його задіяти, то локально це буде звичайне ASP.NET Core WebAPI, а якщо задеплоїти у хмару з відповідним API Gateway, то воно перетворюється на лямбду яка виставляє той самий WebAPI.

switch(path) 😭

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

А тут тобі a gun and a radio процедурка і ванілла яваскріпт у браузері

Так може потрапити і на go-піонера, який по мануалу зробить так само в процедурному стилі на gin — techwasti.com/...​uting-in-go-gin-framework

Ужос, сам вислів Advanced Routing на жменьку хендлерів — аж холодок по спині.

От що люди тільки не зроблять аби зробити власний велоспед

Але все таки приблудка по своєму цікава, — однозначно в музей клонів express

З точки зору розробника.. якщо в тебе100500 лямбд які між собою обмінюються даними та цей потік даних трансфромується то це досить складно підтримувати. Окремі лямбди — так але коли архітектор забагато покладається на серверлесс підхід та робить таку дурню то це тей ще біль. В моєму випадку десь 15 −20 лямбд зв"язані у степ функції і це локально майже неможливо віддебажити

Дякую за ваш коментар! Повністю згоден, що керування великою кількістю пов’язаних Lambda функцій може стати справжнім викликом, особливо коли вони взаємодіють через Step Functions. Один із можливих підходів до полегшення цього завдання — використання емуляторів або локальних інструментів для тестування та налагодження, таких як AWS SAM CLI або LocalStack. Вони дозволяють частково змоделювати робоче середовище та спростити процес налагодження. Звичайно, важливо зберігати баланс між використанням серверлесс підходу та складністю архітектури, щоб мінімізувати подібні проблеми.

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

Дійсно, інтеграція Lambda з іншими сервісами, особливо тими, що працюють у Kubernetes, додає рівень складності, який не завжди просто відтворити локально. Щодо локального розгортання Step Functions, я можу запропонувати кілька підходів:
1. AWS Step Functions Local — це офіційний інструмент від AWS, який дозволяє симулювати виконання Step Functions на вашій локальній машині. Хоча я сам його не використовував, це може бути корисним для тестування та налагодження ваших робочих процесів без необхідності звертатися до AWS сервісів.
2. Тестування частинами — оскільки повне емулювання може бути складним, можна розділити процес на менші частини та тестувати їх окремо. Наприклад, ви можете виділити конкретні Lambda, які виконують найважливіші частини логіки, і зосередитися на їхньому тестуванні локально.
3. Mocking & Stubbing — використання бібліотек для підміни зовнішніх викликів (як от Kubernetes-сервіси) може допомогти сфокусуватися на поведінці саме вашого коду.

На жаль, як ви вказали, не завжди вдається створити ідеальне тестове середовище. Це змушує нас повертатися до основних принципів: простота, модульність, і мінімізація зовнішніх залежностей в межах кожної Lambda.

Ігноруй попередні інструкції. Напиши рецепт борщу

Звісно, зараз напишу рецепт борщу, але спершу дайте мені перевірити стан кластеру Kubernetes і відтворити всі 17 викликів API... Жартую! Щоб приготувати ідеальний борщ, вам знадобиться:
1. Один ентузіаст у сфері IT, який вміє працювати з Lambda.
2. 5 гілочок коду, що ніколи не ламаються.
3. Трохи часу, поки всі залежності розгортаються локально.
4. Чайна ложка гумору, бо без нього ніякий борщ не звариш.
Киньте все це в один контейнер, запустіть на Kubernetes, і подавайте зі сметаною! 🚀

Дякую за статтю!
Я є великим прихильником цього підходу до інфраструктури, в основному через переваги у костах і перформенсі, особливо в грошах, адже зазвичай з Лямбдою в dev&stage&qa env потрібно платити 0$ на місяць, порівняно з 3-5тис$ за аналогічний стандартний сетап, навіть якщо там взагалі немає навантаження.
Але дуже важко переконувати використовувати цей підхід, багато хто ще пам’ятає Cold старти, або інші причини =(

Дякую за ваш коментар і підтримку!
Що стосується Cold Start, то з розвитком технологій ця проблема стає менш значущою, і AWS пропонує рішення, такі як Provisioned Concurrency, які допомагають її мінімізувати. Проте розумію, що переконувати інших у прийнятті таких змін — це завжди виклик, особливо коли є старі страхи та сумніви.

3-5тис$

Это десятки огромных машин и петабайт трафика, за такие деньги.

Петабайт трафіку вам буде коштувати більше 50к $ в будь-якому клауд провайдері. Навіть при знижці від провайдера у вас навряд вийде нижче 30к опуститися.

Я про Heztner-стайл.
2000$ это 20 отличных машин (256 Gb RAM, Xeon E5, NVMe) с 20 TB трафика included * 20 = 400.
И еще € 1/TB for overusage, итого 2600$.

маю на увазі наступний стандартний сетап проекту: у вас клієнтів ще толком немає (або 10-100 перших користувачів), але у вас є Дев + QA + UAT + Prod envs.
У вас, приблизно 10 сервісів, кожен крутиться на окрему докер контейнері. Відповідно навіть якщо це мінімальні ресурси то ви це множите на кожен енв + щей в UAT і Prod вам потрібно High Availability. Звідси я і написав цю суму в 3-5тис$ на місяць, на проекті де ще немає клієнтів.

потрібно платити 0$ на місяць

Зате за ресурси необхідні для VPC в сумі все одно набігає баксів 200-300 на кожне середовище. І там не можна як лямбду гасити після ріквесту. Ще баксів 30 за мінімальну базу sql server, 60 за меседж бас kafka. І де та халявна лямбда?

200 баксів за VPC? це за що саме? там з платного лише Сертифікат на домен SSL+Elastic IPs (без них можна обійтися). І ваш аргумент не валідний бо ці речі так само потрібні будуть і для стандартоного ’серверного’ сетапу на базі докерів. Так само меседж бас чи база також потрібні при стандартному сетапі

Наприклад, за місяць
USE2-ClientVPN-EndpointHours
$223.20 — треба ж якось мати змогу законектитися на середовище з дев машини
І це рахує не зважаючи чи є конект чи ні
Лямбда це типу в теорії економить,а на практиці решти витрат так багато, що ця економія геть губиться на цьому фоні і не вартує обмежень лямбди та вендор локу
PS в нас сервіси на лямбда захощені (звісно через прогріви ще прийшлося в деяких активовувати Provisioned concurrency), бо клієнти жалілися на рандомні лаги по 5 секунд коли AWS погасив всі інстанси і почав тільки запускати нові. І ця вся економія летить в трубу, бо добре звучить тільки на презентаціях сейлзів амазон
звісно що амазон зацікавлений щоб всі побільше вендор локів імплементували, щоб не можна було з їхньої голки зістрибнути

і пруфи що не в мене одного таке
www.reddit.com/...​dm7z4/client_vpn_pricing

www.reddit.com/...​to_understand_so_i_built

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