Укр Рус
DevOps як наслідок закону Мура

DevOps як наслідок закону Мура

  • 6 травня
  • читати 10 хв
Олександр Грабко
Олександр Грабко Senior Systems Engineer (DevOps) у EPAM, Викладач Комп'ютерної школи Hillel.

Гордон Мур зробив емпіричне спостереження: кількість транзисторів (логічних елементів), які розміщені на інтегральній схемі, має подвоюватись кожні два роки. Це спостереження підтверджується з 1975 року, тому воно відоме як «закон» Мура.

Збільшення кількості логічних елементів тягне у себе у тому числі й необхідність зміни програмного забезпечення: операційних систем, прикладних програм — усе це означає, що вся IT сфера перебуває у стані розвитку та різноманітних трансформацій протягом десятиліть.

Якщо ми говоримо про набір практик під назвою DevOps, то вони якраз і є відображенням необхідності постійних змін в IT.

Розвиток обчислювальних систем

Якщо простежити еволюцію комп'ютерних обчислень на високому рівні, можна побачити, що спочатку існували виключно штучні (в єдиному екземплярі) промислові комп'ютери. Потім відбулася революція — обчислення та комп'ютери стали персональними.

Нині ж ми спостерігаємо запровадження комп'ютерів у величезну кількість побутових речей — починаючи телефонами і закінчуючи холодильниками, прасками, кросівками тощо.

Ми є свідками подальшої мініатюризації комп'ютерів при одночасному збільшенні їхньої продуктивності.

У цей же час відбулося «переміщення» обчислень з робочого столу користувача в «хмари» — з'явилася технічна можливість займатися обчисленнями віддалено — тепер немає необхідності мати безпосередній фізичний доступ до обчислювальних потужностей.

Таку зміну можна порівняти з появою телефону/телевізора — по-перше, за кількістю трансформацій, що вона викликає, по-друге, за якісними змінами.

Так само, як раніше з'явилася можливість спілкуватися дистанційно, не витрачаючи час і гроші на фізичне переміщення (що означає прискорення обчислень та їх здешевлення), з'явилася можливість «обчислювати дистанційно» (з тими самими прискоренням обчислень та їх здешевленням).

Отже: трансформація обчислювальних потужностей, а саме технічне переміщення комп'ютерів у хмари, забезпечила можливість, а за цим і необхідність, кардинальної зміни управління цими обчислювальними потужностями.

Сам перехід — це перехід від адміністрування одиничного комп'ютера (неважливо сервера або робочої станції) вручну до адміністрування безлічі віртуальних машин (але і не тільки) за допомогою засобів і інструментів автоматизації.

Перехід від традиційного адміністрування до DevOps

Саме перехід від «традиційного адміністрування» — одиничний, унікальний комп'ютер з унікальним набором налаштувань вручну, до DevOps практики — велика кількість віртуальних машин або сервісів з уніфікованими налаштуваннями та автоматизованим керуванням/налаштуванням, є головним викликом як для зрілого спеціаліста, так і для неофіта.

Одночасно це означає необхідність роботи як з неспецифічними (Bash, Powershell Scripting, Python, GO, іншими мовами програмування), так і специфічними (Desired State Configuration for Windows або для певного клауду — як Cloud Formation для AWS Cloud) технологіями.

Підхід до власне «адміністрування операційної системи» також дуже відрізняється: від «кожний сервер/віртуальна машина унікальна, працездатність у разі збою відновлюється з бекапів» до «сервер/віртуальна машина максимально уніфікована, працездатність у разі збою забезпечується перестворенням з еталонного образу з наступним застосуванням специфічної конфігурації».

Цей підхід також сильно змінює вимоги та підходи до діагностики проблем: замість необхідності глибоко розумітися на базових технологіях, таких як глибоке знання різних ОС або мережі, до необхідності розуміти зони відповідальності та компетенцій, що дозволяють ефективно спілкуватися з клауд провайдером або знаходити та виробляти специфічні для клауду варіанти вирішення проблем.

Підходи переходу до клауду

Можна говорити про те, що «перехід у клауд» загалом поділяється на два сценарії — у першому випадку якась локальна інфраструктура вже існує і її потрібно мігрувати у хмару, у другому — інфраструктуру необхідно створити з нуля.

Кожен із підходів створює свої виклики: у разі міграції до клауду існуючої інфраструктури може знадобитися, наприклад, забезпечення безперервної роботи, тобто перехід має бути «безшовним» — користувачі повинні переміститися непомітно для себе і без перерви в роботі. У разі необхідності створити все з нуля — це може означати необхідність освоїти нові технології (специфічні хмари), а також необхідність перевчити користувачів. Міграція в клауд також означає, як мінімум, ревізію, а іноді і суттєвий перегляд практики використання ліцензій на програмне забезпечення.

Як не дивно, найбільшим викликом була і залишається необхідність зміни на ходу.

Це стосується і самої інфраструктури. Адже хмари розвиваються, змінюється набір та функціонал клауд сервісів, деякі сервіси оголошуються застарілими та перестають існувати, деякі радикально змінюються, і це означає необхідність зміни роботи з ними, з'являються нові можливості, які дозволяють вирішувати раніше нерозв'язні задачі або вирішувати старі завдання новим способом, але більш ефективно.

Постійно виникає новий інструментарій, вносяться зміни у роботу існуючого інструментарію. Все це відбувається синхронно із змінами згідно із законом Мура.

Мабуть, не можна говорити про те, що швидкість цифрової трансформації дорівнює або наближається до швидкості зміни кількості логічних елементів в інтегральних схемах, але принаймні вона сильно від неї залежить і повністю нею визначається.