Определите, какая инфраструктура как код (IaC) лучше всего подходит для вас, основываясь на моем недавнем опыте работы с обоими.

Весь код в этой статье можно найти здесь вместе с правильной настройкой для развертывания приложения на AWS.

Если вы находитесь в той же ситуации, что и я, и пытаетесь выбрать правильную инфраструктуру IaC для нового проекта (или, может быть, думаете о переключении фреймворков в существующем проекте), то я надеюсь, что смогу помочь пролить свет на два популярных на текущем рынке. Я не буду подробно объяснять, что такое Serverless Framework или Pulumi или как они работают, так как об этом уже есть много ресурсов в Интернете. Вместо этого я проведу вас по пути, который я прошел с обоими инструментами, разработкой бессерверных приложений и поиском того, что лучше всего подходит для меня.

TLDR

Если вы разрабатываете бессерверные приложения, развернутые на AWS, уделяя особое внимание бессерверным функциям, которые в основном используют Typescript, то:

  • Используйте Serverless Framework с конфигурацией (serverless.ts), написанной на Typescript.
  • Используйте плагин serverless-bundle, чтобы упростить упаковку ваших функций.

Если вы в основном управляете облачной инфраструктурой и экосистемами и хотите сделать это проще (я говорю проще, потому что, хотя у Pulumi есть собственный API, вам все равно придется писать конфигурации для конкретного поставщика, которые нельзя будет передать другому облачному провайдеру) чтобы сменить облачного провайдера в будущем, то:

  • Используйте пулуми

В приключениях

Оба фреймворка поддерживают всех основных облачных провайдеров, хотя все мои проекты были развернуты на AWS. Я также в основном создавал бессерверные приложения с интенсивным использованием бессерверных функций, а не только управлял инфраструктурой. Это означает, что я писал много кода приложения, а затем использовал инфраструктуры IaC для развертывания этого кода в бессерверных функциях, которые затем взаимодействовали с другими облачными ресурсами. Большинство приложений использовали Typescript в качестве основного языка.

Я использую Serverless Framework уже несколько лет. Я пробовал все три варианта, т. е. писал конфигурацию с помощью Yaml, JavaScript или Typescript. Сначала я начал с версии Yaml по умолчанию, но быстро обнаружил, что это сильно ограничивает мою способность писать повторно используемый код. Невозможно написать общую функцию или блок кода и повторно использовать его в вашей конфигурации. Для таких вещей, как определение нескольких бессерверных функций или ролей IAM, которые часто очень похожи, было бы неудобно переписывать один и тот же код снова и снова или изменять 10 вхождений одного и того же при попытке изменить конфигурация. Переход на использование JavaScript и Typescript сделал это намного лучше. И это обязательно должен быть совет.

Если вы используете Serverless Framework или думаете об этом, используйте для конфигурации JavaScript или Typescript.

Вы пойдете от этого:

К этому:

Это поставит вас на гораздо лучший путь к успеху в поддержании вашего приложения в сопровождении.

Serverless Framework имеет довольно хорошую интеграцию с AWS CloudFormation. Если вы пытаетесь развернуть ресурсы, отличные от тех, которые управляются автоматически (AWS Lambda, роли выполнения IAM, шлюз AWS Api и т. д.), это можно сделать в разделе Ресурсы вашей конфигурации. В этом разделе вы в основном пишете шаблон CloudFormation. Я говорю в основном, так как вы, вероятно, захотите каким-то образом связать созданные там ресурсы с вашими функциями, хотя бы для того, чтобы предоставить вашим ролям IAM выполнения Lambda доступ к этим ресурсам. И здесь Serverless Framework начинает становиться все более сложным. По мере того как вы добавляете все больше и больше ресурсов CloudFormation, взаимозависимости между этими ресурсами и вашими бессерверными функциями быстро материализуются в спагетти-код. Трудно будет понять, что от чего зависит.

Когда я начал новый проект по созданию нового приложения, это привело меня к изучению альтернатив Serverless Framework. Здесь я открыл для себя Пулуми. Главное, что меня привлекло, это тот факт, что Pulumi спроектирован так, чтобы иметь возможность управлять всем облачным приложением, а не фокусироваться только на бессерверных функциях. Кроме того, он поддерживает Typescript и имеет приятную функцию, называемую магическими функциями, которая позволяет встраивать код ваших функций непосредственно в вашу конфигурацию IaC.

Это позволяет довольно легко написать функцию, которая запускается, скажем, при загрузке в корзину S3 или REST API. Это также проясняет зависимости (в отличие от того, что вам нужно делать с Serverless Framework).

Есть также несколько Crosswalks, которые по сути являются вспомогательными классами, которые упрощают некоторые распространенные варианты использования, такие как развертывание бессерверных функций в REST API (например, то, что показано выше). Многие ресурсы создаются классами пешеходных переходов, а не вами.

При всем этом казалось, что вы можете получить целостное представление о своем бессерверном приложении, написав код приложения вместе с кодом инфраструктуры. И именно поэтому я решил попробовать это.

Перенесемся на несколько недель вперед к моему новому проекту, и теперь я понимаю, что вышеизложенное было не чем иным, как несбыточной мечтой. Магические функции очень ограничены. На самом деле, они действительно хорошо работают только в том случае, если вы не используете внешние библиотеки. И, если быть до конца честным, такое случается очень редко. Вместе с тем Pulumi ничем не может помочь с упаковкой вашего приложения. Если вам нужно написать много бессерверных функций, каждая из которых имеет разные зависимости, вы в значительной степени предоставлены сами себе. Преобразование Typescript в JavaScript, встряхивание зависимостей кода, минимизация кода, TSC, Babel, Webpack, давай! Вам придется разобраться во всем этом, чтобы оптимизировать пакеты, которые вы загружаете на AWS, а также оставаться на вершине, поскольку экосистема (ааа… JavaScript) меняется каждый день.

Потратив несколько часов каждые пару дней на решение для создания бессерверных пакетов, я не мог не вспомнить, как легко было работать с Serverless Framework в сочетании с плагином serverless-bundle. Все было сделано за меня, и мне не нужно было ничего знать об инструментах выше.

Вдобавок ко всему, пешеходные переходы казались чем-то запоздалым. Они лишь частично задокументированы. Есть несколько примеров, но если ваш вариант использования выпадает из них, другой документации нет.

Сбой при правильной настройке Webpack сделал это за меня. Я потратил слишком много часов без ожидаемого результата и решил перевести весь свой IaC на Serverless Framework. Я никогда не оглядывался назад.

В конце концов, я пробовал Pulumi в течение нескольких полных недель и понял, что Serverless Framework гораздо лучше поддерживает бессерверные функции, по крайней мере, с AWS.

Pulumi кажется отличным фреймворком, если вы управляете большими облачными инфраструктурами, где у вас есть сотни ресурсов, а бессерверные функции не являются центром инфраструктуры, но если вы похожи на меня и в основном разрабатываете приложения, которые интенсивно используют бессерверные функции, я порекомендовал бы Serverless Framework.

После обратного переключения я также экспериментировал с новым способом структурирования своего приложения, чтобы исправить болевые точки, которые у меня были с Serverless Framework. Оставайтесь с нами для другой статьи (она уже опубликована, найдите ее здесь!), в которой подробно рассказывается о том, как я прояснил зависимости между ресурсами и, по сути, спроектировал то, что хотел от Pulumi, в Serverless Framework.

Не стесняйтесь расширять свой собственный опыт работы с любой из платформ в комментариях! Я всегда ищу разные точки зрения!