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

Lambda не єдина serverless технологія. Існують ще Microsoft Azure, IBM OpenWhisk, Google Cloud Platform та ін. Lambda зародилася трохи більше ніж два роки тому і є наймолодшою серед інших сервісів.

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

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

Власне Lambda являє собою Function as a Service (FaaS) – один з типів хмарних обчислень і є дещо більшим ніж IaaS, PaaS, віртуальні машини та Docker контейнери. AWS Lambda – це сервіс, куди ви завантажуєте код на Java, Node.js, Python або C# та створюєте Lambda-функцію, яка буде викликати цей код у відповідь на HTTP запити або тригери від інших сервісів Amazon та автоматично надаватиме необхідну частку обчислювальних ресурсів для виконання коду.

На відміну від Heroku, DigitalOcean, того ж AWS EC2 та багатьох інших подібних платформ, на AWS Lambda виконується лише функціональний код. Розробникам не потрібно білдити проект, заставляти його десь запускатися і налаштовувати для нього якийсь енвайронмент чи виконувати танок на майдані з бубном. Ці всі проблеми вирішує за нас AWS.

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

На основі Lambda-функцій можна будувати додатки за принципом event-driven development. Кожна Lambda-функція може викликатися декількома тригерами. Тригером для функції може бути подія в S3 (наприклад, успішно завантажений файл), подія в БД, повідомлення від SNS (Simple Notification Service), scheduled task та ін. Також тригером може бути кастомний ресурс, наприклад мобільний або web додаток, що використовує AWS SDK.

Для конфігурації HTTP endpoints для Lambda-функції використовується сервіс API Gateway. Конфігурація безпеки та доступу до різних ресурсів здійснюється за допомогою AWS Identity and Access Management (IAM). Для керування групами взаємопов’язаних сервісів та розподілення ресурсів між ними використовується сервіс CloudFormation.

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

Типова структура компонентів додатку на основі AWS:

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

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

Розробку додатку на основі Lambda-функцій можна вести декількома способами. Використання консолі управління AWS – це не шлях справжніх програмістів. Також існує потужний API на основі сервісу CloudFormation, з яким ще більш складно розібратися. Рятівним жилетом в даному випадку є Serverless Framework. Куди ж у наш час без фреймворків?

Serverless Framework є надбудовою не тільки над AWS Lambda, а й над іншими serverless сервісами, згаданими на початку статті.

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

З БД також не все так просто. В нашому випадку оптимальним рішенням було використання DynamoDB. Це також сервіс Amazon. Дана СУБД є NoSQL і коротко її можна охарактеризувати як дуже швидка і стабільна з автоматичним масштабуванням. DynamoDB обмежена в плані побудови складних запитів, але розрахована на роботу з big data.

Наше перше знайомство з AWS Lambda та Serverless Framework не було дуже болючим в силу нескладних задач, які потрібно було вирішувати. Але були деякі цікаві моменти, про які ми розповімо у іншій статті.

Які саме сервіси і технології ми використовуємо для розробки нашого проекту та які проблеми вони дозволяють нам вирішувати – також тема для окремої статті, KT session або навіть доповіді на Tech Talk. Тому не забувайте слідкувати за оновленнями.

Далі буде …