Бессерверная (serverless) разработка быстро развивается, считает аналитик компании Forrester Девин Дикерсон, который исследует тенденции и лучшие практики, связанные с этим подходом, сообщает портал The New Stack.
По словам Дикерсона, во многом рост serverless связан с побочным эффектом расширения применения DevOps — переносом некоторых операционных вопросов в разработку. «Разработчикам внезапно пришлось беспокоиться о гораздо большем количестве операционных проблем, чем раньше, — пояснил он. — Бессерверная технология выгодна разработчикам, потому что она снимает с них эти операционные проблемы». И это может объяснить ее популярность. В ходе опроса разработчиков, проведенного Forrester в 2022 г., 33% из 2452 респондентов заявили, что уже используют бессерверную архитектуру, а еще 30% сообщили, что хотят ее использовать.
Проектирование сервисов как эфемерных инстансов
Одним из самых важных аспектов бессерверной архитектуры является то, что приложения развертываются в функциях, которые запускаются только при вызове или срабатывании события.
По словам Дикерсона, при использовании традиционных приложений на базе микросервисов и даже монолитных приложений разработчик имеет полное представление о том, что происходит в производстве. Однако этого нельзя сказать о бессерверном приложении, где есть части, которые иногда просто не работают. «Когда вы разрабатываете бессерверное приложение, вы должны учитывать, что оно не будет работать постоянно, — сказал Дикерсон. — Как только оно перестает работать, оно исчезает».
Проектирование с учетом этого означает создание микросервисов как дискретных функций с единой ответственностью. Это также означает, что функции должны выполняться, а затем исчезать.
Согласно Forrester, когда разработчики бессерверных систем создают независимые рабочие нагрузки с коротким периодом выполнения, они получают преимущества автономного горизонтального масштабирования, которое может завершиться за малую долю времени и с меньшими затратами. Для обеспечения оптимальной производительности функциональные нагрузки должны быть небольшими и с минимальными зависимостями.
Бессерверная архитектура хорошо работает при наличии независимых рабочих нагрузок со спорадическим спросом, но это не лучший подход, если у вас есть серийные единицы работы, которые трудно обрабатывать параллельно, отмечает Forrester.
Сопряжение FaaS с микросервисами, управляемыми событиями
Хотя платформы функций как сервисов (FaaS) — такие как AWS Lambda, Azure Functions и Google Cloud Functions — являются ключевыми для бессерверной разработки, это лишь отправная точка, утверждает Forrester. В качестве лучшей практики разработчики также могут сопрягать функции с событийно-ориентированными микросервисами.
«Существуют бессерверные приложения, которые являются полностью бессерверными, и у вас может возникнуть ситуация, когда все может быть бессерверным, — сказал Дикерсон. — Но чаще вы сталкиваетесь с бессерверными функциями наряду с микросервисами и общим нативным облачным приложением».
Согласно Forrester, построение микросервисов как дискретных функций, которые потребляют и эмитируют события, может позволить разработчикам в полной мере воспользоваться преимуществами эфемерного масштабирования функционального программирования. Аналитики рекомендуют четыре шага по реализации событийно-ориентированных микросервисов как функций:
- Разработайте таксономию событий и доменов. Помочь реализовать микросервисы как функции может GitHub Actions.
- Используйте очереди событий для повышения производительности автомасштабирования. Разработчики могут сконфигурировать бессерверные платформы для мониторинга глубины очередей событий и реагировать соответствующим образом, когда производительность начинает снижаться — это можно сравнить с «тем чудесным моментом, когда вы стоите в длинной очереди, а три клерка вдруг открывают окна, чтобы обслужить клиентов».
- Дизайн должен позволять нескольким микросервисам реагировать на одно и то же событие.
- Предполагайте, что несколько версий сервиса могут реагировать на одно и то же событие. Разработчики могут использовать канареечные и синие/зеленые развертывания для оценки новых версий сервисов в производстве. Эту функциональность позволяют реализовать бессерверные фреймворки и инструменты, такие как Canary Plugin от Serverless Framework.
Проектирование функций с учетом автомасштабирования
При разработке функций с учетом автомасштабирования следует разбивать действия на небольшие независимые задачи, которые могут развертываться по отдельности. Разработчики также должны минимизировать время ожидания развертывания функций, поскольку время выполнения является самым большим фактором затрат в бессерверной среде.
Кроме того, согласно Forrester, традиционная большая реляционная СУБД не будет хорошо работать в бессерверной среде из-за сильной связности. Поэтому разработчики бессерверных решений отделяют состояние от бизнес-логики, используя более быстрые подходы NoSQL и рабочие процессы машин состояний, такие как step functions.
Хаос-инжиниринг для создания отказоустойчивых сервисов
Наконец, следует заранее планировать сбои, выявляя критические точки отказа, снижая риски интеграций и другие предсказуемые линии отказа, а также проверять стратегию отказа приложения с помощью хаос-инжиниринга и тестирования, советует Дикерсон.
Приложение, работающее с несколькими бессерверными функциями и получающее события в разное время, требует более тщательного подхода к тестированию, при котором разработчик пытается смоделировать вещи, которые могут пойти не так в производстве.
По словам Дикерсона, такой подход к хаос-тестированию с большим успехом использует Netflix. «Хаос-инженерия — это, по сути, когда вы пытаетесь сломать собственную систему с целью создания более устойчивых приложений, — сказал он. — Это не уникально для serverless, но это техника, которую следует использовать в serverless».