DevOps майбутнього: що зміниться та як це вплине на професію

Інновації розвиваються дуже швидко, постійно з’являються нові технології, що змінюють контекст, у якому ми працюємо. Відповідно, у такому динамічному середовищі не можна стояти на місці — треба безперервно вивчати нове й розвиватися. Водночас важливо правильно визначити, на яку технологію зробити ставку сьогодні, щоб бути успішним завтра. Це певною мірою лотерея. Тепер перемагають ті, хто 5 років тому поставив на Kubernetes, а не на Docker Swarm, або вибрав Azure замість Oracle Cloud.

Я як директор Cloud & DevOps Services у SoftServe вирішую це не лише для себе, а й для компанії: у які технології нам інвестувати, у якому напрямі розвивати експертів компанії та що пропонувати клієнтам.

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

З чого все починалося та як еволюціонувала роль клаудів

Короткий флешбек в еволюцію клаудів. Pre-Cloud — олдскул: сервери, роутери, СЗД. Працюємо з цим самі — установлюємо ОС, отримуємо бібліотеки й платформи, розгортаємо еплікейшени, конфігуруємо й автоматизуємо. Далі — цікавіше.

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

Cloud 0 — у деяких хостинг-компаній з’являється ідея продавати не реальні сервери, а віртуальні, забезпечуючи всю потрібну автоматизацію й роботу щодо керування інфраструктурою. Ми бачимо зародження того, що в майбутньому дістане назву IaaS (Infrastructure as a Service). Але тодішньому сервісу ще далеко до того, щоб називатися клауд-провайдером.



Cloud 1.0 — зліт клауд-платформ. З’явилося розуміння, що більшість компаній використовують ті ж самі ОС, платформи та фреймворки (Linux, Apache, PHP тощо). Це означає, що їх також можна автоматизувати, а інструменти для використання цих платформ — продавати як сервіс. З’являються PaaS (Platforms as a Service), розвивається тренд на використання публічних клаудів. Інженери отримують нові інструменти для роботи з платформами без потреби розгортати й підтримувати їх самостійно. Обсяг рутинної технічної роботи стає ще меншим. Акцент у роботі DevOps-інженера зміщується на налаштування платформи, налагодження й розгортання рішення на цій платформі, оптимізацію використання ресурсів, контроль за тим, наскільки швидким, зрозумілим, гнучким є весь процес.



Cloud 2.0 — автоматизація поширюється не лише на платформи, а й на деякі традиційні сервіси (email, queues). Нам більше не треба думати про їх розгортання, керування ними та їх масштабування, оскільки з’являється такий концепт, як Software as a Service (SaaS). Він змінює парадигму в бік відмови від традиційного білінгу за серверні ресурси (CPU/RAM/HDD) до оплати абонемента на сервіс і використаних ресурсів еплікейшен-рівня за розміром опрацьованих даних чи кількістю транзакцій.



День К — 7 червня 2014 року — перший публічний реліз Kubernetes. Чорний день в історії Docker Swarm. Починається ера клауд-контейнерів, коли на зміну традиційним віртуальним машинам для розгортання еплікейшенів приходять контейнери. Провайдери дуже швидко випускають свої managed-рішення для розгортання Kubernetes-кластерів і керування ними. З’являються ті покоління клаудів, якими ми активно користуємося тепер.



Cloud 2.5 — оркестратори для контейнерів розвиваються дуже активно як відповідь на встановлення глобального тренду на перехід на мікросервісну архітектуру в побудові еплікейшенів. Виникають Containers as a Service, що дають змогу розгорнути комплексну продакшен-архітектуру в клауді лише за декілька годин або днів, на відміну від тижнів або місяців, потрібних раніше.



Cloud 3.0 — Functions as a Service (FaaS) — відповідь на наступний етап еволюції, коли мікросервіси стають такими дрібними, що кожен з них відповідає за конкретну функцію. Водночас кожна функція цілковито ізольована від іншої. Відповідно, еплікейшен розгортається як низка окремих функцій, кожну з яких можна прив’язати до іншої або до будь-якого івенту в системі чи інфраструктурі.



Як свого часу CaaS став відповіддю на появу мікросервісної архітектури, FaaS — відповідь на подальшу еволюцію цієї архітектури й появу функцій.

Як еволюція клаудів уже змінила DevOps

Коли ми мали у своєму розпорядженні лише сервери й навіть коли з’явилася віртуалізація, 80% часу DevOps-інженера йшло на розробку і автоматизацію і лише 20% — на процеси й конфігурацію платформи.

У Generation 3.0 більшість процесів уже автоматизовано. Усі інструменти, що з’являються, звільняють нас від технічної рутини, основне завдання — уміти правильно ними користуватися. Те, що раніше робила команда за місяць, тепер може виконати інженер самотужки за день. Для цього йому досить базових технічних знань без заглиблення в подробиці. Фокус змістився на налаштування процесів, конфігурацію платформи, в окремих випадках — мінімальну автоматизацію і ще рідше — потребу вручну дописати певний компонент платформи.

Відповідно, кардинально змінюються вимоги до DevOps-інженерів. Дедалі частіше глибокі технічні знання більше не дають конкурентну перевагу й не є ключем до успіху. Навіть якщо зіткнешся з певними обмеженнями платформи, то зможеш спланувати архітектуру так, щоб їх обійти. Тепер основне завдання — налагодити процеси, з’єднати між собою компоненти, і дуже рідко нам треба спускатися на рівень нижче, щоб щось підтюнувати.

Що відбувається тепер

Станом на 2019 рік клауди — це must-have для ентерпрайз-компаній. 85% з них уже використовують AWS чи планують перейти на них наступного року. Трохи менший відсоток покривають Azure, GCP. Крім цього, частка Serverless, Container as a Service за рік зросла на 40–50%. У наш час одна з трьох компаній активно використовує Serverless у продакшені, ще одна з трьох — Container as a Service. Machine learning, IoT також зростають, і за наступні 2-3 роки частка цих технологій збільшиться удвічі-утричі.

За даними State of the Cloud Report 2019

Що далі

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

Service mesh

Service mesh дасть змогу ефективно керувати глобальними розподіленими мікросервісними (global distributed microservices) рішеннями на базі Kubernetes-платформи, які продовжать стрімко розвиватися в найближчі роки. За даними досліджень Gartner і IDC, 2020 року всі компанії, які застосовують глобальну мікросервісну архітектуру в продакшені, використовуватимуть Service mesh. Час покаже, які конкретні інструменти виграють. Тепер лідирує Istio, другий за популярністю — Linkerd, але це ще може змінитися з виходом на ринок продуктів від таких гігантів, як HashiCorp, Red Hat і VMware.

Гібридні мультиклауди й Distributed clouds

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

Багато ентерпрайзів розглядають застосування кількох клаудів — не лише AWS, але також Azure, GCP та інших, наприклад, Alibaba Cloud, який так само швидко розвивається в Азії, як і AWS в Північній Америці. Подробиці можна знайти в цій статті.

Проте неефективно мати 5 різних команд, інструментів, процесів і підходів, щоб розгортати той самий еплікейшен для різних клауд-середовищ. Тому ентерпрайз-компанії звертають дедалі більше уваги на платформи, які уніфікували б керування ними й надавали б інженерам один user experience. Тому стрімко розвиваються такі платформи, як Pivotal та OpenShift. Найближчим часом ця тенденція не лише збережеться, а й посилиться.

Everything as a Service (XaaS)

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

Ця тенденція збережеться, і в найближчому майбутньому кількість платформ, якими треба буде керувати вручну, зменшиться до абсолютного мінімуму. Усе перетвориться на managed-сервіси. Спроститься інтеграція таких сервісів між собою. Зникне потреба в автоматизації та розгортанні в такому вигляді, як ми це виконували раніше. Custom development займатиме мінімальну частку нашого робочого лоуду.

Containers, Serverless, ML, IoT

До 2021 року Containers, Serverless подвоять свої показники. Це означає, що 3 з 4 компаній будуть їх використовувати. Використання ML, IoT зросте втричі. Відповідно, інженерам, які не хочуть утратити свою роботу за кілька років, варто це вивчати.

DataOps, MLOps, IoTOps

Основні ідеї DevOps-культури поширяться на інші компетенції. З цього виникають нові течії, як-от DataOps — уже тут, MLOps — починає зароджуватися й стабілізуватися, IoTOps — перебуває на хайпі, але на практиці до стабільного й стандартизованого використання дійдемо за кілька років. Докладніше про ці інструменти розповім трохи нижче.
Predictive CICD and engineering performance

Наприклад, якщо станеться помилка під час злиття коду, система автоматично сповіщатиме про неї та про причину, що її викликала. Тобто розробники більше не муситимуть витрачати час на те, щоб розібратися, чому щось не працює.

Здавалося б, Predictive CICD полегшить життя самим розробникам, але не DevOps-інженерам. Хоча насправді це win-win для нас усіх. Усунення людського фактора з написання коду, де зайва кома може порушити всю систему, — один з основних аспектів поліпшення загальної продуктивності проекту. І це значний крок уперед. Думаю, на це знадобиться років 3-4, оскільки з’являються нові й нові інструменти, що дають змогу краще збирати й обробляти дані, поліпшується ML, що врешті призведе до цілковитої автоматизації.

AIOps

У наступні кілька років зародиться нова течія AIOps, яка поєднає в собі функціонал big data й ML, щоб частково або цілковито звільнити інженерів від тих операційних завдань, які вони ще виконують. Ідеться про availability- й performance-моніторинг, кореляцію та аналіз івентів, менеджмент та автоматизацію ІТ-сервісів.​ Рішення щодо розширення або звуження інфраструктури, перерозгортання, перезавантаження сервісу, міграції платформа прийматиме вже автоматично, без участі інженерів.

Розглянемо на конкретному прикладі. До чого може призвести година простою Facebook, Instagram чи Netflix? До значних фінансових утрат, зниження ціни акцій, утрати лояльності користувачів. А це може статися навіть через найдрібнішу помилку. Але хоч би що призвело до несправності, інженер мусить здійснити роботу, щоб відшукати її причину, а потім ще витратити час, щоб її усунути. А якщо це трапляється вночі, то до цього додається й час на те, щоб він прокинувся й увімкнув комп’ютер. Рішення, що базуються на AI, усе це виконають за секунду.

DevOps майбутнього. Перспектива на 5+ років

Усі ті процеси й зміни, які ми розглянули вище, звучать так, ніби ми рубаємо гілку, на якій сидимо. Адже що залишиться мені, коли AI навчиться виконувати роботу за мене?

Так, традиційний DevOps у нинішньому розумінні поступово зникне. Але з’являтимуться нові зони відповідальності: треба буде оптимізувати процеси, піднятися на рівень вище AI і працювати більше як data scientist, ML-інженер, аналізувати дані.

Подібні зміни парадигми вже відбувалися під час переходу з Cloud 1.0 на Cloud 2.0, коли ми почали фокусуватися на оптимізації процесів. Наступна хвиля сталася, коли зникла потреба в ручній оптимізації.

Основним завданням DevOps-інженера стане зібрати всі елементи й об’єднати їх в оптимізовану систему, щоб забезпечити її максимально ефективну роботу. Це передбачає розуміння того, як розгорнути еплікейшен і платформу, побудувати процеси й об’єднати їх між собою так, щоб уникнути несправностей. А як ми можемо перевірити, що цей прогрес справді відбувається? Без вимірювань і конкретних цифр — ніяк. Відповідно, треба буде вимірювати, аналізувати й чітко розуміти всі процеси. Робота DevOps-інженера буде тісно пов’язана зі збором і аналізом інформації про роботу цілих платформ.

Ми вже починаємо це робити, і найближчим часом це ще активніше набиратиме обертів. Ті компанії, які нині працюють за старою схемою, коли є потреба власноруч писати багато коду, поступово також будуть переходити на нову модель. З приходом у клауд навіть тих вертикалей, які нині відстають (Healthcare і фінанси), потреба в розробці й використанні кастомних рішень для автоматизації зникає. Відповідно, залишаться процеси й конфігурація. А для тих, хто тепер попереду, додадуться ML та AI, які допоможуть їм працювати з даними, навчать їхні системи автоматично ухвалювати рішення на базі метрик і даних.

Передбачення на наступні 10 років від Enterprise: у 80% компаній традиційна ІТ-частина організації, до якої належить DevOps, зменшиться до мінімального рівня. Operations- і development-фахівці працюватимуть з платформами, даними, аналітикою. Людей у компанії, які будуть лізти в платформу, щось дописувати й підтюновувати, практично не залишиться.

До нас звертаються багато компаній, які на крок відстають від цих тенденцій, по допомогу в проходженні такої трансформації. Тобто дедалі більше компаній починають усвідомлювати, наскільки це важливо. Тих, хто перебуває на етапах Cloud 0 чи Cloud 1.0, ми переводимо одразу на Cloud 3.0. Відповідно, ривок уперед відбувається швидкими темпами.

Ті компанії, які ці етапи вже пройшли, звертаються з точковими запитами, наприклад допомогти їм налаштувати кост-менеджмент у клауді чи допомогти побудувати нову платформу на базі FaaS/XaaS.

Тобто ми розуміємо, що середовище буде змінюватися. Відповідно, тим, хто хоче успішно продовжувати кар’єру й мати змогу працювати на інноваційних проектах, варто починати адаптуватися до нових умов уже тепер.

Можу порадити читати профільні ресурси, зокрема DOU, стежити за аналітиками (Gartner, IDC, Forrester) і думати.

Похожие статьи:
В автоматизированном тестировании есть свои большие преимущества, они включают активные качества программного продукта,...
Сегодня компания Microsoft представила свои новые флагманские смартфоны, работающие под управлением операционной системы...
В выпуске: Lens — Kubernetes IDE, новые регионы в AWS (Африка), изменения в Grafana 7.0, TPUs в Google Cloud и новая книга в SRE. The Kubernetes IDE:...
В рамках Международного мобильного конгресса в Барселоне компании компании LG Electronics и Intel объявили о совместной...
А также: Google Assistant, Testing Support Library, доходность Google Play, генерация байкткода, MVVM, Lint rules, аналитика приложений, Realm...
Яндекс.Метрика