Путь развития разработчика в Infrastructure as Code

Недавно вышли новые роадмапы профессионального развития на https://roadmap.sh/ и они на мой взгляд очень хорошо помогают прояснить мой предыдущий пост про то, что подход Infrastructure as Code — это особая форма разработки. Я не уверен, что согласен с названиями роадмапов, но разделение на роадмапы мне кажется очень хорошо сделанным:

- Software Architect — список навыков указывают, что основные задачи это построение систем, состоящих из множества отдельно разрабатываемых компонентов (и интеграция этих компонентов между собой), коммуникация с разработчиками, другими архитекторами и руководством компании, и организация проекта. Одним словом, чтобы множество команд разработки и программные сервисы которые они разрабатывают интегрировались друг с другом и при этом решали бизнес-задачи. Нужны ли эти практики в подходе Infrastructure as Code? Не уверен, скорее всего если выходишь на такой уровень в организации тебе уже не нужен IaC, но вместе с тем практически все эти темы в той или иной мере затрагиваются если ты занимаешься методологией DevOps.

- Software Design and Architecture (напомню, что “design” переводится как “проектирование”) — список навыков указывает, что основные задачи это структурирование программного кода, разбиение на модули и интеграция между ними. Одним словом, все то, что нужно для того, чтобы код в рамках одного сервиса был не лапшой, а был поддерживаемым, тестируемым, изменяемым, надежным и т.п. Нужны ли эти практики в подходе Infrastructure as Code? Несомненно. Если размер инфраструктурного кода десятки тысяч строк, применение всех этих практик и концептов поможет справиться со сложностью и в декларативных языках — сложность в них с ростом кодовой базы растет медленнее чем в императивных, но все же растет. Отдельные принципы скорее всего неприменимы, но не столько неприменимы сами по себе, сколько по причине относительно более простой и относительно маленькой кодовой базы в случае инфраструктуры, и относительно стабильного пространства понятий которые мы при помощи IaC описываем.

- Backend Developer — здесь говорится об инструментах и концепциях применяемых собственно в процессе разработки. Что-то из этого если находимся в контексте инфраструктуры мы знаем и так, что-то становится применимо сразу же как-только мы начинаем заниматься SRE, а не только писать код. В целом кажется применимым не столько к IaC, сколько к SRE.

Напомню свой тезис, который прозвучал в начале: практика Infrastructure as Code является не чем иным как программированием в “особой” доменной области на “особом” языке. Примерно так же как современное фронтенд-программирование имеет довольно мало общего с тем программированием на языке Паскаль, которое мы изучали в школе. Основные отличия находятся в решаемой проблематике и в конкретных языках программирования, которые применяются для решения задач.

Есть ли что-то, что я упустил в рассуждениях?