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

В статье ¹ мимоходом отлично прояснен этот вопрос через определение того, что такое “инженерия”:

Ideally the construction design phase results first into an ontological model of the object system, i.e. a white-box model that is completely independent of its implementation. Gradually this ontological model is transformed into more detailed (and more implementation dependent) whitebox models, the last one being the implementation model. This process is called implementation design or just engineering. If the object system is a software application, then the implementation model would be the source code in some programming language. The act of implementing consists of assigning appropriate technological means to the implementation model, e.g. running the source code on an appropriate platform.

Мой вольный перевод:

В идеальном случае, фаза конструктивного проектирования дает на выходе онтологическую модель целевой системы, т.е. модель прозрачного ящика (whitebox), которая полностью независима от ее имплементации. Постепенно эта онтологическая модель трансформируется в несколько более детализированных (и более зависимых от имплементации) моделей прозрачных ящиков, последняя из них будет моделью имплементации. Этот процесс называется “проектирование имплементации” или просто “инженерия”. Если разрабатываемая система это программа/приложение, имплементацией модели будет исходный код на некотором языке программирования. Акт имплементации состоит в назначении на эту модель соответствующих технологических средств, т.е. запуск исходного кода на подходящей платформе.

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

Иными словами, подход “инфраструктура как код” будет отличаться от “классического программирования” только если говорить о конкретной имплементации в коде и технологиях (и отличаться будет сравнимо с отличиями языка C от Haskell). Однако если говорить о дисциплинированной практике проектирования разница между ними будет только в части имплементации.

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