Гордон Мур сделал эмпирическое наблюдение: количество транзисторов (логических элементов), размещенных на интегральной схеме, должно удваиваться каждые два года. Это наблюдение подтверждается с 1975 года, поэтому оно известно как «закон» Мура.
Увеличение количества логических элементов влечет за собой в том числе и необходимость изменения программного обеспечения: операционных систем, прикладных программ — все это означает, что вся IT сфера находится в состоянии развития и различных трансформаций на протяжении десятилетий.
Поговорим о наборе практик под названием DevOps — что это, и почему DevOps является отражением необходимости постоянных изменений в IT.
Развитие вычислительных систем
Если проследить эволюцию компьютерных вычислений на высоком уровне, можно увидеть, что сначала существовали исключительно штучные (в единственном экземпляре) промышленные компьютеры. Затем произошла революция — вычисления и компьютеры стали персональными.
А сейчас мы наблюдаем внедрение компьютеров в огромное количество бытовых вещей — начиная телефонами и заканчивая холодильниками, утюгами, кроссовками и так далее.
Мы являемся свидетелями дальнейшей миниатюризации компьютеров при одновременном увеличении их производительности.
В это же время произошло «перемещение» вычислений с рабочего стола пользователя в «облака». Теперь, когда появилась техническая возможность заниматься вычислениями удаленно, нет необходимости иметь непосредственный физический доступ к вычислительным мощностям.
Такое изменение можно сравнить с появлением телефона/телевизора — во-первых, по количеству тех трансформаций, которое оно вызывает, во-вторых, по качественным изменениям.
Точно так же, как раньше появилась возможность общаться удаленно, не тратя время и деньги на физическое перемещение (что означает ускорение вычислений и их удешевление), появилась возможность «вычислять удаленно» (с теми же самыми ускорением вычислений и их удешевлением).
Итак: трансформация вычислительных мощностей, а именно техническое перемещение компьютеров в облака, обеспечила возможность, а следом за этим и необходимость, в кардинальном изменении управления этими вычислительными мощностями.
Собственно сам переход — это переход от администрирования единичного компьютера (неважно: сервера либо рабочей станции) вручную к администрированию множества виртуальных машин (но и не только) при помощи средств и инструментов автоматизации.
Переход от традиционного администрирования к DevOps
Именно переход от «традиционного администрирования», при котором речь идет о единичном, уникальном компьютере с уникальным же набором настроек вручную; к внедрению DevOps, простыми словами, — к большому количеству виртуальных машин или сервисов с унифицированными настройками и автоматизированным управлением, именно этот переход является главным вызовом как для зрелого специалиста, так и неофита.
Одновременно это означает необходимость работы как с неспецифическими (Bash, Powershell Scripting, Python, GO, другими языками программирования), так и специфическими (Desired State Configuration for Windows или для определенного клауда — как Cloud Formation для AWS Cloud) технологиями.
Подход к собственно «администрированию операционной системы (ОС)» также сильно отличается: от «каждый сервер/виртуальная машина уникальна, работоспособность в случае сбоя восстанавливается из бекапов» до «сервер/виртуальная машина максимально унифицирована, работоспособность в случае сбоя обеспечивается пересозданием из эталонного образа с последующим применением специфической конфигурации».
Этот подход также сильно изменяет требования и подходы к диагностике проблем: вместо необходимости глубоко разбираться в базовых технологиях, таких как глубокое знание различных ОС или сети, до необходимости понимать зоны ответственности и компетенций, позволяющих эффективно общаться с клауд провайдером или находить и вырабатывать специфические для клауда варианты решения проблем.
Подходы к переходу в клауд
Можно говорить о том, что «переход в клауд» в общем разделяется на два сценария — в первом случае некая локальная инфраструктура уже существует и ее нужно мигрировать в облако, во втором — инфраструктуру необходимо создать с нуля.
Каждый из подходов создает свои вызовы: в случае миграции в клауд существующей инфраструктуры может понадобиться, например, обеспечение беспрерывной работы. В этом случае переход должен быть «бесшовным» — пользователи должны переместиться незаметно для себя и без перерыва в работе.
В случае необходимости создать все с нуля — это может означать необходимость освоить новые технологии, а также необходимость переучить пользователей. Миграция в клауд также означает плотную роботу DevOps и сисадмина, а еще как минимум ревизию, а иногда и существенный пересмотр практики использования лицензий на программное обеспечение.
Как ни странно, самым большим вызовом была и остается необходимость «изменения на ходу».
Это относится и к самой инфраструктуре. Ведь облака развиваются, меняется набор и функционал клауд сервисов, некоторые сервисы объявляются устаревшими и перестают существовать, некоторые радикально реформируются, и это означает необходимость изменения работы с ними, появляются новые возможности, которые позволяют решать ранее неразрешимые задачи или решать старые задачи новым способом, но более эффективно.
Постоянно возникает нововведения, вносятся изменения в работу существующего инструментария. Все это происходит синхронно с изменениями согласно закону Мура.
Пожалуй, нельзя говорить о том, что скорость цифровой трансформации равна или приближается к скорости изменения количества логических элементов в интегральных схемах, но, по крайней мере, она сильно от нее зависит и всецело ею определяется.
