Платформенная инженерия (platform engineering) — это не только инструментальные цепочки или внутренние платформы разработчиков. По своей сути это дисциплина, призванная повысить производительность труда разработчиков, пишет на портале The New Stack Вишал Гаривала, старший директор и технический директор компании SUSE в Азиатско-Тихоокеанском регионе, Японии и Китае.

Практика DevOps в сочетании с нативно-облачной экосистемой обещает привнести скорость, последовательность и эффективность в процесс создания и развертывания ПО.

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

Как повысить производительность и улучшить опыт разработчиков? Как сделать так, чтобы разработчики тратили больше времени на написание кода? Возможно, ответ на этот вопрос может дать платформенная инженерия, которую Gartner определяет как «дисциплину создания и эксплуатации внутренних платформ разработчиков (IDP) с самообслуживанием для доставки и управления жизненным циклом ПО».

Растущий интерес к платформенной инженерии

Многие заказчики вступают в ряды сторонников платформенной инженерии и создают платформенные команды. Согласно отчету Puppet «2023 State of Platform Engineering», 51% компаний за последние три года создали такую команду. Эти команды, как правило, имеют следующий устав:

  1. Выявление общих требований со стороны других функций и разработка/использование централизованно управляемых решений для удовлетворения этих требований.
  2. Обеспечение управления и экспертной оценки централизованно управляемых решений.
  3. Предоставление разработчикам возможности использовать централизованно управляемые решения, обеспечивая автоматизацию и самообслуживание с использованием основных защитных механизмов. Для этого может использоваться интерфейс более высокого уровня, например портал для разработчиков.

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

Различные мотивы перехода на платформенную инженерию

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

Почему? Обе компании точно знали, чего они хотят добиться, и решали обратную задачу: Netflix стремилась унифицировать свой инженерный опыт, а Adidas — сократить время, необходимое разработчикам для запуска проекта и его интеграции в инфраструктуру.

Из общения с заказчиками из Азиатско-Тихоокеанского региона можно сделать вывод, что у тех, кто внедряет платформенную инженерию, как правило, есть свои причины. Например, для одного из заказчиков, чьи команды распределены по многим странам, одним из главных приоритетов является согласованность развертывания инфраструктуры, разработки приложений и мер безопасности во всех регионах. Решением для него стала внутренняя нативная облачная платформа, которую могут использовать распределенные команды. Другой заказчик, надеясь освободить разработчиков от выполнения сквозных функций, таких как управление инфраструктурой, создал единую платформенную команду, которая обеспечивает легкое «подключение» других систем и приложений.

Не упускайте из виду конечные результаты

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

  • Принять подход «думай по-крупному, начинай с малого, развивайся постепенно». Начните с минимально жизнеспособной платформы (MVP), которая позволит улучшить показатели разработчиков или решить проблемы, связанные, например, с производительностью их труда. Со временем вы можете добавить функциональность к этой MVP или создать еще одну MVP. Наличие единой платформы не является обязательным условием.
  • Не зацикливаться на инструментах. В литературе, посвященной платформенной инженерии, принято делать акцент на использовании «специализированных инструментов и платформ». Хотя это и важно, компаниям следует оценить свои цели и определить наиболее быстрый способ их достижения с помощью самых простых инструментов. Несмотря на утверждения некоторых поставщиков, не каждая компания сразу же нуждается во внутреннем портале разработчика или возможностях самообслуживания. Решение может быть простым — завести центральную вики-страницу, на которой будет собрана наиболее распространенная техническая информация, необходимая вашим разработчикам, на поиск которой они тратят много времени. Это может быть также стандартизация редактора Visual Studio Code с Rancher Desktop для обеспечения быстрой и удобной итерации Kubernetes на локальных машинах разработчиков.
  • Внедрить эффективное управление, лучшие практики и техническую экспертизу, чтобы направлять пользователей платформы. Это позволит не только повысить эффективность и согласованность, но и установить рамки для пользователей.

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

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