- Он воспроизводим!
- Он самодокументируемый!
- Он видимый!
- Он предотвращает ошибки!
- Он снижает затраты!
- Он предотвращает отклонения!
- Он предотвращает рутину и увеличивает радость!
- Самообслуживание!
Несомненно, все эти вещи могут быть верными. В идеальном мире все эти преимущества были бы очевидны и огромной пользы для любой организации, готовой вложиться в начальные затраты на переход к развертыванию инфраструктуры в виде кода и управлению конфигурацией. И, в основном, мы все такие. Но что насчет вещей, которые, скажем, не находятся в идеальном мире? Каковы реальные затраты, риски и трудности при внедрении IAC? Где крутой рекламный ход начинает таять под ярким, горячим светом реальности? Давайте рассмотрим некоторые из перечисленных выше преимуществ и проанализируем некоторые из этих предположений.
Он воспроизводим!
Ну, вроде того. Я бы сказал, что код инфраструктуры прекрасно воспроизводим — какое-то время. Но потом… все становится нестабильным. Пакеты устаревают. Функции устаревают и перестают работать. Синтаксис кода меняется. Образы больше не доступны. Dockerhub требует заплатить. Чья-то учетная запись больше здесь не работает. Множество взаимосвязанных зависимостей, обеспечивающих работу развертывания, просто меняются со временем. Дело в том, что код развертывания имеет срок годности, и если вы не будете постоянно его обновлять, он не будет работать, когда вам вдруг понадобится.
Он самодокументируемый!
Опять же, в какой-то мере это верно. Однако у этого аргумента есть несколько недостатков. Первая проблема связана с проблемой, упомянутой выше. Ваш код начинает выглядеть изношенным после некоторого времени. Это означает, что инженер, который впервые просматривает ваш код, может начать преследовать бесполезные цели, пытаясь заставить старый модуль работать в новой облачной среде, где некоторые предположения о том, как делаются вещи, больше не применяются. У меня есть коллеги, которые проводят дни за отладкой и устранением сбоев в развертывании, поэтому они полностью запутываются, потому что то, что они видят в коде, не соответствует реальности. В действительности, вероятно, было бы быстрее и лучше, если бы они просто начали сначала и написали новый код.
Вторая проблема заключается в том, что код, на мой взгляд, действительно не очень хорошо подходит для документации. Я сам писал код и через полгода возвращался к нему, и был полностью озадачен, что я там делал. При написании кода можно использовать все возможные хаки, полумеры и просто неправильные вещи, потому что есть большая вероятность того, что вы учитесь тому, что вы делаете по мере его выполнения. Во время этого можно узнать многое, что заставит вас плакать, когда вы вернетесь к своим первым попыткам. Код инфраструктуры не отличается от этого и может закрепить в себе все виды неправильных предположений и подходов, которые только запутают будущих инженеров, когда они вернутся, чтобы посмотреть на него в будущем.
Он видимый!
Да, он видимый — так же, как если бы я написал кириллицей граффити на стенах кабинета моего главного технолога. Это было бы круто и вызывающе, но никто бы не знал, что это значит. Проблема заключается в том, что это код. Это нечто, что непрофессионал может легко прочитать, даже инженер, который не знаком с Terraform или чем-то подобным, может легко прочитать. Нужна практика и тренировка, чтобы понять содержащуюся информацию, и даже опытным инженерам может потребоваться некоторое время, чтобы полностью понять, где находятся все данные, особенно если у вас много вложенных файлов, зависимостей и сценариев, которые вызывают сценарии, которые вызывают сценарии. Суть в том, что да, вы можете это увидеть, но это не означает, что вы быстро или легко можете это понять.
Он предотвращает ошибки!
Или же, оно может усилить их, как дейтериевая оболочка вокруг ядра водородной бомбы. Я однажды слышал историю об инженере, который запустил команду «terraform destroy» на своем ноутбуке — в неправильной вкладке. Он находился в директории Prod и начал уничтожать прода. Поняв свою ошибку, он нажал Control-C, чтобы остановить процесс, но было уже слишком поздно. Многие вещи уже были уничтожены, и, кроме того, остановка процесса оставила файл состояния в запутанном состоянии. Они смогли восстановить его, вручную исправив файл состояния и повторно запустив terraform, и проблема была решена за пару часов. Но это была действительно ужасно простая ошибка, которую мог совершить любой.
Он снижает затраты!
Если все работает отлично, и ничего никогда не меняется, и вы постоянно делаете одно и то же, то, конечно, да. Но по моему опыту, усилия, которые нужно приложить, чтобы держать свой код в актуальном состоянии, поглощают большую часть времени инженеров. Инженерам требуется много часов в день, чтобы отлаживать, устранять проблемы, изучать и писать код. Иногда потребуется несколько дней работы, чтобы автоматизировать задачу, которая займет всего несколько минут, если вы просто войдете в консоль и нажмете на несколько кнопок. Если вы используете свой код постоянно, то, конечно, это стоит инвестиций. Но вам действительно нужно задать себе вопрос, сколько раз вы действительно будете развертывать новый экземпляр RDS или новый Cloudfront Distro? Многие из этих задач выполняются один раз, и вы можете никогда больше их не делать. Действительно ли вам нужно потратить несколько дней на их автоматизацию?
Он предотвращает отклонения!
Это верно только в том случае, если вы используете код только для изменения настроек в своей среде. Как только у человека появляется доступ к консоли, вы можете столкнуться с проблемой дрейфа (отклонения от желаемого состояния — прим. перев.). Итак, кто этот беспечный злодей, который входит в консоль и вносит изменения? Ну, иногда это вы. Потому что возникла неполадка, и вам нужно было добавить новый сертификат в свой балансировщик нагрузки, или потому что вы подверглись DDOS-атаке и вам нужно было добавить CloudFront Distro для принятия входящих запросов. Или потому что вам нужно масштабировать что-то, чтобы справиться с неожиданной нагрузкой. Очевидно, что вы можете вернуться к коду после внесенных изменений и внести соответствующие правки, но, по моему опыту, в реальном мире такие ситуации случаются довольно регулярно, и это может показаться глупым.
Он предотвращает рутину и увеличивает радость!
Хотите утомительной работы? Как насчет обновления версии Terraform 0.10 до Terraform 1.3? Существует значительная разница в синтаксисе, которую некоторые автоматизированные инструменты могут обрабатывать. Однако в старых версиях требовались многочисленные хаки, которые были улучшены в новых версиях при добавлении функций. Это означает, что автоматизированные инструменты для обновления синтаксиса недостаточны, и вам нужно полностью рефакторить репозиторий от начала до конца. У моих коллег работа по миграции на Terraform продолжается уже более года. Это огромный проект, который требует множество часов работы инженеров обновления. Иногда бывает трудно убедить начальство в том, что это необходимо, особенно если вы уже израсходовали свой кредит доверия, вкладывая многие месяцы усилий в создание кода в первую очередь.
Самообслуживание!
Святой Грааль для команды Platform Team — PAAS самообслуживания для всей компании. Вся ваша инфраструктура и сервисы настолько тщательно автоматизированы, что инженер, не являющийся DevOps, может взять git-репозиторий, отредактировать несколько файлов шаблонов, выложить их обратно, и ваша система CI/CD развернет их автоматически. Все протоколирование, оповещение, метрики и политики безопасности уже встроены. Мне откровенно нравится эта идея. Сейчас я работаю над тем, чтобы привести свою нынешнюю компанию к такому состоянию. Но опять же это наталкивается на реальность. Например, раньше у нас была довольно сложная автоматизированная система управления учетными записями пользователей в Github. Мы редактировали файлы, отправляли их в CI, и пользователи и репозитории заполнялись. Однако мы поняли, что это излишне сложно и значительно замедляет процесс принятия на работу новых сотрудников и подрядчиков, пока они ждут, пока кто-то из технических специалистов отредактирует файлы автоматизации. Гораздо проще и быстрее было просто убедиться, что менеджеры команд прошли проверку и обучение политике безопасности и получили доступ к Github напрямую. Мы верим, что они правильно нажмут на кнопку, чтобы добавить новые учетные записи и предоставить им права доступа.
Заключение
Значит ли это, что мы просто отказываемся от всей идеи IAC и возвращаемся к тому, чтобы кликать вокруг Консоли? Ну, не всегда? Я думаю, что это лучший ответ. Как и хорошие идеи прошлого — думайте об Agile, Scrum, DevOps, Serverless, Microservices, все эти вещи могут принести много пользы. Вы просто не можете узко сосредоточиться и считать, что вам нужно посвятить себя этой идее, как будто это единственный смысл вашей жизни. IAC имеет свое применение, но это всего лишь использование. Не каждый случай будет одинаковым, и всегда есть дьявольские детали, с которыми нужно бороться. Хороший инженер или менеджер по инженерии знает, когда пришло время отпустить платонический идеал автоматизированного совершенства и дать людям некоторую гибкость, когда это необходимо.
