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



Типичная команда разработчиков собирала свое приложение и «перебрасывала его через стену» команде сисадминов. Последние должны были разобраться с тем, как его развертывать и запускать. Большая часть этого процесса выполнялась вручную. Отчасти потому, что это неизбежно требовало подключения физического аппаратного обеспечения (например, расстановки серверов по стойкам и разводки сетевых кабелей). Но программные аспекты работы системных администраторов, такие как установка приложений и их зависимостей, часто выполнялись вручную путем выполнения команд на сервере.

До поры до времени этого было достаточно, но по мере роста компании начинали возникать проблемы. Обычно выглядело так: поскольку ПО доставлялось вручную, а количество серверов увеличивалось, выпуск новых версий становился медленным, болезненным и непредсказуемым. Команда сисадминов иногда допускала ошибки, и в итоге некоторые серверы требовали немного других настроек по сравнению со всеми остальными (это проблема, известная как дрейф конфигурации). Поэтому росло число программных ошибок. Разработчики пожимали плечами и отвечали: «У меня на компьютере все работает!» Перебои в работе становились все более привычными.

Команда администраторов, уставшая от вызовов в три часа ночи после каждого выпуска, решала снизить частоту выпуска новых версий до одного в неделю. Затем происходил переход на месячный и в итоге на полугодовой цикл. За несколько недель до полугодового выпуска команды пытались объединить все свои проекты, что приводило к большой неразберихе с конфликтами слияния. Никому не удавалось стабилизировать основную ветку. Команды начинали винить друг друга. Возникало недоверие. Работа в компании останавливалась.

В наши дни ситуация меняется коренным образом. Вместо обслуживания собственных вычислительных центров многие компании переходят в облако, пользуясь преимуществами таких сервисов, как Amazon Web Services (AWS), Microsoft Azure и Google Cloud Platform (GCP). Вместо того чтобы тесно заниматься оборудованием, многие команды системных администраторов проводят все свое время за работой с программным обеспечением, используя инструменты вроде Chef, Puppet, Terraform и Docker. Вместо расставления серверов по стойкам и подключения сетевых кабелей многие сисадмины пишут код.

В итоге обе команды, Dev и Ops, в основном занимаются работой с ПО, и граница между ними постепенно размывается. Возможно, наличие отдельных команд, отвечающих за прикладной и инфраструктурный код, все еще имеет смысл, но уже сейчас очевидно, что обе они должны работать вместе более тесно. Вот где берет начало