Становление платформенного инженера: как справиться с растущей сложностью программного обеспечения
Проектирование платформ не заменяет DevOps — скорее, оно дополняет DevOps для решения проблем в масштабе предприятия и обеспечивает платформу для поддержания согласованности.
DevOps
DevSecOps
Платформенная инженерия
Является ли разработка платформ просто еще одним термином, обозначающим специализацию DevOps, или это что-то другое? Истина, по мнению разработчиков компанииDST Global, вероятно, где-то посередине. DevOps и связанные с ним разновидности DevXOps имеют сильную культурную специфику, которая ставит в центр отдельные команды. К сожалению, во многих местах DevOps привел к новым проблемам, таким как распространение инструментов и отсутствие гармонизации на предприятии. Можно сказать, что в ответ на очень строгую разрозненность и сильную централизацию прошлого DevOps слишком сильно сдвинул маятник в сторону федерации — и, следовательно, к субоптимизации на уровне команды — в ущерб организации. Больше всего это ощущают более крупные и сложные предприятия, которым приходится иметь дело с различными стеками технологий и разными уровнями зрелости внутри организации.
Разработка платформ возникла как ответ на эту проблему в масштабах всего предприятия. Проектирование платформ не является заменой DevOps. Вместо этого разработка платформы дополняет DevOps для решения проблем в масштабе предприятия и предоставляет платформу инструментов, которая позволяет отдельным командам поступать правильно, а не ломать что-то, пытаясь поддерживать согласованность во всей организации.
За последние несколько лет доставка ИТ усложнилась, поскольку все больше приложений развиваются более быстрыми темпами. Это означает, что организации не могут полагаться на отдельных людей для контроля сложности; они требуют системных ответов, подкрепленных соответствующими инструментами. Это постановка проблемы, которую стремится решить разработка платформ. Благодаря этому инженеры платформ стали иметь решающее значение для организаций, поскольку их роль играет ключевую роль в обеспечении безопасности и технических стандартов.
Что такое инженер платформы?
Роль инженера платформы состоит из трех разных частей.
Наиболее очевидной из них является роль технического архитектора , поскольку ему необходимо создать инженерную платформу, которая соединяет все инструменты и обеспечивает процессы. Второй аспект — это поддержка сообщества , которая аналогична роли по связям с разработчиками в компаниях, занимающихся техническими инструментами. Третья часть — менеджер по продукту ; конкурирующие интересы и требования сообщества разработчиков должны быть приоритетными по сравнению с техническими потребностями платформы (рассмотрим такие вещи, как усиление безопасности и исправление устаревших компонентов).
Инженер платформы в роли технического архитектора
В организациях со средней или высокой сложностью технологического стека количество инструментов, необходимых для создания, выпуска и обслуживания программного обеспечения, составляет как минимум дюжину, а иногда и больше. Интегрировать эти инструменты и обеспечить измерение значимых показателей примерно так же сложно, как и интеграцию бизнес-приложений. В конце концов, проблемы очень похожи: различные процессы необходимо согласовать, модели данных необходимо преобразовать, чтобы сделать их пригодными для использования, а точки интеграции необходимо соединить, чтобы обеспечить сквозной процесс.
Системы, управляющие программным обеспечением бизнеса, стали такими же сложными. Роль инженера платформы здесь заключается в том, чтобы следить за архитектурой инструментов, которые управляют программной частью. Цель состоит в том, чтобы инструменты «исчезли», а сборка и выпуск программного обеспечения казались простыми.
Инженер платформы как активист сообщества
Инженеры-программисты склонны думать, что их решения лучше, чем у кого-то другого. Таким образом, внедрение инженерных платформ является непростой задачей. Предложения инженерам использовать конкретный инструмент часто встречают сопротивление. Инженер платформы должен быть активным участником сообщества, который работает с инженерами, чтобы продвигать платформу и убеждать их в преимуществах. В этой части роли общение идет в обе стороны, поскольку инженер платформы также должен выслушивать проблемы и задачи платформы и определять новые функции, которые пользуются большим спросом. Это приводит к третьей части роли.
Инженер платформы в качестве менеджера по продукту
Конкурирующие требования к платформе исходят от инженеров организации и других заинтересованных сторон, таких как безопасность, и, конечно же, инженеров платформы. Осмысленная приоритезация этих требований является сложной задачей, поскольку вам нужно найти баланс между всеми конкурирующими интересами, особенно потому, что финансирование платформы часто само по себе является проблемой, поэтому скорость окупаемости имеет решающее значение для постоянной поддержки платформы.. Инженеру платформы требуются хорошие навыки ведения переговоров, чтобы справиться с этими проблемами.
Обзор инженерной архитектуры платформы
Мы говорили о роли инженера платформы, но что находится в этой платформе, которую он строит и обслуживает? Проще всего подумать о трех слоях и одной целевой среде:
- Верхний уровень — это опыт разработчика. Это инструменты, с которыми разработчик напрямую взаимодействует — инструменты, которые управляют общим рабочим процессом, такие как инструмент управления жизненным циклом Agile, инструмент управления сервисами и IDE для разработчика, вписываются в это.
- Нижний уровень включает компоненты инфраструктуры , которые необходимо объединить для создания сред приложений. Это может быть общедоступное или частное облако и включает традиционные технологии центров обработки данных.
- Основная сложность находится посередине — платформа для разработки программного обеспечения. Здесь координируются все процессы, необходимые для создания и доставки программного обеспечения: CI/CD, сканирование безопасности, подготовка среды и управление выпусками.
Переключение: как внедрить разработку платформ в командах DevOps
Так с чего же начать? Один из успешных шаблонов внедрения фокусируется на определении пути разработчика для определения минимально жизнеспособной платформы. Какие возможности необходимы, чтобы путь разработчика позволил достичь результата? Подумайте о такой задаче, как подготовка среды, развертывание нового API в рабочей среде или запуск набора тестов производительности. Каждый из них представляет собой действительный путь разработчика с множеством точек соприкосновения, которые потенциально требуют множества инструментов. После того как вы создали минимально жизнеспособную платформу для первого набора приложений или технологий, внедрение будет происходить по трем направлениям: больше приложений (как только будут доступны необходимые возможности), больше возможностей и большая зрелость, что приведет к повышению уровня автоматизации и/или производительности..
Помимо заботы о разумном подходе к созданию платформы, на раннем этапе следует рассмотреть три других аспекта:
- Участие сообщества
- Финансирование
- Измерение результатов с помощью платформы
Определение стратегии взаимодействия с сообществом может быть очень полезным. Эта стратегия должна содержать информацию о том, как информация будет передаваться сообществу разработчиков, как можно делать запросы на добавление новых функций и как будут сообщаться о преимуществах платформы. Также полезно определить форумы, способы общения и их частоту.
Финансирование может быстро стать узким местом, поэтому стратегию финансирования следует согласовать на раннем этапе внедрения разработчиком платформы. Это может быть одна из нескольких стратегий, таких как целевое финансирование, финансирование предоставляемых услуг или налог на услуги по всей разработке программного обеспечения. У каждого есть свои преимущества и проблемы, обсуждение которых выходит за рамки данной статьи. Важно иметь устойчивую долгосрочную стратегию финансирования, которая не зависит от доброй воли заинтересованных сторон.
И последнее, но не менее важное: разработчик платформы должен иметь возможность демонстрировать результаты, а это означает, что нам необходимо измерять значимые показатели , которые показывают, почему компании лучше иметь платформу. Об этом часто забывают или думают второстепенно. Понимание приоритетов организации и согласование с ними системы измерения могут помочь добиться постоянной поддержки. К сожалению, это обычно требует согласования данных между несколькими инструментами, и это легче всего сделать, если подумать об этом заранее — это становится все сложнее, чем дольше модели данных отдельных инструментов остаются изолированными.
Заключение
Разработка платформ все еще довольно нова, но по ней уже есть много контента, что показывает, как быстро она завоевала интерес со стороны организаций. Для этого даже есть специальная конференция, которая началась в 2022 году и собрала тысячи участников. Это только начало, но текущие данные показывают, что разработка платформ быстро нашла признание на рынке и активное сообщество. И пока это происходит, роль инженера платформы будет неуклонно возрастать, что уже проявляется и в зарплатах.
Разработчики DST Globalнадеяться, что разработка платформ продолжит помогать организациям снижать сложность для своих разработчиков, одновременно выполняя обещание DevOps: предоставлять лучшие решения быстрее и безопаснее.
