Михаил Чалый "Serverless Architectures using .NET and Azure"

Editor's Notes

• #4: Я сьогодні розповім про новий бузворд serverless причому як зазвичай буває в Інтернетах кожен трактує нові базворди як йому вигідніше. Приблизно так само і з бузвордом serverless. І я тут не виключення . Отже моя презентація фактично складається з двох частин, я спрочатку введу в курс справи хто тільки чув про serverless потім десь з середни розкажу з практичної точки зору на прикладах Azure І для того щоб було легше зрозуміти, спробую розповісти звідки це все пішло.
• #5: Почалось давно, нас цікавить час від он-премісів1. Он-преміси це коли всі ваші тачки стоять десь поруч. Іноді гоолвняк навіть просто щоб знайти потрібний комп’ютерв. В мене була історія коли ми просто загубили CI сервер. 2. Далі були клауди. Спочатку IaaS в якому були всі ті самі проблеми що і в on-premises , але хоча б компи не губились. Потім був PaaS. Тут вже прикольніше. 3. Куди розвиватись далі? Адже замахує кожен раз налаштовувати Web Site, default page, роути і всяке таке. Тим паче з розвитком SPA, коли аппа реально може хоститсь де завгодно, головне щоб був доступ до АПІ 4. Очевидно, що ми можемо піти далі. Провайдер може запропонувати хостити для вас просто кусок коду. І якраз це і є Serverless, і ось саме про цю штуку ми з вами сьогодні і поговоримо. 5. Звісно що це не межа. Я так пербачаю що через рік-два ми побачимо щось типу валью аз сервіс.
• #6: Проки я хотів помріяти про наступні кроки ровитку, я наткнувся на такий пакет. Це жарт.
• #7: Отже повертаємось з невпевненого майбутнього, в наш час до serverless. Як я вже казав це кусок коду. Функція.
• #8: Це дійсно функція. Може бути синхронною, може бути асинхронною, може бути на C#, а може бути на чомусь іншому. Може бути навіть просто exe файлик. Пізніше я покажу як воно реально проацює, і навіть якщо все буде добре то пару демок. Але головне розуміти, ми говоримо про ізольований кусок коду, який має вхід, щось робить і виходить. Якщо хтось вчився років 20 тому, то мабуть пам’ятає qbasic, там програмка могла складатись з декількох методів. Так і тут.
• #9: Якщо хтось вже чув, читав, колупав serverless, то могло стати питання чи саме це serverless. І так і ні. Залежить від трактовки.
• #10: Ви мабуть не чули прикол про два Львови? Схожа ситуація з і терміном serverless. Є два serverless. Спрочатку був BaaS . Це фактично концепція, коли замість того щоб писати свій бекенд, як ми завжди робимо стоврюючи АПІ, підключаючи ліби. Ми беремо існуючі бекенди (як наприклад парс.ком), робимо більшість бізнес логіки прямо на клієнті, ну а те те що критично робити на сервері, робимо якимось хуками. Ви почули слово хуки? Ось тут якраз і вийшов прикол. В BaaS все просто ідеально, поки не потрібно писати щось своє на сервері. Для цьго споачтку всі почали клепати свої костилі у вигляді можливості виклику наприклад джаваскрипта. А потім костиль перкували на фітчу. Так і з’явився FaaS. І так FaaS, це і є наш кусок коду аз а сервіс. Зараз більшість коли каже serverless мають на увазі FaaS, тож і ми так будеом робити.
• #11: Отже функції це зрозуміло. Але чом це важливо? Якщо не брати до уваги сценарієв з хуками? Фактично сервердесс має дікілька дуже важливих осбливостей.
• #12: Головне, це новий рівень абстракції. Фактично деплоймент юніт тепер функція. Маючи чітку асбстракцію, і беручи обмеження цієї абстракції стає легко вирішити багато питаннь Наприклад: Я функція – рантайм будь ласка прибери все що я тут насмітив Або я функція – рантайм викликай мене скільки і як і де хочеш, це взагалі твої проблеми мене викликати А рантайм може спокійно собі скейлити лінійно до безмежності. Або навпаки, упаковвати багато функцій на шарені ресурси. Або ще щосб робити що прийде в голову Скоту Гурт’є.
• #13: Друга штука це реактивність. Насправді вона випливає з першої. Якщо я функція, за яку райнтам вирішує коли і як мене викликати. Це приводить до того що фактично я як функція завжди працюю як результат якоїсь події. ШТТП реквест, нова месага в черзі, або якісь специфічні для клауд провайдера штуки, як то запис в Blob, або в DocumentDb. А може бути по годиннику. Фактично платформа serverless, це якраз рантайм який декларативно зв’язує різні події і функцію. І опціонально повертає результат.
• #14: Ще одна сокріше вже традиціяна особливість, ніж суто технічна. Це спосіб оплати виконання функції. Я думаю це і є те в чому заключається serverless, оплачується тільки час і ресурси роботи функції. Тобто на відміну наприклад від більшоісті PaaS де ви платите за весь час існування коду, як то WebApp в який не прийшо жодного запиту, в FaaS ви платите тільки за час роботи і використані ресурси. 18 хвилин.
• #15: Ок, це все добре, кльово що ми не платимо, всякі там необмежені скалабіліті, моніторінг. Але все одно «функції»? Реалі? Це ж як аплікація на stored procedures в sql server! Насправді так теж можна, AWS Aurora додала можливість викликати функції в треггерах, тож я думаю скоро щось таке буде і для Azure SQL . Але я краще приведу декілька реальніших юз кейсів.
• #16: Для іллюстрації, я розкажу мій реальний приклад, після якого я зацікавився темою серверлесс. Невеличка монолітна аплікація для дитячих садочків Мантесоррі. Реально невеличка. Без особливих навантажень, тому вона спокійно працює на мінімальних нодах. Одна з задач цієї апплікації, це обробка картинок. Також нічого воєнного, але існючого сервісу для того не знайшлось. І от якраз обробка картинок не влазить на мінімальну ноду. Десь за годину часу, функціонал перенісся в функцію, функція отримала потрібні їх ресурси, а основна аппа так і залишилась обробляти тисячі невеличких текстових запитів. Це до речі чудовий приклад для однієї з помилок адопатції serverless, коли цю архітектуру застосовують замість інших архітектур для всієї апплікації. Іноді це працює, особливо з BaaS, але в більшості випадків це оверкіл. Ось наприклад ви маєте якесь монолітний додаток, або мікросервіс. З точки зору серверлесс, це будуть тисячі функцій. Здоровий глузд підказує, що воно так не працює.
• #17: У LangUK проекта є ідея, створити набір мікросервісів для роботи з українськими текстами. Токенізація, Named Entity Extraction, тощо. Я взявся за частину NER, технічно це така собі біліотека, MITIE, яка розповсджується як С++ код, і має біндінги під Python 2.7. Представьте що вам потрібно мати NER в вашому додатку, а Azure Cogniteve Services вам не підходить. Хочте залежність на Python2.7? А на білд процес MITIE? Не хочете. Так от хлопці натренували її для української мови, це модель в 350МБ, яка має бути вся в пам’яті. Жах. Рішення мега очевидне. Виділяємо то все як функцію. Налаштовуємо HTTP Trigger, і вуаля, всі жахливі залежності ізольовані.
• #20: Наприклад обробка фотографій з першого прикладу, зроблена як підписка на блоб. Як тільки картинка з’являється в контенері, виконується функція, і результат збрегається в інший контейнер достпний для скачування апплікушкою. Робота по графіку це також реакція на подію. Просто події генерується за допомгою scheduler.
• #21: З рахунок обмежень функції, набирає популярність використання функції як GraphQL ендпоінтів, там якраз одна точка доступу. Для .NET світу, майже аналог це Odata, але я якщо чесно не дуже бачу в цьому сенс. Маюучи таку абстаракцію як інструмент, можна пробувати вирішувати дуже різні задачі. Можливо обробляти команди в CQRS, можливо денормалізовувати евенти в евент сорсінгу. В цілому доволі багато задач для яких ця архітектура має реальний сенс.
• #22: Поговорили про юзкейси, тепер припустимо що ми вирішили робити серверлесс відносно стандарту апплікацію. З чого почати? З декомпозиції. І тут є два піходи.
• #23: Мабуть перше що пробують робити починаючи копати серверлесс, це переносити сервіси та мікросервіси на функції. Виходить щось типу одна функція яка насправді виконує декілька функцій. Це і називають мікросервісом в серверлесс. Як на мене це скоріше антипаттерн, але коли не можна, але дуже хочеться, то можна. Гловне потрібно розуміти. Це функція, вона вам не допоможе з роутінгом, паралельним виконанням, тощо.
• #24: Другий варіант це на кожну операцію по функції. Це більше схоже на те як має бути. І це як буде пропонувати робити Azure Portal, GET, POST, DELETE – все окремі ізольовані функції. Головна проблема – неможливо керувати такою кількістю функцій. Так виглядає, що жоден з двох варіантів не ідеальний, і так і є.
• #25: Все з теор частиною закінчили, переходимо до більш прагматичної частини.
• #26: Я точно не знаю хто перший все це придумав. Думаю Amazon, але на поточний момент майже всі провайдери в підтримують так чи інакше serverless. AWS Lambda - мабуть найкрутіший він задає моду. Якщо AWS Lambda зробили підтримку в stored procedures, то можна очікувати що і інші провайдери скоро підтягнуться. AWS Lambda вміє тільки Linux , підтримує NodeJS і ще щось. Але через NodeJS запускаються будь що, тому комуніті нафігачила просто нереальну кількість фреймоврків і підтримок. Наприклад фремворк serverless якраз для AWS Lambda . Крім AWS Lambda, у Amazonа ще круто підтримується BaaS. Когніто для данних і аутентифікації. Всі інші сервіси також достпні. Події можеуть генерувати майже всі сервіси. Приклади, це класичні події з S3, SES. SNS, DynamoDb, Aurora, CloudWatch. IBM OpenWhisk в IBM BlueMix. Швидше за все також тільки Лінукс. Також NodeJS. Забув додати, NodeJS це як де факто стандарт. Цікава подробиця це підтримка Docker. Теортетично підтримує багато чого з CloudFoundry та OpenStack. Google Cloud Functions, це типу, а давайте і ми зробимо. Швидше за все тільки Лінукс. Працює як хуки для Firebase. Auth0 WebTasks – це цікавий феномен, це єдиний активний гравець на цьому ринку що не є клайд провайдером. Я точно не знаю де саме вони виконують свої перйлоади, але сам Auth0 для файловера знаходиться в Azure і в AWS. І нарешті Azure Functions. Windows, NodeJS, C#. Підтримка свого клауда добра. Менше ніж в AWS, але багато речей можна робити. Далі я зконцентруюсь на Azure Functions.
• #29: Всі плюшки з App Service
• #32: Моноліти писати легко, до якогось часу. Мікросервіси писати складніше з початку, більш менш норм і потім. Пару функцій написати дуже легко. 10 дуже легко. Далі я собі то не уявляю. На поточний момент єдиний спосіб групування, це аплікація. Якщо хстоь бачив як виглядає Management Studio з логікою в stored procedures, це туди. Функції можуть розгоратитись всі разом, а можуть поокремо. Всі разом втрачається частина гнучкості. Поокремо тяжко не провтикати і не зрозуміло якщо CI робити. Функції підтримують вресіонування, але проблема та сама що і з розгортанням. Незрозуміло що робити коли функцій багато.