Некоторое время назад я озвучивал свое мнение о том, что такое “devops-инженер” (спойлер: определенный вид разработчика), однако на днях было указание на термин “платформенный инженер” (спасибо, Антон!).

Несмотря на то, что термин “platform engineer” постепенно распространяется, я не считаю его верным. Но вместе с тем он может оказаться полезным.

Platform Engineering это домен проектирования, предметная область, такая же как, например “трансграничные переводы” или “автоматизация склада”, или шире “финтех” и “ретейл”.

Platform team разрабатывает Технологическую Платформу (вариант: Инфраструктурную Платформу, Internal Developer Platform, IDP) – систему, автоматизирующую деятельность сотрудников организации, только в данном случае не финансистов или кладовщиков, а программистов. Для автоматизация работы склада это может быть как коробочное решение (например, 1С Управление складом), так и полностью самописное решение. То же самое с Технологической Платформой – есть вендоры, которые предлагают готовые решения, но чаще всего их собирают …-инженеры из опенсорсных компонентов самостоятельно. 

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

К примеру, платформенная команда занимающаяся компонентами платформы на базе Backstage будет состоять из typescript-разработчика, devops-инженера и DX-чемпиона (в России его скорее всего назвали бы не чемпионом, а аналитиком). Платформенная команда занимающаяся DBaaS будет состоять из Postgres DBA, Golang-программиста, фронтендера и архитектора. А платформенная команда занимающаяся мониторингом будет состоять из спеца по тюнингу прометеуса, девопс-инженера, голанг разработчика и DX-чемпиона.

Если проект маленький, все эти роли могут быть совмещены в одном человеке – в этом случае его можно будет назвать Platform Engineer. Но с большой вероятностью он тогда будет заниматься и задачами команд и ИТ за пределами собственно платформы. Иными словами, попробуйте в этом случае найти три отличия от “devops-инженера”, кроме названия.

Если проект большой – команда будет естественным образом больше. В кроссфункциональной команде возникнет либо разделение работ, либо разделение труда.

Разделение работ (“артель”) - это когда несколько взаимозаменяемых T-shape специалистов с примерно общими для всех компетенциями работают над общим проектом. В этом случае, наверное, термин platform engineer будет вполне корректным. T-shaped платформенные инженеры закрывают все задачи в создании Платформы от проектирования UI и API до производительности дисковой подсистемы и сопровождения в продакшне.

Разделение труда (“производство”) - это команда в которой каждый выполняет свою часть функциональных задач: фронтендер пишет фронтенд, голангер пишет голанг, а девопс настраивает интеграции.

В первом случае (“артель”) команда будет эффективнее с т.з. результативности и проще в управлении, но сложнее в подборе и дороже по стоимости, т.к. будет требовать сеньорных разносторонних экспертов, либо будет требовать развитого и хорошо поставленного процесса онбординга, либо будет необходимо наличие большого количества таких “разносторонних экспертов на рынке” (чего не случится никогда).

Во втором случае (“производство”) команда будет менее гибкая, скорее всего сложнее в эффективном управлении, но проще в подборе и масштабировании.

В свете вышесказанного видится, что “платформенный инженер” как отдельная специальность/должность скорее всего будет актуальной исключительно для компаний, для которых сверхбыстрое и сверхпредсказуемое ИТ является важным конкурентным преимуществом, а не просто способом снизить стоимость реализации проектов. При этом компания будет достаточно большой (от нескольких десятков команд), чтобы IDP выделять как отдельную сущность. Т.е. в первую очередь “платформенные инженеры” будут существовать только в бигтехе и scale-ups в высококонкурентных областях. Либо в высокорегламентированных областях типа медицины, но там их задача будет не ускорение разработки, а обеспечение повторяемого качества релизов любых команд и соответствию регуляторке, и такие платформы вероятно будут достаточно сильно отличаться от платформ в компаниях, работающих в “экономики скорости”. Во всех остальных случаях термин “платформенный инженер” кажется не будет иметь смысла.

При этом “платформенная инженерия” вполне может и будет оставаться актуальным доменом проектирования систем, примерно таким же как “проектирование СЭД” или “проектирование WMS”, именно потому что автоматизация работы команд разработки так или иначе нужна всем, только работать в этих командах будут работать не Platform Engineer, а классические Software Engineer либо Devops Engineer.

Но тем не менее я поддержу термин “платформенный инженер” по одной простой причине. До сих пор не было хорошего способа способом самоидентификации для “devops-инженеров”, “automation engineer”, “build & release engineer”, и всех тех, кто попал в зазор между “developers” и “operations”. Были попытки в виде SRE и Cloud Engineer, но они захватили только часть всей профессии “devops-инженер”, поэтому проблема самоидентификации никуда не исчезла.

Теперь этот способ самоидентификации появился, и при всех его приведенных выше недостатках он выглядит достаточно неплохо: термин “Platform Engineer” дает людям хороший ориентир куда развиваться и к чему стремиться. И одновременно закладывает в понятийное пространство нанимателей организационный паттерн “технологическая платформа”