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