Всем знакома история, когда менеджер спрашивает: сколько времени нужно, чтобы реализовать ту или иную фичу? Менеджеры или заказчики смотрят на это просто: разработка пишет код, эксплуатация деплоит его и следит, чтобы всё надёжно и хорошо работало. Но в жизни всё оказывается гораздо сложнее, при этом разработка и эксплуатация не стоят на месте и развиваются в инструментарии и подходах.
Меня зовут Виктор Кузённый, и за 15 лет в IT я работал Java‑разработчиком на гособоронзаказ, делал высоконагруженные бэкенды в Кинопоиске, а затем подружился с Serverless в Yandex Cloud, и этот опыт позволил мне познакомиться с разными инструментами разработки, языками программирования, а также инструментами деплоя и управления инфраструктурой.
Методы и подходы к управлению инфраструктурой постоянно развиваются. Эпоху ручной конфигурации и bash‑скриптов сменил подход Infrastructure as Code (IaC), далее императивный подход стал вытесняться декларативным (Terraform), затем появились библиотеки описания инфраструктуры на языках программирования общего пользования (AWS CDK, Pulumi, TFCDK). Но сложность и объём инфраструктуры растёт быстрее, чем мы успеваем придумать новые инструменты для эффективного управления ею.
Бессерверные вычисления всё более активно применяются в различных задачах IT. Serverless представлен уже не только в крупных гиперскейлерах, но и в небольших специализированных облачных провайдерах. Помимо облачных решений есть и опенсорс‑платформы. Пока он скорее популярен среди небольших и средних проектов и команд.
Особенность serverless‑подхода в том, что управление инфраструктурой в классическом понимании берёт на себя облачный провайдер или техплатформа. Но возникает новый слой верхнеуровневых ресурсов (функции, триггеры, топики, очереди, бакеты, API, джобы и т. д.), которых в разы больше, чем в IaaS и PaaS, и которыми управляют чаще всего разработчики, а не инженеры эксплуатации или DevOps. Применение IaC помогает справляться с этой проблемой, но с ростом проекта количество инфраструктурного кода становится сравнимым с прикладным, и его написание и поддержка не даёт разработчикам максимально сосредоточиться на реализации бизнес‑логики приложения. Более того, прикладной и инфраструктурный код достаточно сложно постоянно поддерживать в консистентном состоянии.
Относительно новая концепция Infrastructure from Code (IfC) использует другой подход, создавая необходимую инфраструктуру непосредственно из кода приложения. Вместо написания отдельных файлов конфигурации инструменты IfC интегрируются с кодом или анализируют его, чтобы автоматически определять и предоставлять необходимую инфраструктуру.
В статье разберёмся детальнее, что такое IfC, в чём его преимущества и недостатки, а также чем он отличается от IaС и как его дополняет.
Развитие DevOps с точки зрения Dev и Ops
Если мы захотим визуализировать современные практики DevOps, то скорее всего увидим что‑то такое:
Но так было не всегда, особенно если начать обзор с эволюционного развития инструментов разработки и языков программирования.
Когда‑то у нас было поколение языков, где помимо программирования бизнес‑логики нужно было управлять памятью и потоками. Вслед за этим пришло поколение языков, где появилась автоматическая сборка мусора, а управление памятью ушло в рантайм. Потом пришло более современное поколение языков, появились легковесные потоки и корутины, и управление потоками тоже перешло в рантайм. Теперь мы подошли к моменту, когда разработчики действительно пишут только бизнес‑логику.
В свою очередь, команде эксплуатации, или Operations, чтобы поднять инфраструктуру для нового кода нужно было подготовить железный сервер или виртуальную машину, установить операционную систему, пакеты, код приложения, объединить узлы в кластер, поставить балансировщик нагрузки — всё это делалось руками. Потом появились специальные скрипты. Потом пришло поколение инфраструктуры как код (IaC), появились разные фреймворки, языки, где можно было всё описывать, но масштабированием нужно было заниматься вручную. Затем появилось направление бессерверных вычислений.
Со временем платформа уже забирала на себя всё большую часть управления инфраструктурой, в том числе мониторинг, трейсинг, логирование. Если объединить два таймлайна рядом, то мы увидим, что между Dev и Ops всё ещё остаётся небольшой разрыв, требующий ручной работы.
Это тот самый переход, когда разработчик написал код, и должна случиться какая‑то магия, чтобы этот код сам развернулся. Примерно пять лет назад для этого появился такой термин, как Self Provisioning Runtime, где рантаймы позволяли сделать этот шаг автоматически. Это и есть первые зачатки IfC — инфраструктуры из кода.
А что насчёт Serverless
Если вести отчёт с запуска AWS Lambda, то Serverless‑подход появился 10 лет назад. Он возник как концепция: разработчик пишет код, реализует какой‑то интерфейс, деплоит его в виде функции, а платформа берёт этот кусочек кода, собирает его, разворачивает в отказоустойчивом и автомасштабируемом окружении и затем предоставляет HTTP для вызова этого кода. Всё происходит автоматически.
За эти 10 лет не только функция стала доступна как сервис: появились бессерверные базы данных, бессерверные очереди, уже привычно нам бинарное хранилище, где бакет тоже предоставляется как сервис.
Облачная архитектура получила новый слой в виде Serverless наряду с традиционными IaaS, PaaS и SaaS. Serverless берёт на себя уже практически все аспекты инфраструктуры, в том числе приложения и данные.
Если сравнить конструкции, которыми мы оперируем на разных слоях облачной архитектуры, то в Serverless на API‑уровне мы оперируем API Gateway. Если речь про бизнес‑логику, то в IaaS — это виртуальные машины, либо kubernetes‑кластер, а в Serverless — это функция или контейнеры как сервис.
Слой | IaaS | PaaS | Serverless |
|---|---|---|---|
API | Network Load Balancer | Application Load Balancer | API Gateway |
Business Logic | Virtual Machine (VM) | K8S | Function |
Data | Network Blob Storage (NBS) | Database | Table |
Messaging | Network (VPC) | Message Broker (Kafka) | Queue |
Новый уровень управления инфраструктуры приводит к тому, что разработчики не хотят писать по‑старому, если уже познакомились с преимуществами Serverless. При этом команда эксплуатации пока ещё не может или не хочет оперировать теми терминами, которые предлагает новый слой, в том числе потому, что нужно больше знать про бизнес‑логику приложения. На плечи разработчиков ложится задача по описанию инфраструктуры в объектах уровня Serverless.
Разработчики любят писать код на привычных им языках программирования, а не конфиги на yaml или json. И было бы здорово предоставить им такой инструмент, чтобы описание инфраструктуры автоматически генерировалось из кода приложения для дальнейшего автоматического развёртывания. Давайте посмотрим, что нам предлагают современные IaC‑инструменты, чтобы решить эту проблему.
Развитие IaC: прошлое, настоящее и будущее
Начнём с такого подхода, как императивный IaC. До сих пор пользуются популярностью Ansible и Chef, где вы просто описываете последовательность шагов, чтобы развернуть инфраструктуру.
Помимо этого бывают декларативные предметно‑ориентированные языки, где вы описываете целевое состояние, и фреймворк сам понимает, какие ресурсы надо удалить, изменить или добавить.
С точки зрения Serverless получается такая ситуация: чтобы небольшой кусочек кода развернуть в боевом окружении, надо написать четыре листинга конфигов Terraform. Любой DevOps‑практик скажет, что надо создать модуль на Terraform, но разработчики не очень любят писать на Terraform.
Затем появились специфические языки именно для Serverless, которые уменьшили объём инфраструктурного кода. Вслед за этим появились специальные библиотеки на общепринятых языках, которые позволили описывать это разработчикам — Cloud Development Kit. Но подход стал больше похож на паттерн‑билдер, где код приложения по‑прежнему живёт отдельно от кода инфраструктуры.
Последующее появление Serverless CDK помогло снизить объём, но не решило проблему концептуально.
Возникла и новая проблема. Если мы хотим жить в мультивендорном мире или планируем переезжать в другие облака, то сталкиваемся с тем, что Serverless‑код приложения специфичен для конкретного вендора, это же касается и описания инфраструктуры. А хотелось бы, чтобы код ничего не знал про вендора, а описание инфраструктуры настраивалось под конкретного облачного провайдера.
Если резюмировать все описанные проблемы, хочется сформулировать принципы, которые применимы к развитию текущих подходов.
LowOps. Хочется автоматизировать создание инфраструктуры, опираясь только на код приложения.
Developer‑friendly. Хочется, чтобы разработчики писали код привычным образом, на привычных языках и оперировали теми абстракциями, к которым они привыкли: API, бакетами, таблицами, очередями и так далее.
Vendor‑free. И хочется, чтобы была возможность описывать инфраструктуру в независящем от платформы (облака, вендора) виде.
Обзор подходов, технологий и инструментов Infrastructure from Code
Мы немного разобрались, что такое инфраструктура из кода. Теперь давайте посмотрим, как на рынке реализуется этот подход и учитываются эти принципы. В первую очередь, посмотрим с точки зрения developer experience.
Здесь на одной чаше весов — удобство и простота, а на другой — гибкость, экосистемность, сохранение компетенций. Максимально простое и удобное решение — это отдельный язык.
Свой язык программирования. Дизайнеры придумают язык, которым удобно описывать инфраструктуру, он будет встраиваться в обычные конструкции, которые используют разработчики, когда пишут бизнес‑логику. Потом они подумают о том, чтобы сэкономить трудозатраты на разработку. Это максимально унифицированный подход, который также обещает повышенную производительность.
Но, как с любым новым языком, это глобальная история. Во‑первых, вы теряете скилы, потому что нужно изучать новый язык, а переход на новый язык дорого стоит. И на старте любой язык имеет ограниченную экосистему, комьюнити и поддержку в инструментах разработки.
Пример — язык Wing. Он существует несколько лет. Это относительно популярный опенсорс‑язык, который поддерживает основные таргетные платформы: AWS, Azure, GCP.
Следующий подход менее удобный, но более гибкий.
Аннотирование кода. Код размечается аннотациями, принятыми в языке. На этапе статического анализа кода, фреймворк по аннотациям понимает, какой тип ресурса надо создать, и либо сразу создаёт этот ресурс, либо генерирует его описание на IaC‑языке.
Особенности в том, что в каждом языке — свой способ аннотирования кода. Поэтому под каждый язык будет своя аннотация. При этом не все фреймворки поддерживают все языки. Также тут ограниченная поддержка IDE. Вы зависите от дорожной карты языка и инструментов статического анализа в этом языке.
Пример — фреймворк Klotho. У него достаточно широкий набор поддержанных языков, но целевая платформа только одна — это AWS.
SDK. Самый гибкий, самый простой в реализации способ. Вы подключаете к проекту библиотеку с SDK, как вы привыкли, делаете её вызовы, по которым система понимает, какие вы используете ресурсы, с какими параметрами. Этот подход хорошо расширяемый, позволяет учесть специфику вашей инфраструктуры, специфику вашего деплоя.
Но под каждый язык нужен свой SDK. И могут быть ограничения, потому что вы подключаете зависимость, и могут появиться определённые ограничения на структуру проекта, на артефакт сборки.
Пример — фреймворк Nitric. У него достаточно богатый набор поддержанных языков и основных целевых платформ.
Теперь давайте посмотрим, какие есть решения, с точки зрения deployment experience.
Тут также на одной чаше весов — удобство и простота, на другой — гибкость и независимость.
Специализированные облака. Это решение под ключ, когда облако берёт на себя всю работу по автоматизации деплоя, управление инфраструктурой, в том числе и управление ею в рантайме. Здесь минимальные затраты на эксплуатацию. Ограничения: минимальный уровень контроля, поскольку есть вендор‑лок и ограничения на уровне той функциональности, которую предоставляет облако, а также ограниченная гибкость и расширяемость.
Пример — система ampt. Это проприетарное облако, которое имеет достаточно узкую поддержку языков. Такие решения часто затачиваются под конкретный язык, под конкретную базовую целевую платформу, на основе которой они построены.
В данном случае ampt построен поверх AWS. Кроме самостоятельного деплоя и провиженинга, эти системы умеют оптимизироваться в процессе рантайма: они смотрят на профиль нагрузки, на то, как ведёт себя инфраструктура, и могут оптимизировать использование CPU, памяти, других ресурсов.
Следующий класс решений — это платформы, которые интегрируются с крупными гиперскейлерами.
Интегрированные платформы. Такие решения уже не управляют инфраструктурой в процессе рантайма, они только помогают сгенерировать описание и развернуть инфраструктуру в целевой платформе. Зачастую они проинтегрированы с крупными облачными провайдерами, предоставляют больше возможностей по расширению и управлению инфраструктурой.
Особенности: увеличиваются расходы на эксплуатацию. То есть нужно больше знаний о том, как устроена инфраструктура, и нужно иметь людей, компетенцию или команду эксплуатации. При этом, по‑прежнему есть вендор‑лок на эту платформу.
Пример — система Encore. Она поддерживает языки TypeScript, Go, а также платформы — AWS, GCP.
Независимый фреймворк. Максимально гибкое решение — это фреймворк, который умеет генерировать IaC‑описание. Автоматически собираемые из кода приложения контейнеры мы можем деплоить привычными IaC‑средствами в целевую платформу, которую сами используем. Это наиболее расширяемый и гибкий подход. Он интегрируется в уже существующие в компании или проекте CI/CD‑процессы в используемую инфраструктуру.
Особенности в том, что здесь минимум удобства и простоты: нужно гораздо больше знать про современный IaC и целевую платформу или облачного провайдера.
Пример — система Nitric, которая уже упоминалась выше. У неё достаточно широкий набор поддерживаемых языков и платформ. В её архитектуре есть деплоймент‑слой или ControlPlane и рантайм‑слой или DataPlane. При сборке и развёртывании приложения вызовы методов SDK превращаются в вызовы специального API‑сервера, в котором есть провайдер‑плагин для целевого облачного провайдера. Этот плагин знает, какой ресурс нужен в облаке и как с ним работать для данного метода в SDK. Есть возможность написать свой специфичный провайдер‑плагин и расширить существующие провайдеры‑плагины, если не хватает поддержки каких‑либо облачных ресурсов. Также есть рантайм‑сервер, который живёт рядом с самим приложением умеет обрабатывать обращения к ресурсам и делает это специфичным для целевой платформы способом, тем самым абстрагируя код приложения от конкретного облачного провайдера. Это всё расширяется: можно написать адаптер под свою инфраструктуру, под своё целевое облако.
Итого, что даёт Infrastructure from Code
Если хотите сэкономить на эксплуатации и описании инфраструктуры для вашего приложения, советую посмотреть на этот подход — инфраструктура из кода. Он позволяет найти нужный баланс между удобством и простотой, а также гибкостью, расширяемостью и независимостью. Выбирайте решение, в зависимости от вашего проекта.
Также буду рад видеть вас в нашем комьюнити — изучайте инфраструктуру из кода и задавайте вопросы.
Источники:
Мой доклад на эту тему и демо на DevOops 2024
Self-Provisioning Runtimes Streamline DevOps
Мой доклад о пути от FaaS к платформе для EDA‑приложений на Scale 2024