×

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) і думати.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному5
LinkedIn



23 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Спасибі, Олександре. Дуже цікава стаття.

Сейчас довольно много компаний в том числе переходят на AWS ECS (Fargate), поэтому не K8s единым.

Из статьи я понял, что хайпотрейн уходит, клиенты умнеют и софтсерву все сложнее впаривать сисадминов по тройному прайсу клиентам. Поэтому приходится наслаивать дополнительные ML, AI, IoT и прочая.

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

Все досить логічно і натурально розвивається.
Десь далі так і виглядає, що будем слідкувати за новими клауд агностік тулами (ну бо тоді клауди почнуть конкурувати за юзерів- дешевшати, ну і плюс фантастичний випадок блекауту регіону)
Ну і певне якщо про АІ все як думаєм то логи воно само грепне, очевидно прийдеться щось типу го чи пітона знати.
Ми все далі від кернел панік і все ближче до коду.

Називати девопс (процес) інженером все ще дивно на порозі 2020...

А девопс це процесс?)

Ого... Написав пост про DevOps i не знав, шо це процес. Пацани ващє рєбята, умєєтє, магьотє.

Сорян, забанили в гуглі, інфу шукав через Baidu.
Так що там зараз кажуть за ДевОпс в нормальних інтернетах?

Важко погодитись з вашими висновками.

Візьміть приклад з розробки ... колись був IDE з Borland Pascal, зараз є JetBrains. Чи вплинув цей перехід на розробку? Очевидно, що так і досить суттєво. Чи змінило це сутність роботи? Думаю, що не дуже.

З «DevOps» переїзд між голий linux->віртуалки->докер по суті спрощує та пришвидшує деякі процеси, але, знову ж, на скільки принципово?

Щодо cloud ...
1. Сервіси як такі — далеко не новинка: mail, dns, sms gateways існували вже дуже давно як сервіси. Зараз їх асортимент, просто, розширився.

2. Хмарні сервіси не стандартизовані. Відповідно, їх використання — це вже vendor lock in. Особливо це важливо, якщо використовувати специфічні фічі.

3. Часто, є зручним розмістити щось там на VPS. Але як тільки появляється яке не яке навантаження, одразу чомусь вигіднішим стає взяти в оренду виділений залізний сервер.

4. Є фічі, які cloud провайдери дозволять робити значно легше і краще, ніж самостійно: cdn, масштабування, частково бекапи. Але, знову ж, це дорого під навантаженням. І можна прийти до думки, що простіше взяти по серверу на кожному континенті в оренду.

5... В хмарних рішеннях, звісно, є сенс для деяких задач. Але із-за 1-4 я не розумію хайпу навколо цього. Що б там не було, але точно не про «дешево» та не про оптимізацію витрат.

І у вас є своя правда. В цій статті, мої висновки опираються на досвід роботи з великим ентерпрайсами та інтервью, що ми робили цього року серед С-левелів компаній з прибутком більше одного мільярда. Ось декілька основних меседжів:
— До 2025 року скоротити витрати на штат IT до 10% від того что є зараз, і в 3 рази знизити операційні затрати пов’язані з обслуговуванням та підтримкою інфраструктури.
— Реальні затрати для бізнесу на «vendor agnostic» солюшени дуже великі, і в тей же час всі шукають платформу, що зможе поєднати під один дах всі існуючі хмарні та онпрем ресурси компаннії. Тим самим бути «vendor locked» на платформу, що зробить їх infrastructure agnostic і дасть уніфікований експіріенс і процесси для решти.
— 80+% йдуть або вже в клаудi, і причому відразу в декількох.
І можливо, це не те що торкнеться всього бізнесу в наступні роки, але ігнорувати такі тренди точно не можна.

Ну ... з компаніями з міль’ярдними прибутками в мене досвіду роботи немає, тому ви можете бачити все з іншого боку.

1. Поділити на 10 ІТшників та поділити на три залізо — то серйозна заява. Це схоже на не-ІТ компанії з софтом з 90х, які не можуть вилізти з зоопарку софта, технологій та старих рішень.

2. Якщо я вірно зрозумів вашу тезу, то шукають те, чого немає: стандартизованого cloud.

3. Виктристовувати cloud це часто корисно. Особливо в допоміжних сервісах. Але щоб в усьому... хз.

Могли б ви з досвіду назвати 2-3 use case-а, коли перехід в cloud був би виправданий, за умови, що за альтернативу взяти редизайн системи на власних потужностях? (Якщо не рахувати речі типу SaaS як crm, ту ж пошту, трекери задач, office 365, тощо ... особливо, якщо бізнес не ITшний)

Не оч реально кажется уменьшить в 10 раз затраты на IT департамент за 5 лет. Ктото же должен код писать. И просто из любопытства, интересно куда этот клиент планирует перенаправить сэкономленные 90% костов?

По нашим даним,якщо будівництво не на*бнеться зараз—воно обов’язково на*бнеться в наступному кварталі ©

Я ще люблю тему «Девопс Помер! Хай живе Девопс».
Кожного кварталу можно випускати XDD

"

Тепер перемагають ті, хто 5 років тому поставив на Kubernetes, а не на Docker Swarm

" — це просто означає, що автору на Софтсерв не залітали великі проекти базовані на Swarm :)

А якщо глянути на це прагматично? Успіх тої чи іншої технології можна виміряти в тому, скільки заплатять за експертизу в ній. І порівняння це зараз не в сторону Docker Swarm. Ресурси які аналізують середню зарплатню (наприклад www.payscale.com) кажуть, що 5 років в кубернетесі, в середньому, дасть +20к зелені в рік більше ніж докер.
Та в кінці кінців, все буде залежити від того, як саме Ви продасте цю експертизу ;)

Успіх тої чи іншої технології можна виміряти в тому, скільки заплатять за експертизу в ній

www.ziprecruiter.com/...​s/Cobol-Programmer-Salary vs www.ziprecruiter.com/...​/dotnet-Programmer-Salary — хлопи в 1960 якомусь році зробили правильний довготерміновий вибір, хе хе :)))

З того, що було на той момент — так, правильний

Великі проекти на Docker Swarm — погане архітектурне рішення

Процитую з вашого сайту : 12. Rational decision making #
There are a huge number of tools to solve each individual problem, and you need to choose the right tool for the job as correctly as possible and not chase the fashion trends that are constantly appearing.

Ви не знаєте про потенційний проект нічого — ні задачу, яку має вирішити бізнес, ні як довго це рішення має працювати, ні часові, ресурсні, або бюджетні обмеження, але:

Oleg Mykolaichenko DevOps Engineer:
Великі проекти на Docker Swarm — погане архітектурне рішення

Згоден з Вами, з точки зору великого сферичного коня у вакуумі — без сумніву. :)

7 червня 2014 року — перший публічний реліз Kubernetes. Чорний день в історії Docker Swarm. Починається ера клауд-контейнерів, коли на зміну традиційним віртуальним машинам для розгортання еплікейшенів приходять контейнери.
December 25, 2018
The future of Kubernetes is Virtual Machines

tech.paulcz.net/...​etes-is-virtual-machines

Redhat вже підтримує віртуальні машини в кубернетесі через kubevirt на більшості on-premise і хмарних кластерах. Працює :)

Коментар порушує правила спільноти і видалений модераторами.

Дякую за статтю, в цілому з усім згідний. Усе гарно розкладено по полицях.

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

Підписатись на коментарі