Devops: как экономить на создании и обслуживании инфраструктуры разработки.

Одна из идей Devops - обеспечить команде на проекте единую инфраструктуру. Чтобы разработчики писали программы, а QA - тестировали в той же среде, в которой они будут потом использоваться.
Далее - купленное оборудование нужно и близко не 24/7, большую часть времени оно простаивает, медленно покрываясь пылью и устаревая. Разработчики алчно посматривают на курс биткоина и все чаще шутят на тему того, что в свободное от работы время на оборудовании можно майнить биткоины, но едва ли кто-то переходит от слова к делу.

Каждый раз, когда в инфраструктуре надо что-то поменять, процедура настройки идет по привычным кругам ада: разработчики или QA сообщают админу о своих потребностях, он тратит время на настройку, и это далеко не пять минут. Лишь в том случае, если изначально разные компоненты инфраструктуры не очень хорошо взаимодействовали между собой и для их работы приходилось дописывать "Костыли", то теперь админу надо будет вспомнить, что оно такое было, и повторить. И было бы здорово, если бы все потом использовалось дольше, чем настраивается или еще один пример. Компания на работу нового разработчика нанимает. Он приходит в офис, полдня ждет, пока ему принесут стол, потом еще полдня - когда появится админ, и они вместе отправятся в подсобку собирать ему рабочую "Машину". Еще несколько дней уходит на то, чтобы установить и настроить инфраструктуру (а денежки в это время уже капают. Потом компания решает, что в идеале ей бы еще нанять парочку тестировщиков, и после продолжительных собеседований и тестовых заданий долгожданные новобранцы появляются в офисе. Ждут свои столы, ждут админа, потом ждут, пока нужная для тестирования среда будет у них на компьютере.
Все эти процессы (кроме ожидания стола и админа, конечно), если их автоматизировать, могут занимать всего несколько минут.
В Devops - практике это называется "Инфраструктура как код".
Только в том случае, если искать в интернете подробное описание практики, то можно наткнуться на большое количество написанных сложным техническим языком текстов, в которых идет речь о конкретных кейсах и описываются процессы. В случае если вы не технический специалист и читаете эту статью, так как связаны с разработкой постольку - поскольку, то вам нужно знать не их, а то, как это все устроено в общих чертах (а если вам нужны именно конкретные примеры настраивания, то в этом тексте их не будет.

"Инфраструктура как код" подразумевает, что все данные об инфраструктуре хранятся в виде скриптов в репозитории (в том же, которым пользуются разработчики проекта или другом, не принципиально) и извлекаются оттуда, когда нужно. Даже ждать, когда админ физически доберется до объекта, не надо - ведь все процедуры можно произвести "в Облаке".

Только в том случае, если "Ложится" один из серверов проекта, то это уже не повод для паники и бегства с корабля - восстановление инфраструктуры из готового файла занимает так же мало времени. Все уже было однажды создано, оттестировано на работоспособность и готово к внедрению сколько угодно раз и в любой момент.
В таком виде вы получаете более гибкую систему, которую проще перенастраивать под следующие проекты. Таким образом, если оказывается, что компоненты инфраструктуры плохо работают друг с другом, то конфликты совместимости достаточно решить один раз и для всех дальнейших случаев.

Ценность такого подхода заключается в том, что он позволяет быстрее осуществлять "Доставку" инфраструктуры туда, где она нужна, и оптимизировать неиспользуемые ресурсы. Например, для определенного проекта необходимо такое-то количество виртуальных машин и серверов с такими-то характеристиками, таким-то программным обеспечением, таким-то объемом накопителя. В случае если вы используете облако Azure, то проще всего создать шаблон инфраструктуры в Azure Resource Manager и быть уверенным, что все участники рабочей группы получат абсолютно одинаковые виртуальные машины - с теми же настройками и даже файлами в тех же каталогах. В дальнейшем при помощи одной команды можно будет просматривать все логи, связанные с работой инфраструктуры для этой группы и менять все на лету - подключать необходимые модули и библиотеки, менять настройки в соответствии с тем, что нужно для развертывания конкретного приложения, и быть уверенным, что нужна среда есть у всех, кто работает над проектом. Не вкладывая деньги и время в физическую инфраструктуру и оплачивая ровно то и ровно столько, сколько используется.
Microsoft Azure позволяет создавать инфраструктуру и управлять конфигурацией в том числе при помощи сторонних инструментов - таких как Chef и Puppet.
Публичное облако не привязывает вас к определенной инфраструктуре в режиме 24/7. Соответственно, платить в нем можно только за те лицензии, объем накопителя, сервера и виртуальные машины, которые потребляет проект. Что-то из этого необходимо на весь период разработки, что-то - как виртуальные машины для тестирования - только часов 8-10 в день, на ночь их можно спокойно выключать (причем это все тоже настраивается один раз и работает всегда, если вдруг кто-то из команды решает совершить трудовой подвиг ночью или на выходных, то в единичных случаях правила тоже легко поменять на один момент. Это дает максимальный контроль над технической стороной проекта и над расходами на инфраструктуру.