Тренды ведут к тому, что рекрутеры IT-компаний рекламируют новую роль — инженера платформы. Давайте разберёмся, что это за должность и как она связана со «смертью» DevOps.
Кто такой инженер платформы
Разработка платформ — это новый технологический подход, который может ускорить доставку приложений и темпы, с которыми они становятся ценными для бизнеса. На нижнем уровне те, кто выполняет роль инженера, предоставляют разработчикам стандартизированную платформу. И разработчики уже могут использовать выходные данные для доставки разработанного приложения, не беспокоясь о базовых зависимостях. Код может проходить через весь цикл разработки, невзирая на то, что какие-либо основные библиотеки или предварительные требования отсутствуют или не соответствуют спецификации. Согласитесь, стабильная среда для нашего развития — звучит здорово.
С первого взгляда может показаться, что роль инженера платформы сосредоточена только на потребностях разработчика, а не бизнеса в целом. Но что именно предлагает Platform Engineering с точки зрения сокращения рутины, устранения ограничений и оптимизации рабочих центров? Всё зависит от вашего определения DevOps. Посмотрите, как делаем его мы.
Реальная ценность DevOps
DevOps — это не просто технология, ведь речь идет о сокращении ненужного труда, выявлении болевых точек, сокращении переделок и обеспечении ценности для бизнеса. Инструменты вроде Terraform, Git, Pipelines и т.д — всего лишь метод обеспечения ценности, но не ценность сама по себе.
Реальная ценность в индустриализации ИТ.
DevOps — на самом деле это бизнес-процесс, а не технический процесс. Он про то, чтобы стандартизировать всё, что можно, и автоматизировать процессы. А это уже снизит затраты на развертывание и повысит стабильность приложений, позволит сотрудникам делать гораздо больше с теми ресурсами, что у вас есть. Также DevOps избавляет от рабочей скуки, ведь каждый член команды может участвовать в процессах, которые еще больше расширяют возможности бизнеса.
Со временем основополагающий принцип DevOps и его уникальная ценность были утрачены — их заглушили поставщики сервисов своим желанием контролировать сферу сообщениями в духе «все дело в инструментах». И потом возникли споры, является ли декларативный подход лучше процедурного? Использовать шаблоны ARM, или Bicep в Azure, или облака на AWS? Является ли шеф-повар лучше, чем Ansible или Puppet? Chef лучше, чем Ansible или Puppet?
Но суть в том, что выбор инструментов не влияет на ценность или увеличение прибыли для бизнеса. Важен сам процесс.
Вы начинаете с бизнес-потребностей, и только когда вы понимаете их и можете определить бизнес-обоснование, которое повышает ценность или увеличивает прибыль, вы можете приступить к определению функциональных и нефункциональных требований… И только потом стоит думать о технологии, которая поможет в реализации стратегии.
Итак, почему при обсуждении DevOps мы начинаем с технологий. А дело в том, что микрофон у продавцов, которые рекламируют свои товары. Люди забыли, что DevOps зародился как реакция на Waterfall — методологии, которая предлагала длительные циклы разработки в сочетании с полнофункциональными релизами ежеквартально или ежегодно.
Проекты часто перегружались из-за неправильно рассчитанных сроков и постоянно растущего объема хаотичных практик. DevOps же был революционным — он предлагал сумасшедшие вещи, такие как многократные релизы ежедневно, индустриализация и определение потока работ, минимизация переделок. ИТ-специалисты, которые считали свою работу основанной на знаниях, а себя ремесленниками, чувствовали себя как дома в этом производственном потоке.
DevOps построил свои основные идеи на бережливых процессах. Об этом писал ещё Голдратт в его знаменитой книге «Цель: процесс непрерывного совершенствования», где основное внимание уделяется улучшению производства на заводе-изготовителе, эффекту Toyota и трех путях развития.
Так что весь шум от поставщиков сервисов уменьшает истинную ценность DevOps, а мы теряем из виду истинную причину, за которую пришли к DevOps.
DevOps — это про гибкость бизнеса и совершенствование. Масштабирование того, что у вас есть, чтобы прийти к чему-то большему. Устранить повторяющуюся рутину, оптимизировать процессы и предотвратить потери в процессе работ — но, прежде всего, речь идет об общении и укреплении доверия к работе других.
Итак, DevOps мертв? Все ли мы теперь инженеры платформы?
Нет, не все. Разве что некоторые :) Факт в том, что Platform Engineering — это лишь небольшая часть DevOps. Хорошее начало, но это точно не конечная точка. И если вы находитесь в этом путешествии и только что зашли в закусочную под названием Platform Engineering, наслаждайтесь своим пребыванием там, но помните, что путешествие продолжается. DevOps — это постоянное совершенствование. А Platform Engineering — всего лишь круг в бесконечном цикле.
Приходите к нам за помощью — мы создаём высокопроизводительные системы, повышаем стабильность существующего программного обеспечения, отслеживаем бизнес-метрики и улучшаем системы мониторинга, а также обеспечиваем техническую поддержку в режиме 24/7