Михаил Селиверстов: Post-DevOps?

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

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

Сегодня хочется обсудить вопрос цифровизации DevOps-инженеров. Профессия DevOps-инженера крайне востребована на рынке труда, актуальна и интересна специалистам смежных специальностей.

Термин DevOps — это комбинация слов «разработка» (development) и «эксплуатация» (operations), которая отражает процесс интеграции этих дисциплин в единый непрерывный процесс. На самом деле, DevOps — это не название профессии. Это культура, методика, цельный подход к решению проблем, движение, если угодно. Это движение возникло в 2008 году и было призвано решить накопившиеся проблемы, но со временем в новом движении возникли новые проблемы.
Post-DevOps — это новая парадигма разработки, тестирования и эксплуатации информационных систем и облачных приложений. Post-DevOps описывает уровень зрелости, при котором достигается гибкость, превосходящая традиционный DevOps благодаря тому, что команда разработчиков платформы предоставляет самообслуживающуюся, автоматизируемую платформу, которая позволяет командам разработчиков приложений выполнять все операционные действия.

Квалифицированные специалисты стоят дорого, а их переход из компании в компанию доставляет немало хлопот работодателям и HRD. Именно дефицит DevOps-инженеров, создает высокий спрос на автоматизацию, и предложения не заставляют себя долго ждать. Не так давно российская компания «Эквирон» вывела на рынок продукт Imagenarium, который позиционируется как Post-DevOps-решение и нацелено на полную цифровизацию DevOps. Продукт появился более пяти лет назад, за плечами у разработчиков интересные и достаточно масштабные внедрения, т. е. это состоявшееся решение, на которое как минимум стоит обратить внимание. Решение недорогое, позволяет компаниям обходиться без DevOps-инженеров, что доказано практикой. Не сократить, не упростить или автоматизировать их рутину, а именно полностью оцифровать. Это основное отличие Imagenarium от других контейнерных платформ на рынке: первый замещает DevOps-инженеров, а вторые только упрощают или автоматизируют работу этих специалистов. В конце января в журнале IT-Expert была опубликована статья «Платформа Imagenarium: вся инфраструктура как код — в одном контейнере», в которой можно подробнее ознакомиться с работой Post-DevOps–платформы Imagenarium.

Любой руководитель, отвечающий за сложную инфраструктуру, может легко прикинуть в уме примерную экономию времени и затрат.

В чем подвох? Это мы решили узнать у разработчика решения, у генерального директора компании «Эквирон» Михаила Селиверстова.

Ваше решение уже довольно зрелое, но о нем мало что известно?

Imagenarium был разработан в 2017 году. Мы разработали этот инструмент и сами им пользуемся. В течение 15 лет работая на сложных и масштабных проектах нам пришлось создать несколько собственных решений, и Imagenarium одно из них. Как правило, его внедряли там, где мы сами были разработчиками решений, и масштаб внедрения был достойным. Заказчики просто не могли устоять, видя, как он работает, правда.

Что именно послужило поводом для создания продукта?

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

И это возможно?

С Imagenarium — да, с Kubernetes — нет. Также нам было важно, чтобы у разработчика была возможность осуществлять отладку своего кода, например микросервиса, куда он вносит изменения в контексте системы, запущенной у него на ноутбуке или на сервере. Система запущена, Imagenarium подключает к ней экземпляр сервиса, который разработчик запустил в своей IDE. Это очень удобно.

Разработчик может самостоятельно осуществить развертывание сложной системы на доступном ресурсе? Даже на ноутбуке?

Именно для этого мы и создали Imagenarium. Один инструмент для всей команды, от разработки до эксплуатации. QA-инженеры также могут без проблем развернуть систему на доступных им ресурсах, благодаря API Imagenarium они включают его в свои сценарии автоматизации тестирования, никаких специальных знаний не нужно: API очень простой.

А каким образом Imagenarium ускоряет разработку?

Разработчик получает возможность отладить свой код в контексте решения на доступном ресурсе. Таким образом он сдает сборку, будучи уверенным в том, что не разнес ничего глобально. Он переходит к следующей задаче, и шанс, что код вернется к нему на доработку, крайне мал. Для страховки он просит QA задеплоить его сборку куда-нибудь на тестовый стенд и быстро прогнать тесты. QA делает это, фактически не отвлекаясь от своих текущих задач, и дает добро на включение ветки разработчика в общую. Оба потратили 20 минут, а не часы или дни, ожидая пока DevOps-инженеры развернут код или приложение на сервере и дадут возможность провести тесты.

А откуда QA возьмет эту нужную ветку?

В Imagenarium реализован подход инфраструктура-как-код (IaC), а для хранения этой информации мы используем обычный GIT.

Инфраструктура в GIT?

Да, очень удобно. Это решение используется повсеместно.

А что представляет собой эта инфраструктура как код?

Шаблоны развертывания для системного ПО, для сервисов разрабатываемой системы, собственно, сам код, написанный разработчиками.

А где хранится само системное ПО?

В реестре докер-образов контейнеров. Оттуда и берется во время запуска процесса деплоя.

И что нужно, чтобы его запустить?

Нажать одну кнопку.

И все?

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

Значит Imagenarium делает все то, что делают другие платформы, построенные на базе Kubernetes?

Совершенно, верно, но в своем масштабе, и он невероятно прост в обращении, повторю, он помещается в одном контейнере. Для сравнения: платформы на Kubernetes — это, как правило, несколько open source-решений, склеенных скриптами с общим UI, плюс высококвалифицированный и дорогостоящий обслуживающий персонал. Учитывая все перечисленное, мы и отказались от Kubernetes. У нас всегда был десяток проектов в разработке, множество окружений, активная жизнь, а работали над проектами далеко не гигантские коллективы. Требовалась эффективность.

Но вы работали с Kubernetes?

Конечно. Мы побывали на ряде конференций и презентаций Kubernetes-платформ и сделали для себя вывод… Не хочу никого обидеть, но изрядный процент хайпа вокруг таких решений создается их евангелистами, а их сложно назвать бескорыстными людьми. Формируя стандарты на рынке, практически безапелляционно заявляя, что единственная правильная технология — это Kubernetes, люди формируют рынок — как рынок специалистов, так и рынок для своих решений, — а потом пожинают плоды. Лет десять назад это было как гипноз. Собирали представителей энтерпрайза и зомбировали, подобно продавцам травяных чаев из девяностых, утрирую конечно, но работали люди действительно профессионально. Логотипы крупного бизнеса, истории успеха, потрясающие кейсы — все это сработало.

Вас тоже сложно назвать бескорыстными, продукт ведь не бесплатный.

Тут вы не совсем правы. Мы предлагаем решение, которое в разы снизит затраты на эксплуатацию, серьезно — на разработку и сократит time-to-market. Да, Imagenarium стоит денег, но он сэкономит вам деньги, причем очень существенные, если взять ваши текущие бюджеты, добавить налоги. Посчитайте сами! Так что, мы предлагаем сотрудничество, протягивая, без пафоса говорю, руку помощи.

Но все же не может быть так, что все ошибаются, а вы одни правы? По-вашему, Kubernetes — это какой-то монстр.

Нет, конечно, даже близко нет такого мнения о таком достойном и полезном продукте. Я хочу сказать, что всему свое место. Нам он не подошел, причины я назвал. Очень дорого и с излишней сложностью. Ну не нужно нашим заказчикам решение, которое, по сути, можно развернуть только на тысяче серверов. Если у вас их десяток-другой, зачем он вам? Что вы хотите получить от тех действительно крутых возможностей, которые он дает? Вот мы делаем в Imagenarium совершенно то же самое, конечно, до определенного масштаба.

Там, где кончаются возможности Imagenarium, подходит очередь Kubernetes?

Да, именно так! Традиционно считается, что может быть либо очень просто, например Docker Compose, либо необходимо сложное решение на базе Kubernetes. И это неправда. Imagenarium заполняет ту нишу, которая образуется посередине. Мы делаем очень сложные процессы крайне простыми. Есть ниши, в которых работают продукты разного масштаба. И Imagenarium совсем не «таблетка от всех болезней» и от всех проблем. У нас есть предел, но он позволяет использовать наше решение как минимум в 70% серьезных проектов.

Наверняка есть какой-то функционал, которого нет в Imagenarium, но который критичен для тех, кто эксплуатирует Kubernetes-платформы.

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

Становитесь популярными?

Пока еще не так, как нам хотелось бы, но мы работаем над этим. Вопрос оптимизации, экономии, эффективности сейчас важен для бизнеса. И импортозамещение тоже не последнее слово в настоящий момент. У нас же все-таки полностью российский продукт.

Насколько я знаю, есть российские Kubernetes-платформы.

Да, конечно. Но под капотом у них десяток open-source-продуктов, каждый из которых может изменить свою лицензионную политику в отношении России. Знаете, чем это может закончиться? Вот Terraform, например, одно из самых популярных IaC-решений для Kubernetes, официально как бы не работает в России и Беларуси. Если и другие популярные компоненты этих платформ сделают то же самое? Что это повлечет за собой?

Если честно, даже не хочу представлять.

Я тоже. Мы российский вендор, у нас отечественный продукт и это огромный плюс. Если заказчику чего-то не хватает, мы это сделаем, и быстро. Потому что продукт наш. Гибкость у нас невероятная. Отказоустойчивое хранилище у нас появилось в течение нескольких месяцев, сейчас мы завершаем разработку LDAP-модуля, а в планах уже стоит модуль резервного копирования. У нас хорошая производительность, поэтому мы будем популярны.

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