Об DevOps и архитектуру

Об платформенных инженеров [1/2]

Некоторое время назад я озвучивал свое мнение о том, что такое “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 до производительности дисковой подсистемы и сопровождения в продакшне.

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

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

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

👍2

www.tgoop.com/devops_architecture/58

536 viewsTimur Batyrshin, edited  Nov 6, 2024 at 17:41

Об платформенных инженеров [1/2]

Некоторое время назад я озвучивал свое мнение о том, что такое “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 до производительности дисковой подсистемы и сопровождения в продакшне.

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

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

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

BY Об DevOps и архитектуру