Друзья из Флант недавно попросили меня поделиться видением того, куда движется DevOps и индустрия, и что с ней станет лет через 10. После того как они опубликовали свою статью я понял, что хочу немного развернуть свои ответы.

Kubernetes

• Будет ли он ещё популярен через 5-10 лет?
• Какие технологии могут прийти ему на смену?
• Какие вызовы ему придётся решать?

Kubernetes никуда не исчезнет, он стал таким же стандартом, каким стал Docker для упаковки и передачи приложений. Пока что это стандарт на описание и композицию приложений и инфраструктуры. Но он сейчас достаточно быстро становится базой для стандартов, например, для комплаенса или интеграции с телеметрией, одним словом при помощи Kubernetes API уже значимое время описывают объекты, которые не всегда связаны с инфраструктурой напрямую:

Примеры:

• OpenSLO для описания SLO
• OAM для описания состава приложения
• Tekton для описания CI/CD
• Argo Workflows для описания DAG-ов
• Open Service Broker для описания сервисов наподобие SaaS

Все это описывается прямо в YAML прямо в Kubernetes.

Сейчас реализации этих стандартов не всегда удачные, но по мере развития подхода он станет понятен широкой общественности и будут появляться как новые онтологии объектов (читай – CRD), так и операторы, которые работают с этими стандартизированными CRD.

Появится еще больше Kubernetes Native софта, который изначально расчитан на запуск через Kubernetes API – в режиме оператора, и он добавит свой вклад в этот тренд.

“Классический devops-тулчейн” постепенно тоже будет мигрировать в сторону Kubernetes Native и начнет поставляться в виде операторов (это уже происходит, яркие примеры это Elasticsearch и Prometheus). Естественно, никто не помешает запустить контейнеры или бинарники с софтом вручную, только это станет все менее и менее поддерживаемым.

Что изменится в самом Kubernetes внутри – это реализации. Чаще начнут применяться легковесные реализации а ля k3s или minikube, которые применимы для маленьких локальных инсталляций или одноразовых операций (например, для бутстрапа “большого” кластара Kubernetes). Возможно Kubernetes APIs еще более явно разделятся на Core APIs, которые поддерживаются всеми всегда и везде с сохранением обратной совместимости, и расширения, которые будут добавляться в те или иные реализации Kubernetes прямо через встраивание в основные бинари, либо через CRD.

Сам “большой” Kubernetes возможно останется, возможно преобразится во что-то другое, но это не важно: к примеру, уже давно именем Docker мы называем как собственно Docker, так и containerd, да и не всегда различаем его с podman и CRI. То же самое будет с Kubernetes – появятся форки, модификации, инсталляторы и сборки типовых компонентов, типа Openshift или Rancher, совместимые с ванильным Kubernetes по большинству функциональности, но каждый из них будет притаскивать какие-то свои функции.

И все это так и будет называться Kubernetes.

DevOps

• Будет ли ещё DevOps через 5-10 лет?
• Как изменится его понимание?
• Как изменится культурный аспект, стоящий за DevOps-практиками?
• Как могут измениться сами практики?

В начале 2010х DevOps решал ровно одну задачу: как в кроссфункциональные аджайл-команды включить и Operations. Задача давно решена, собственные ops/devops в командах разработки это данность, и весь мир уже лет 5 пытается переизобрести DevOps, найти ему новую проблему, которую он бы решил.

Но решение проблемы кроссфункциональных команд совершенно логичным образом вывело нас в задачи следующего уровня: какие вообще нам команды нужны в организации, какие информационные системы они будут разрабатывать и поддерживать, кто за что в этом будет отвечать, и как при этом сохранить гибкость кроссфункциональных команд и не свалиться обратно в бюрократию.

Этими задачами традиционно занимается архитектура (корпоративная и технологическая) и delivery, но до недавнего времени по тем или иным причином они обращали мало внимания на аспект инфраструктуры и его интеграцию в процессы разработки.

Задачи вокруг которых возникло движение DevOps сейчас попали в их сферу внимания и постепенно они закрепятся и в сфере их ответственности. Все системы, которыми сейчас занимаются devops-инженеры/платформенные команды и т.д. встанут в один ряд с функциональными системами решающими “классические” бизнес-задачи. Платформенные команды и “команды devops” станут точно такими же “обычными” командами разработки, только с фокусом на инфраструктурные сервисы.

С другой стороны, практики ассоциированные с DevOps и SRE начали активно применяться в развертывании корпоративного ПО (типа почтовых серверов и рабочих станций) и в ITSM, a практики ITSM начали применяться в DevOps и платформенной инженерии. Здесь скорее всего произойдет их сращение в виде многочисленных взаимных заимствований. Словом ITSM все так же будут называть преимущественно ручные процессы сопровождения вокруг “классического” ИТ, а каким-то словом из облака терминов вокруг DevOps – преимущественно автоматизированные, вокруг разработки новых систем, но их основа станет более близкой друг к другу.

Ops’ы:

• Какие интересные, необычные Ops’ы могут появиться через 5-10 лет?
• Какие задачи они будут решать?

Вопрос не совсем корректен. Технически “devops-инженер” – это “IaC-разработчик” или “инфраструктурный разработчик”, и это уже давно является отдельной ролью в команде разработки (вместе, например, с дата-саентистом и дизайнером).

Разнообразные DataOps, MLOps и т.п. это не роль, а указание на “тип разрабатываемого приложения”. Чтобы это пояснить, приведу пример с фронтендом: фронтендщиков уже некоторое время разделяют на условных “ангулярщиков” и “реактщиков”, но от этого они не перестают быть “фронтендщиками”, это подклассы одного класса. У них возникают специализации связанные, например, с разработкой под Electron, под мобильные устройства и т.д., но в общественном сознании они остаются “фронтендерами”.

То же самое и с инфраструктурной компетенцией. В любой команде будут представители инфраструктурной компетенции, но в зависимости от того, что именно разрабатывается командой, это могут быть devops-инженеры со специализацией “data”, или devops-инженеры со специализацией “cloud”, или devops-инженеры с другими специализациями. Специализации могут появиться и новые, но общий термин останется один – “devops-инженер”.

При этом как я уже упомянул в ответе на предыдущий вопрос, организация самих процессов в соответствующей области – это задача архитектурной и проектной функции, а не *Ops, и эта задача все больше и больше будет уходить от *Ops к этим функциям.

Cloud Native-экосистема, программы внутри неё

• Что станет с этой экосистемой?
• Какие проблемы она должна будет научиться решать через 5-10 лет?
• Какие новые программы могут появиться в этой экосистеме?
• Что станет с облаками? Как они изменятся?
• Придёт ли какая-то другая технология на смену облакам, и если да, то какой примерно она будет?

Cloud native это в первую очередь архитектурный паттерн, применение которого уже создает вокруг себя экосистему. Паттерн есть и никуда не денется (так же как никуда не исчезли, например, SOA и ESB при всех их проблемах, только они заняли вполне определенную узкую нишу).

Если же взглянуть на тренды вокруг Cloud Native:

• С одной стороны это превращение его в Cloud Bound, т.к. это направление наиболее выгодно для облаков, и наиболее удобно для клиентов (если те готовы принять риск vendor lock). Для примера можно взять условный AWS Athena или Yandex Dataproc и сэкономить несколько человекомесяцев (а то и человеколет) по сравнению с самостоятельной интеграцией стандартных компонентов в аналогичный сервис. Облака продолжат дальше выпускать новые проприетарные сервисы удобные клиентам, которые будут соседствовать со “стандартными” сервисами IaaS и PaaS типа compute, сетей и kubernetes.

• С другой стороны появилась обратная тенденция к возвращению к централизованным архитектурам – “модульным монолитам”. Наработки в этой области не сильно скажутся собственно на Cloud Native, т.к. он дополняют друг друга. Но это направление может дать толчок развития практикам Observability и в частности сервисам мониторинга, логирования и трассировки.

• С третьей стороны, практики и технологии присущие Cloud Native проникают в другие архитектуры, при этом преображаются довольно сильно. К примеру, уже появилась и развивается его ветвь Kubernetes-native, про которую я упомянул в начале статьи, которая будет все больше и больше отличаться от Cloud Native. Это продолжится и дальше с учетом сказанного выше о том, как изменится роль devops-инженеров.

Выводы

Термин “devops-инженер” закрепится, ни у кого не будет мыслей ставить его под вопрос. Сам термин “Devops” станет таким же плохо оформленным жаргоном как и “Agile”. Предмет работы “devops-инженеров” еще больше сместится из “автоматизации серверного администрирования и пайплайнов” в сторону разработки и архитектуры. В части инструментария продолжится движение в сторону облачных сервисов и Kubernetes. Индустрия развивается, мода меняется, жизнь прекрасна и удивительна.