Платформенная инженерия (platform engineering) растет, но куда она движется? Ответ можно найти в первом отчете Humanitec «State of Platform Engineering Report», сообщает портал The New Stack.

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

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

Платформенная инженерия в тренде

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

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

В то же время это не совсем новое явление: первые проблески идеи были зафиксированы в Thoughtworks Tech Radar в 2017 г., а сама концепция получила толчок к развитию благодаря публикации в 2019 г. книги «Топологии команд» Мануэля Паиса и Мэтью Скелтона.

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

Нынешнее исследование показывает, что компании, инженеры и идейные вдохновители твердо стоят на своем. Более того, платформенная инженерия выходит из фазы шумихи: существует множество доказательств ее ценности на практике.

Платформенная инженерия работает

Растущее внедрение платформенной инженерии — это не просто полет фантазии. От поддержки проектов Nike и Starbucks, которые в противном случае были бы невозможны, до основы легендарного роста инфраструктуры GitHub, IDP стоят за некоторыми действительно вдохновляющими историями о том, как процветать в масштабе.

Платформенные инженеры со всего мира предоставили исследователям множество замечательных примеров. Вот несколько примеров того, чего может добиться «умная» платформенная инженерия.

Снижение когнитивной нагрузки

Одна из самых болезненных точек неудачного внедрения DevOps связана с неизбежным умственным бременем, которое накладывает эта методология: от разработчиков ожидают, что они освоят все — от Kubernetes и Infrastructure as Code до самостоятельного запуска сервисов.

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

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

Продвижение самообслуживания для искоренения теневых операций

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

Эти размытые границы означают, что современные разработчики должны быть готовы делать все: от работы с тикетами поддержки до необходимости есть, дышать и спать в Kubernetes, чтобы решать ежедневные задачи. В результате они становятся «теневыми» членами операционной команды. Хорошо известен главный симптом этой нездоровой ситуации: опытных бэкенд-разработчиков постоянно просят выполнять инфраструктурную работу за своих менее опытных коллег — и у них остается мало времени для написания кода в соответствии со всеми своими основными обязанностями!

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

Избежание повторного изобретения колеса

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

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

Эксперты по платформенной инженерии пропагандируют продуктовое мышление

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

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

Платформенная инженерия расширяет возможности карьерного роста

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

Хотя некоторые организации считают платформенные команды не более чем «клеем», скрепляющим все остальное, такой упрощенный взгляд упускает из виду один жизненно важный факт: такой клей имеет ощутимую ценность для бизнеса. Он разблокирует разработчиков, сокращает сроки доставки ПО и улучшает опыт разработчиков.

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

Ничто так не убеждает в этом, как вознаграждение, которое получают платформенные инженеры. Humanitec опросила 134 инженера в Северной Америке и Европе и выявила значительный разрыв в зарплате между теми, кто работает над IDP, и их коллегами, использующими только DevOps, — от 9,4 до 19,4% в зависимости от места работы. Другими словами, организации вкладывают свои деньги туда, где выше ценность, а именно в создание высококвалифицированных команд платформенных инженеров.

Платформенная инженерия — в ваших руках

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

Роли платформенных инженеров в настоящее время находятся в похожем состоянии: исследование показало, что почти половина респондентов работает над платформами. Несмотря на это, чуть менее 23% респондентов занимают должности платформенных инженеров — большинство из них оказались SRE, архитекторами ПО или инженерами других видов.

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

Перспективы

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

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