Перевод статьи подготовлен для студентов курса «DevOps практики и инструменты» в образовательном проекте OTUS.

Когда в 2015 году начали появляться первые туториалы с использованием AWS Lambda и API Gateway, было неудивительно, что они в основном были сосредоточены на копировании микросервисной архитектуры. Но тем, кто использовал AWS Lambda в больших масштабах, с течением времени становилось понятно, что существуют значительные ограничения для применения микросервисного подхода к AWS Lambda... По крайней мере, были ограничения в отношении того, что большинство людей подразумевали под правильным строительством микросервисов.

Давайте поговорим о "почему" для микросервисов

Микросервисы появились в первую очередь из-за разочарования монолитными приложениями. Монолит — это приложение, в котором вся логика находится в одной логической кодовой базе.

Были времена, когда из-за дороговизны серверов было обычным делом развертывание всего приложения на одном сервере. Развертывание монолита означало, что на сервере вы разворачивали часть или целиком все приложение.

Также развертывание монолита означало, что вы должны быть уверены, что ничего не сломаете. Очень часто небольшие изменения приводили к выходу из строя всего сервера и всего приложения.

Поэтому, когда появились облака с возможностью предоставлять экземпляры одним щелчком мыши в считанные минуты (а не дни или недели), стала ясной возможность разделения задач.
Разрушение монолита стало очевидной идеей, и родилась идея микросервисов.

Вместо создания монолита со всей логикой на одном сервере / экземпляре вы можете разместить части приложения на разных серверах и связать их между собой через какой-то легковесный протокол — обычно HTTP API.

Таким образом, архитектура приложений переместилась от монолитов к микросервисам.

Хотя, интересно, почему? Ценность такого подхода заключается в том, что при правках кода вы изменяете кодовую базу не всего приложения, а микросервиса — только составной части приложения. Это значит, что вы не можете сломать все приложение целиком.

Хотя это только теоретически, но эта теория лучше, чем монолит, хотя она и не идеальна.

Ключевым элементом для каждого сервиса является...

Интерфейс сервиса

Часто это некоторая форма HTTP-интерфейса (по крайней мере, это самый распространенный подход). Как правило это не проблема, кроме случаев, когда у вас большое количество сервисов и может появиться проблема их координации.

Движемся к бессерверной архитектуре

Поэтому первоначальный подход к построению бессерверных приложений (serverless) на AWS был “давайте создадим микросервисы”...

Это означало создать интерфейс API Gateway с функцией Lambda за ней и switch-инструкцией, которая выступает в роли маршрутизатора.

Каждый API Gateway становился интерфейсом сервиса, и это казалось логичным.

Вы можете сделать несколько сервисов, которые масштабируются отдельно друг от друга, что в некоторых случаях может быть очень важно.

За исключением того, что это не имеет смысла, когда вы понимаете, что функции AWS Lambda и FaaS в целом не должны рассматриваться как инстанс/сервер.

Потому что, хотя у них под капотом есть серверы (эй, серверы есть под большей частью вещей, которые работают в интернете, но никто не говорит “S3 все еще имеет серверы” или “BigTable все еще имеет серверы” или “Azure Active Directory все еще имеет серверы”...), есть мнение, что вы должны относиться к FaaS-функции так же, как к сервису… “minilith”, как некоторые называют это.

Проблема в том, что здесь не хватает того, что, по-моему мнению, является ключом к бессерверной архитектуре:

Бессерверная архитектура (serverless) — это все о событиях

Бессерверная архитектура, события и триггеры

Бессерверные системы по своей сути являются системами, управляемые событиями (event driven systems), и поэтому являются представителями cобытийно-ориентированной архитектуры (event driven architecture). Это меняет ваш подход к разработке, управлению и архитектуре.

В случае с микросервисами суть в том, чтобы реагировать на интерфейс — это основной механизм взаимодействия с логикой.

В бессерверном решении речь идет о реагировании на происходящие события, а API на самом деле является лишь механизмом генерации событий.

В рамках экосистемы AWS, которая является наиболее зрелой из бессерверных решений, API не рассматривается в качестве основного интерфейса. События гораздо важнее.

И именно поэтому существует около 50 событий, которые могут запустить функцию Lambda из других AWS-сервисов.

Совет в том, что если вы можете запустить функцию Lambda без прохождения через API Gateway, то это будет значительно быстрее и эффективнее, чем использование API Gateway, особенно если вы запускаете ее из другого интерфейса AWS.

Взгляните на Serverless Best Practices, вы увидите ряд моментов, которые отличаются от того, как многие проектируют микросервисы.

В первую очередь — однонаправленность функций. Большинство микросервисов, как правило, используют архитектуру “запрос-ответ” (request — respone), потому что так работает большинство веб-приложений. Функции в бессерверном приложении, как правило, бывают однонаправленные, а в качестве “circuit breaker” используются очереди, поэтому запрос-ответ становится менее распространенным.

Уровень данных (data layer) также управляется и понимается по-разному. Лучшая практика заключается в том, чтобы было несколько функций, а не одна прокси-функция с выражением switch.

Идея нескольких функций также дает дополнительные преимущества по сравнению с микросервисами. Если функция вызовет ошибку, то это повлияет только на эту функцию, но не на остальную часть приложения, потому что у функции нет состояния (по крайней мере, так должно быть!). И это очень веская причина не делать “minilith” !

Поэтому опыт построения микросервисов хотя и дает вам некоторые преимущества при проектировании бессерверных решений, но в действительности можно упустить большую часть того, что делает бессерверные приложения ценными.

Микросервисы, как правило, отличаются от хорошо спроектированного бессерверного приложения в нескольких отношениях. Это означает, что, хотя можно создать микросервисы с бессерверным бэкендом, но на самом деле нет прямого пути от микросервисов к бессерверной архитектуре.

Путь от микросервисов к бессерверной архитектуре

Итак, каков путь от микросервисов к бессерверным решениям? Есть ли быстрый способ изучить основы, чтобы упростить переход от одного к другому, поскольку микросервисы широко распространены?

Я думаю, это то, над чем ломает голову бессерверный мир. Недавно в твиттере было большое обсуждение, в котором мы говорили на эту тему. Здесь стоит сослаться на него, хотя бы для того, чтобы увидеть, о чем говорит сообщество (посмотрите различные ответы, и вы увидите многочисленные мнения по этой теме, хотя никто прямо и не упоминает микросервисы).

Там говорят о некоторых инструментах, которые, как вам скажут, облегчают создание бессерверных приложений, но в конечном итоге они станут той платформой, на которой вам придется все строить. Я не думаю, что это принесет пользу или поможет кому-то лучше понять архитектурный стиль.

Мы, как сообщество, понимаем, что за бессерверной архитектурой будущее. Но переход от старых архитектурных стилей не всегда будет простым, даже когда бессерверная архитектура — это правильный (а иногда и не правильный) выбор.

Для этого есть причина. Не так просто изменить мышление человека. Легко построить функцию Lambda. Но создать хорошо спроектированное беcсерверное приложение непросто. Потому что это требует изменения мышления, а это относительно сложно.

И как я уже говорил несколько раз, мы должны перестать учить людей “hello world”-приложениям и останавливаться на этом из-за того, что многие думают, что этого им будет достаточно.

Причина, по которой я написал Serverless Best Practices заключалась в том, чтобы помочь людям понять, что они не должны делать предположения о том, как строить бессерверные приложения на основе текущих знаний.

Инструменты, которые мы сейчас используем для создания бессерверных решений — это те же инструменты, которые мы используем для создания “cloud 1.0”-приложений, но они не полностью подходят для этих целей. Эти инструменты несовершенны, но мы пытаемся объяснить и сделать их как можно лучше.

Что нам нужно от вас

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

Так что нам, как сообществу, нужны ваши вопросы:
— С чем у вас трудности?
— Где есть пробелы?
— Каких туториалов не хватает?

И что-то в этом роде.

Я готов помочь компаниям осуществить этот переход. Я работал с высшим руководством, CTO и CEO, чтобы помочь определить, какая ценность создается в компании с использованием бессерверного подхода, и я рад помочь другим компаниям.

Я очень рад помочь. Свяжитесь в LinkedIn здесь.