Terraform: инфраструктура на уровне кода

Как известно, оценка сроков разработки программных проектов очень приблизительна. И это вдвойне касается проектов DevOps. Небольшое исправление, которое, как можно было бы ожидать, требует не более пяти минут, на самом деле занимает целый день. Мелкая функция, на реализацию которой, по вашим прикидкам, нужно потратить день работы, растягивается на две недели. Приложение, которое, как вы надеялись, должно быть выпущено за две недели, все еще не готово спустя полгода. Проекты, связанные с инфраструктурой и DevOps, идеально иллюстрируют закон Хофштадтера48:

Закон Хофштадтера: работа всегда занимает больше времени, чем вы ожидаете, даже с учетом закона Хофштадтера.

Даглас Хофштадтер

Мне кажется, у этого есть три основные причины. Прежде всего, DevOps как индустрия все еще находится в каменном веке. Я не пытаюсь никого обидеть, а просто хочу указать на незрелость этих технологий. Термины «облачные вычисления», «инфраструктура как код» и DevOps появились лишь во второй половине 2000-х годов, и инструменты вроде Terraform, Docker, Packer и Kubernetes впервые были выпущены в середине или конце 2010-х. Все эти средства и методики относительно новые и быстро развивающиеся. Значит, они не совсем зрелые и глубокими знания­ми в этой области обладает не так уж много людей, поэтому неудивительно, что на проекты уходит больше ожидаемого времени.

Вторая причина — DevOps, похоже, особенно подвержен эффекту стрижки быка (yak shaving). Если вам незнаком этот термин, уверяю, вы его полюбите (и возненавидите). Лучшее его определение, которое мне встречалось, опубликовано в блоге Сета Година49:

«Я хочу сегодня помыть машину».

«Ох, шланг треснул еще зимой. Придется купить новый в Home Depot».

«Но Home Depot на другом конце моста, а проезд по нему платный, и без платежной карточки будет дорого».

«Ой, точно! Я могу одолжить карточку у своего соседа…»

«Но Боб не даст мне свою карточку, пока я не верну ему подушку-обнимушку, которую взял мой сын».

«А не вернули мы ее потому, что из нее вылезла часть набивки, и, чтобы набить ее снова, мне нужна бычья шерсть».

Таким образом, вы докатились до того, что стрижете быка в зоопарке — и все для того, чтобы помыть свою машину.

Сет Годин

Стрижка быка состоит из всех этих мелких и, на первый взгляд, не связанных между собой задач, которые нужно выполнить до того, как приступать к изначально запланированной работе. Если вы разрабатываете программное обеспечение и особенно если вы работаете в сфере DevOps, подобного рода ситуации вам встречались тысячу раз. Вы беретесь за развертывание исправления для небольшой опечатки, чем внезапно провоцируете ошибку в конфигурации приложения. После нескольких часов на StackOverflow вы решили проблему с TLS и теперь пробуете развернуть свой код еще раз, но тут у вас начинаются проблемы с системой развертывания. Чтобы в них разобраться, вы тратите еще несколько часов и обнаруживаете, что причина — в устаревшей версии Linux. Не успев оглянуться, вы беретесь за обновление операционной системы на целой армии серверов — и все для того, чтобы «быстро» развернуть исправление небольшой опечатки.

DevOps, по всей видимости, особенно подвержен подобного рода конфузам со стрижкой быков. Отчасти из-за незрелости данной технологии и современных подходов к проектированию систем, которые часто требуют жесткого связывание и дублирования инфраструктуры. Любое изменение, которое вы делаете в мире DevOps, сродни попытке выдернуть один USB-кабель из коробки с запутанными проводами — обычно таким образом вы вытягиваете все содержимое коробки. Но в какой-то мере это связано с тем, что термин DevOps охватывает поразительно широкий спектр тем: от сборки до развертывания, обеспечения безопасности и т. д.

Это подводит нас к третьей причине, почему работа в сфере DevOps занимает столько времени. Первые две причины (DevOps в каменном веке и стрижка быка) можно классифицировать как ненужные сложности. Ненужные сложности — это проблемы, связанные с определенными инструментами и процессами, которые вы сами выбрали. Их противоположность — имманентные сложности — проблемы, присущие тому, над чем вы работаете50. Например, если вы используете C++ для написания алгоритмов биржевых торгов, проблемы с ошибками выделения памяти будут необязательными трудностями — если бы вы выбрали другой язык программирования с автоматическим управлением памятью, этих проблем у вас бы вообще не было. С другой стороны, подбор алгоритма, способного преуспеть на рынке, является имманентной сложностью — эту проблему придется решать независимо от того, какой язык программирования был выбран.