Platform engineering

Мир только-только пришёл к пониманию того, для чего нужны инженеры, отвечающие за деплой, доступность и облака, к которым попутно прибегали и убегали мониторщики, безопасники, сетевики, любители чатов и искусственного интеллекта, как вдруг появляется новая сущность - инженер платформ. Что он делает, куда его применять и что делать со старыми инженерами?

Немного истории.

В дикие времена существовали разработчики (Dev) и админы (Ops). Первые писали код продукта, вторые эту поделку эксплуатировали. Часто между командами случались баталии на тему того, с чьей стороны проблема, у кого кривые руки и кому надо было буквально убиться об стену. Релизы зачастую передавались на физических носителях, иногда по сети, в редких случаях даже использовались пайплайны, но раскатка билдов отнимала столько времени и сил, что в какой-то момент пришлось сесть за стол переговоров и придумать как оптимизировать процесс. Так появился DevOps, разрушивший стену между Dev и Ops. Подход настолько ускорил разработку продуктов за счёт непрерывности циклов, позволяющих максимально быстро внедрять фичи и фиксить баги, что вопроса о целесообразности его внедрения ни у кого не вставало.

DevOps-инженеры стали отвечать за подготовку среды в которой запускается приложение - писать пайплайны, terraform-инфраструктуру, ansible-скрипты, docker-образы, k8s-деплойменты, подключать мониторинги, логирование, сканеры безопасности, хранение секретов и прочую автоматизацию для создания единообразной среды разработки и эксплуатации, позволяющей минимизировать ущерб в случае багов и доставлять фиксы и фичи в максимально короткий срок.

Выглядит круто. Но появляется новая проблема. Благодаря ускорению разработки, теперь можно увеличить количество проектов. В каждом проекте сидят свои DevOps-инженеры и пишут свои пайплайны, используя актуальный для проекта стек. Где-то это managed k8s, где-то aws, где-то gcp и так далее. И вот уже получается так, что управление всей этой инфраструктурой становится процессом чуть ли не более сложным, чем разработка продукта - скорость написания качественного deployment для k8s не будет поспевать за разработкой и та начнёт простаивать. К тому же DevOps-инженер должен обладать достаточно высокой квалификацией чтобы не тащить на дно процесс разработки, а это дорого. Проблема примерно та же, что была в начале - бизнес начинает недополучать прибыль на которую рассчитывал. А раз аппетиты растут, а чувство голода не проходит, надо снова сесть за стол переговоров и разобраться с процессами. Где может быть бутылочное горлышко? Правильно - в инструментах, требующих настройки. Потому что писать пайплайны может каждый, кто прошёл инфоцыганские курсы, а поднять кластер k8s, настроить сети и прочую инфраструктурную периферию - уже нужен опыт, которого зачастую может не хватать. А раз в каждой команде очередного проекта своя атмосфера, значит все вспомогательные команды (те же безопасники и мониторщики), тратят время на понимание того, что от них требуется в каждом проекте. То есть масштабирование проектов становится затыком из-за отсутствия внутренних стандартов. И вообще жизнь превратилась в ад, потому что если раньше подход "You build it, you run it" работал, то теперь мир изменился - приложение, состоящее из сотни-другой микросервисов, плюс пары десятков инфраструктурных сервисов, запускается в multi-cloud архитектуре, размазанное по aws, gcp и azure. Ни один здравомыслящий человек уже не разберётся что тут к чему. И в этом не должно быть необходимости - backend-разработчику платят за разработку api, frontend-разработчик пилит красивый интерфейс и никто из них не должен тратить своё время на подготовку инфрастркутуры, поднятие k8s-кластеров и тому подобного - это слишком расточительно. Этим занимается команда DevOps, но и у них случается проблема в стиле "вас много, а я одна" (растёт ответственность и нагрузка, к тому же возникает несогласованность процессов от проекта к проекту) , из-за чего страдает общее качество работы.

И вот тут на помощь приходит подход Platform engineering, отвечающий, по сути, за создание фреймворка разработки.

Суть подхода заключается в следующих принципах:

Стандартизация использования инструментов - берём инструменты для деплоя и запуска приложений и стандартизируем подход к их использованию на все команды. Если команды используют разные инструменты CI/CD, предлагаем им перейти на единую платформу. Если на проектах используется k8s, пишем стандарты его применения. То есть всё, что не отвечает за бизнес-логику приложения, должно быть стандартизировано и оптимизировано (VCS, CI/CD, Runtime, Provision, Observing, Securing, etc)
Разделение ответственности. Каждый инструмент имеет базовую ролевую модель Admin-User. Админы отвечают за настройку инструмента, его безопасность, плагины, бэкапы и т.п., пользователи - за свою работу с этим инструментом. То есть одни управляют, другие используют. Это позволяет разделить ответственность. Как я писал раньше - настроить кластер k8s и писать deployment для него - это скиллы разного уровня, но обычно в DevOps командах всё ложится на плечи простого инженера, квалификация которого страдает от проекта к проекту. Таким образом можно переопределить команды DevOps-инженеров, отправив часть на поддержку платформенных сервисов, а часть оставить на настройку пайплайнов. Таким образом экспертиза в целом будет повышена, т.к. каждая команда наконец-то займётся каким-то одним делом.

Что получается? Получается, что мы опять создали модель, с которой всё начиналось, только теперь в качестве Dev - инженеры, отвечающие за написание пайплайнов, а роль Ops выполняют люди, отвечающие за настройку инструментов. Будут ли у них в итоге те же проблемы? Наверняка ожидание доступов или добавление новых плагинов в сервисы станет бутылочным горлышком. Но (!) подход platform engineering здесь добавляет новый принцип:

Создание пользовательского интерфейса для взаимодействия с услугами. То есть инженеры платформы пилят сервис с UI или API для заказа тех самых provisioned, up-to-date, secured сервисов, за которые раньше у всех болела голова.

То есть команда разработки не ходит к инженерам платформы, для них сделан PaaS сервис, где они сами вольны выбрать всё что им нужно. Называется он Internal Developer Platform (IDP) Так что цель инженеров платформы - пилить стандартные решения, которые можно заказать через этот сервис. То есть теперь разработчик не идёт заказывать на aws кластер eks, а жмёт кнопку в интерфейсе IDP, который сам закажет кластер, настроит доступы, бэкапы, мониторинг и логирование. И это занимает минуты в отличие от стандартного подхода, когда подобные задачи выполнялись командами DevOps в течение дней.

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

Например, одной команде хватает gitlab-ci, другой привычнее работать с jenkins, третья хочет circleci, четвёртая - argo-ci. Зачастую возникает ситуация, когда компания говорит что "у нас стандартом является только одна CI, кому не нравится - нас не волнует". Задача platform engineering заключается в том, чтобы этот барьер пробивать и находить решения, способные всех удовлетворить. То есть инженеры платформы приходят к команде и говорят "Вы хотите использовать CircleCI? Ок, давайте мы вам настроим её с учётом всех best-practices, а потом интегрируем в нашу платформу чтобы и остальные могли использовать этот инструмент, если в нём возникнет потребность". То есть инженеры платформы вместо ограничений замотивированы на расширение возможностей своего продукта. В реальности, конечно, будет так, что какая-то команда использует маргинальные решения, внедрять которые в платформу не имеет смысла, тогда придётся обслуживать это решение по старинке.

Ещё один момент - инженеры платформы не должны ограничивать возможность конфигурирования сервисов в IDP под себя. Вместо этого они должны предусмотреть возможность гибкой настройки этих сервисов. То есть вместо прибивания всего гвоздями, инженеры должны использовать лучшие практики, такие как Infrastructure as Code (IaC) для создания шаблонов, в которые можно вносить изменения, при этом не нарушая общую безопасность и стабильность.

Внедрение platform engineering

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

Вообще IDP - это постоянно развивающийся продукт, у которого нет конечной достигаемой точки. Инженеры должны постоянно пилить фичи, фиксить баги, взаимодействовать с командами разработки, релизить новые версии платформы и т.п.

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

Platform vs DevOps

Одно не заменяет другое. Да, инженеры платформы забирают себе экспертизу по настройке инфраструктуры, готовят шаблоны для безопасной сборки приложений, развёртывания кластеров и прочего, но они не берут на себя задачи по деплою самого приложения, которое выполняет задачи бизнеса. То есть DevOps-инженеры по-прежнему пишут пайплайны по раскатке приложений и манифесты k8s, но теперь им не надо грузить голову вопросами раскатки инфраструктуры. Второй важный момент - разработка платформы использует внутри себя те же DevOps-процессы (добавление фич, фикс багов, тестирование, сбор требований, обратная связь и т.п.). То есть в конечном итоге никто не останется без работы, просто произойдёт перераспределение по интересам.

Лично моё мнение - исходя из таких реалий ближайшего будущего, всё равно стоит разбираться в обоих типах задач - настройке и использованию инструментов, поскольку проекты, как обычно, разные и требуют погружения в различные аспекты. Команды инженеров платформы будут формироваться как из облачных инженеров, так и из инженеров devops, где-то просто переименуют позиции, где-то платформенные инженеры вытеснят devops. Но, как показывает опыт, Dev и Ops - это две стороны одной монеты. Кто-то любит разрабатывать, кто-то любит поддерживать, но жить друг без друга у них не получается.