Рулевой в океане контейнеров

Слушайте выпуск на подкаст-площадках

Сергей Зинкевич. Александр, каково быть генеральным директором такой технологичной компании, как «Флант», и как ты к этому пришел?

Александр Баталов. Быть генеральным директором такой современной и технологичной компании, как «Флант», безумно ответственно и интересно, и последнее, скорее всего, стало решающим фактором. Я начинал карьеру как веб-разработчик, причем в большей степени работал во frontend-разработке. Однажды я понял, что у меня хорошо получается работать с людьми, заниматься управлением проектами и взаимодействовать с заказчиками. Постепенно я стал тимлидом, а потом продакт-менеджером. В какой-то момент основатель «Фланта», с которым мы были знакомы с юношества, предложил оставить самостоятельную деятельность и начать делать серьезные вещи в серьезной компании с большим будущим. Я подумал, что это может быть очень интересно, учитывая, как быстро развивалась компания. Я очень любопытный человек, а что, как не должность генерального директора, может помочь удовлетворить любопытство.

Сергей Зинкевич. Получается, что генеральным директором стать пришлось?

Александр Баталов. Отчасти да, но не без удовольствия.

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

Как за последние три года изменились запросы, которые получает «Флант»? Мне кажется, что изменились, потому что у заказчиков значительно выросли компетенции. Мы получаем не общие, а очень глубокие вопросы по сопровождению Kubernetes.

Александр Баталов. Эта технология действительно уверенно закрепилась и в России, и в мире. Три года назад Kubernetes занимались условно хипстеры — ребята из технологических стартапов, амбициозные и инициативные, как правило, небольшие команды, которые успели «въехать» в технологию и поверили в нее. На сегодняшний день и крупные компании с серьезными задачами, большим бюджетом и высокой ответственностью уже оценили возможности Kubernetes и внедряют технологию в бизнес. Очевидно, что задачи крупных компаний сложнее и значительнее, а сами компании более требовательны к отказоустойчивости, надежности и безопасности. Соответственно, растет не только технологическая экспертиза команд, которые реализуют такие проекты, но и уровень запросов.

Александр Фикс. Популярность Kubernetes у заказчиков КРОК Облачные сервисы растет. Действительно, технологией пользуются не только небольшие технологические стартапы, но и крупные компании. Последние, как правило, обращаются к нам за помощью в администрировании и поддержке, а через год-полтора выращивают свою команду и начинают самостоятельно развивать кластеры и платформы. Экспертиза растет, поскольку компании видят ценность Kubernetes и необходимость улучшать собственные компетенции.

Сергей Зинкевич. Один из самых часто задаваемых вопросов: что выгоднее — использовать готовые контейнерные платформы или все собирать из кубиков с нуля?

Александр Баталов. Вектор развития platform engineering вполне определился. Это объясняется тем, что в контейнерах запускаются очень серьезные системы. Для большинства компаний ИТ — это инструмент масштабирования, повышения надежности бизнеса и отчасти оптимизации затрат. Если вы используете Kubernetes как инструмент, то можете сфокусироваться на специфичной для вашего бизнеса задаче. Платформа — это commodity. Не обязательно изобретать велосипед, если до вас этот велосипед не только изобрели, но и настроили, оформили best practice, решили архитектурные задачи и все проверили на очень широком спектре проектов. Разумеется, если вы не являетесь технологическим гигантом, намного выгоднее заимствовать такой опыт и пользоваться уже наработанными решениями от надежных вендоров.

Александр Фикс. Есть какой-то минимальный порог, достигнув которого можно переходить к платформе, а до него проще использовать кластеры Kubernetes без платформы? Например, в какой момент технологическому стартапу, развивающему свои продукты и использующему Kubernetes, стоит задуматься об использовании платформы?

Александр Баталов. Задуматься стоит до момента написания первой строчки кода, вне зависимости от размера компании. Если этого не сделать, вы рискуете отвлечься от решения бизнес-задач и потеряете время, наращивая экспертизу, которая не приносит добавленной ценности вашему продукту и вашему бизнесу. Если вы делаете современный софт и работаете в микросервисной архитектуре, лучше минимально отвлекаться на ИТ-инфраструктуру. Разработчик должен думать про алгоритмы и описание бизнес-логики, а максимально комфортную инфраструктуру получать как сервис.

Сергей Зинкевич. Облачные провайдеры, и мы в том числе, предлагают Kubernetes как платформенный сервис. Есть ли на него спрос или все предпочитают пользоваться готовыми вендорскими продуктами, такими как Deckhouse от «Фланта»?

Александр Фикс. Спрос есть. Если клиент использует тестовые среды, находится на начальном этапе перехода от монолита к микросервисной архитектуре или хочет просто попробовать Kubernetes, ему удобнее взять инструмент, встроенный в облачную платформу. Он сможет его протестировать, после чего принять решение об использовании вендорского продукта или облачного PaaS.

Сергей Зинкевич. На недавней профессиональной конференции помимо Deckhouse были представлены еще несколько контейнерных платформ, и, возможно, в два раза больше решений не участвовали в мероприятии. После того как корпоративная контейнерная платформа Red Hat OpenShift ушла из России почти 13 месяцев назад, образовалась огромная ниша. Как вы оцениваете такую конкуренцию и как планируете в ней побеждать?

Александр Баталов. «Флант» все и всегда делает исходя из оценки того, что востребовано на рынке сейчас и какие технологические стандарты будут востребованы в ближайшем будущем. Мне кажется, что у нас сильно развито технологическое визионерство.

Deckhouse уже 6 лет используется в продуктиве. Более 250 кластеров развернуты у наших клиентов, где мы берем на себя управление платформой. Но невозможно точно подсчитать, сколько кластеров работает на бесплатной версии Community Edition (CE) в закрытых окружениях компаний.

Deckhouse появился эволюционным путем и быстро стал зрелым продуктом. «Флант» был сервисной компанией, и наработанный опыт воплощался в автоматизации — мы постепенно автоматизировали один компонент за другим. Поначалу эти наработки использовались для наших внутренних задач. В период пандемии участились запросы от ритейлеров, которым потребовалось усилить онлайн-продажи, чтобы не потерять рынок. Мы, в свою очередь, поняли, что если останемся сервисной компанией и не сможем предложить продукт, который можно использовать в больших компаниях, то не решим проблему этих клиентов. В итоге мы собрали все свои наработки по автоматизации компонентов ИТ-инфрастуктуры. Так и родился Deckhouse.

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

Александр Фикс. Как вы планировали бороться за место на рынке, если бы зарубежные вендоры таких решений, как Red Hat OpenShift, не ушли?

Александр Баталов. У нас неплохо получалось конкурировать с этими продуктами. Deckhouse — это не копия и не аналог OpenShift, а альтернатива. В платформе заложены архитектурные решения, проверенные нашей практикой сопровождения систем в режиме 24/7. Мы всегда были клиентоориентированными, а наша техническая поддержка оперативно и компетентно обрабатывала запросы клиентов не только в отношении продукта, но и по поводу интеграции и обучения персонала. Это играло важную роль, потому что был период, когда клиентам не хватало компетенций и обучение сотрудников было очень востребовано.

У Deckhouse были конкурентные преимущества. Возможно, если бы конкуренты не ушли, спрос рос медленнее, однако мы вне всяких сомнений заняли бы свой сегмент рынка.

Сергей Зинкевич. Что на практике дает использование Kubernetes? Как понять, что Kubernetes сделал мою жизнь лучше?

Александр Баталов. Любой современный бизнес работает эффективно, если используются ИТ и если цифровизация пронизывает все бизнес-процессы. А это влечет за собой рост объема разработки и количества запускаемых приложений, которые необходимо оперативно обновлять, проверять гипотезы, эксплуатировать и т. д. Если заниматься всем этим в рамках классических моделей, это превращается в неуправляемый ком, который, во-первых, ухудшает качество работы бизнеса, а во-вторых, по объективным причинам очень сильно портит взаимоотношения между командами разработки, командами эксплуатации и т. д. За всем сразу просто невозможно уследить, если вовремя не сделать шаг к цифровой трансформации.

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

Сергей Зинкевич. Наши заказчики часто думают, что Kubernetes не нужно поддерживать. Достаточно просто настроить инфраструктуру, чтобы все работало само по себе.

Александр Фикс. Мы видим, что заказчики, которые правильно с точки зрения архитектуры подходят к выстраиванию контура и настраивают систему мониторинга (что важно как для монолитного сервиса, так и для микросервисной архитектуры), используют Kubernetes без проблем и выпускают десятки релизов в сутки.

Сергей Зинкевич. Получается, что заказчики, которым внедрили инфраструктуру с Kubernetes и продали поддержку, могут со временем настаивать на снижении тарифа, если у них «все и так стабильно работает»?

Александр Фикс. Обычно компании не останавливаются на одном или нескольких кластерах. Объем задач постоянно растет, в результате чего усложняются и кластеры. Без поддержки со стороны партнера с этой ситуацией будет трудно справиться — придется развивать собственные компетенции, что тяжело, дорого и сбивает фокус с развития конечного продукта на инфраструктуру.

Александр Баталов. Многие команды вкладываются в собственное развитие. Однако мы видим разные примеры, поскольку все в конечном итоге упирается в деньги.

Разумеется, можно сделать собственную платформу на базе Kubernetes. Вопрос в том, какое время на это уйдет, сколько будет стоить и насколько гарантирован результат. Работающую систему можно собрать, только если есть богатый и разнообразный опыт эксплуатации. Поэтому крупным компаниям с огромным штатом инженеров удается создать неплохие решения, а для небольших команд это невыполнимая задача. У нас были заказчики, которые пришли к нам, потратив 2 года на разработку собственной платформы. Она перестала работать после увеличения нагрузки, а обновление Kubernetes не удалось из-за «кривой» сборки. Сделать действительно управляемую систему, которую не страшно запускать в продуктив, очень тяжело и дорого.

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

Александр Фикс. Компания может самостоятельно заниматься поддержкой и администрированием, однако при этом ИТ-директор должен взять на себя ответственность за любые проблемы, например, за простои, связанные с ошибками администрирования. Если же компания обращается к вендору платформы или к партнеру (например, КРОК Облачные сервисы), такая ответственность определяется SLA вендора или партнера.

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

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

Сергей Зинкевич. В какой момент компании становится неудобно собирать все из кубиков и стоит воспользоваться готовой платформой?

Александр Баталов. Вопрос заключается в том, ради чего вы это делаете. Если вы хотите попробовать свой технологический потенциал и понимаете, что результат разработки на dev-контуре не влияет на бизнес, то можете заниматься разработкой в свое удовольствие. Если на кону стоят деньги, репутация, развитие и масштабирование бизнеса, вам одновременно потребуется и мониторинг, и обновление, и администрирование, и безопасность, и множество других компонентов и направлений, которые необходимо учитывать и понимать, как они взаимодействуют между собой. Как только вы осознаете, что ваша система должна работать на результат, стоит искать надежную платформу, которая облегчит вам жизнь.

Сергей Зинкевич. Это типовой аутсорсинг: если необходимо расширять свои компетенции, приходится аутсорсить либо людей, либо готовые продукты.

Александр Баталов. Возьмем к примеру системы виртуализации. На российском рынке есть свои решения. Был, например, OpenStack, и ни у кого не возникала мысль сделать свой OpenStack с нуля, тогда как примеров, когда компании «допиливали» OpenStack и развивали его до платформы, достаточно много.

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

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

В КРОК Облачные сервисы направление по сопровождению инфраструктуры Kubernetes в 2022 году выросло на 140% по сравнению с 2021 годом. Эти сервисы пользуются большим спросом.

Сергей Зинкевич. «Флант» был сервисной компанией, затем вы разработали свою платформу и стали вендором. Как сервисная компания решилась пойти по пути вендора, учитывая плюсы и минусы этих двух вариантов?

Александр Баталов. Все случилось естественным путем. Триггером стал ковид. До этого «Флант» был аутсорсером для компаний малого и среднего бизнеса и помогал командам, у которых не было своих компетенций или ресурсов, получить все необходимое под ключ.

Когда к нам пришли с запросом крупные компании, стало очевидно, что аутсорс для них невозможен. Удовлетворить спрос «живой силой» мы также не могли, поскольку, например, в команде «Леруа Мерлен» сотни разработчиков, а у нас 50-70 инженеров. Единственное, чем мы могли им помочь, это экспертиза, наработанные решения и методология, которую внутренняя платформенная команда может перенять и на ее основе в своих закрытых окружениях создавать экосистему.

Хочу обратить внимание на один момент. Многие крупные компании не могут использовать облако для всех решений, однако есть целый пул сервисов, где это возможно, особенно в случае плавающей нагрузки. Использование Kubernetes дает возможность выстроить тесную интеграцию между собственной инфраструктурой и облаком. Мы предлагаем возможность расшириться буквально в один клик. Сегодня вы работаете в своем закрытом контуре, завтра у вас промоакция, нагрузка растет, и вы можете расшириться, например, в Облако КРОК по клику.

Можно ли говорить о каком-либо стандартном пакете возможностей — Kubernetes, СУБД, инструменты работы с контентом и т. п., который необходим для работы? Есть ли минимальный набор технологий, необходимых, чтобы выйти на рынок облачных платформенных сервисов (PaaS)?

Александр Фикс. Есть базовый набор инструментов из облака, которые в настоящее время очень популярны и значительно облегчают жизнь нашим заказчикам.

Если говорить про PaaS, то начинать надо с СУБД и средств кэширования. Однако этого недостаточно, необходим также мониторинг и логирование, то есть стек ELK поверх PaaS. Кроме того, требуется возможность поддерживать сервисы незаметно для заказчика. Мне кажется, это тот минимальный набор компонентов, который необходим облачному провайдеру для предоставления PaaS.

Александр Баталов. Я бы также отметил синергию платформенных решений, таких как Deckhouse, и облаков. В облаке клиенту предоставляются управляемые сервисы (Managed Services), и, чем более богатый выбор, тем комфортнее клиенту. Но что делать, если используется закрытый контур? Все преференции, которые дает облако, оказываются недоступны. Deckhouse добавляет Managed Services — базы данных (Redis), мониторинг, работу с логами и т. д. Кроме того, мы работаем над тем, чтобы все принципы cloud native разработки стали доступны клиентам, у которых даже разработка выполняется в закрытом контуре. Благодаря этим подходам мы можем обеспечить полную синергию. Разработчик получает и в облаке, и на внутренней платформе единую среду с общими возможностями, что обеспечивает комфортную работу и полностью меняет образ мышления разработчика: разработка не на конкретной виртуальной машине, а в облачной среде. Такой подход — это не планы на будущее, а сегодняшний день.

Сергей Зинкевич. Запрос на облачные сервисы огромен из-за удобства, при этом не все компании готовы пускать разработчиков во внешние контуры. Но разработчики предпочитают работать в тех компаниях, где им работать удобно. Поэтому для продвижения своего HR-бренда приходится внедрять Deckhouse или, возможно, строить частное облако.

Почему стандартного Kubernetes и пары продуктов CNCF недостаточно? Многие компании предпочитают добавлять проприетарные решения к проверенным open source технологиям. Недавно автор известной книги про микросервисы Сэм Ньюман в своем блоге высказал опасения относительно platform engineering.

Александр Баталов. Насколько я помню, речь идет о том, что платформы не являются «серебряной пулей», и это действительно так. Для крупной технологической компании, добавленная ценность которой определяется технологиями, будет неправильно использовать некий стандартный платформенный продукт, он не даст ей конкурентное преимущество. Однако если в компании ИТ-решения — это инструменты, усиливающие бизнес, то платформа — это единственное, что поможет в развитии бизнеса и обеспечит наилучшее соотношение цена-качество.

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

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

Александр Фикс. Многие компании опасаются оказаться привязанными к определенным вендорам.

Александр Баталов. Такой риск действительно есть. Поэтому «Флант» делает упор на open source и выпускает продукты с открытыми лицензиями. Во-первых, это дает открытый код, а во-вторых, закрывает вопросы о совместимости. После выхода каждый новой версии Kubernetes мы проверяем, что Deckhouse с ней совместим. Кроме того, в каждом релизе нашей платформы мы поддерживаем 5-6 версий Kubernetes, что может предложить далеко не каждая платформа. Это позволяет гарантировать, что клиент не останется ни с чем, если вдруг решит по каким-либо причинам отказаться от вендора и продолжит развивать эту платформу самостоятельно. У клиента будет понятный продукт, который можно и сопровождать, и при необходимости развивать.

Мы все знаем захватывающие истории о том, как основатели стартапов придумывали сервисы, которые в течение очень короткого времени приобретали миллионы подписчиков. Вера в такой успех заставляла стартаперов изначально проектировать безгранично масштабируемые и отказоустойчивые сервисы, и за этим они шли в гиперскейлеры. Что заставляет ваших клиентов выбирать облачное развертывание?

Александр Фикс. Каждый наш клиент не хуже самого крутого зарубежного стартапа.

Александр Баталов. Масштабирование — это далеко не самый главный драйвер использования облака. Облако, в первую очередь, предлагает удобство. Клиент может одномоментно получить доступ к необходимой инфраструктуре, не тратя время на закупку и не планируя необходимую инфраструктуру «на вырост». При этом не стоит опасаться, что бизнес столкнется с проблемами, поменяются задачи или оценка необходимой инфраструктуры окажется ошибочной.

Дмитрий Симонов. Как Kubernetes помогает компании экономить на инфраструктурных затратах и оптимизировать процессы выкатки кода (CI/CD)?

Александр Фикс. Во-первых, огромная экономия будет за счет того, что упрощается выпуск обновлений. Мы можем использовать выкатку новых релизов. Оптимизация происходит, например, за счет канареечного обновления, когда выходит обновление сначала dev-контура на несколько процентов, а потом уже основного. Использование облачного KaaS также сокращает затраты на инфраструктуру. Кроме того, микросервисная архитектура менее объемная, чем монолиты, за счет использования контейнеров.

Дмитрий Симонов. Конкретизирую вопрос: в чем можно измерять эффективность? Могу я выкатить релиз сразу на 500 машин за 10 секунд?

Александр Баталов. Можно сделать очень многое. Все зависит от архитектуры, от того, насколько хорошо написано приложение, насколько эффективно идет сборка, насколько хорошо выстроена система деплоя. У нас есть отличные примеры скорости выкатки.

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

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

Сергей Зинкевич. В чате Олег Сапрыкин из компании «Флант» дополняет, что обычный пайплайн на внутренних инструментах Deckhouse имеет running time 63 секунды, и за полторы минуты после коммита можно проверять правки в проде.

Дмитрий Симонов. Вы сказали, что за счет Kubernetes получается буст бизнеса. В чем это измеряется?

Александр Баталов. Time to Market — увеличивается количество релизов, бизнес-функции можно выпускать намного интенсивнее.

Сергей Зинкевич. Считается, что количество изменений в целом позитивно влияет на бизнес. Конечно, не надо думать, что если просто делать 100 изменений в день, захватишь рынок. Но если у вас есть большой план по гипотезам, корпоративная культура проверки гипотез, вложений в те гипотезы, которые выстреливают, и «отстреливания» идей, которые не работают, то инфраструктура поддержит эти возможности.

Александр Фикс. Вернемся к ритейлерам, которым пришлось срочно перестраиваться в период ковида, реализовывать новые идеи, а для этого требовалось огромное количество релизов каждый день. Если бы они использовали монолит, то не справились бы с этим потоком нововведений.

Дмитрий Симонов. Фактически, мы говорим: пользуйтесь микросервисами, и тогда будет буст для бизнеса. А причем здесь Kubernetes? Я понимаю, что Kubernetes помогает лучше работать с микросервисами. А микросервисы без Kubernetes не работают?

Александр Баталов. Микросервисы без Kubernetes, безусловно, работают. Это вопрос эффективности, удобства, стандартизации. В совокупности это дает свои преимущества.

Дмитрий Симонов. Предположим, у меня есть парк машин и часть парка я сейчас не использую. Могу ли я передать произвольный пул ресурсов другой команде, а потом его забрать, и не делать для этого сложные согласования, просить о чем-то DevOps-ов?

Александр Баталов. Если говорить о Deckhouse, то платформа вообще не зависит от инфраструктуры. Сегодня вы можете развернуть ее на bare metal, завтра на внутренней виртуализации, послезавтра в одном облаке, а послепослезавтра в другом. Вам не придется переделывать деплой, сборку. Все будет работать, потому что платформа реально отвязывает разработчика от конкретной серверной реализации.

Сергей Зинкевич. Такой подход снимает барьеры использования облаков: проще заезжать, проще балансировать нагрузку, но всегда можно включить заднюю передачу и оставить провайдера.

Александр Баталов. Сейчас очень модное направление FinOps, когда затраты на инфраструктуру проецируются на разные команды. Одна команда хочет в облако, вторая предпочитает in house, а третья хочет купить другое облако. Даже биллинг можно настроить таким образом, чтобы четко учитывать ресурсы — какая команда на какой инфраструктурной платформе сколько потребила. Kubernetes в этом очень хорошо помогает навести порядок.

Дмитрий Симонов. Давайте поговорим о рисках, с которыми мы сталкиваемся при работе с Kubernetes.

Александр Баталов. Концепции организации защиты в Kubernetes или не в Kubernetes глобально не отличаются, отличается реализация. То, что делалось с помощью классических «железных» решений, сейчас приходится воспроизводить программно. Зачастую служба защиты к этому не привыкла и с опаской воспринимает новые подходы.

Сергей Зинкевич. Насколько сильно команда защиты затягивает релизы?

Александр Баталов. Не думаю, что сильно. Затягивает, скорее, внедрение платформы по объективным причинам — они хотят быть уверены, что та область, за которую они отвечают, защищена. Когда мы делаем большие инсталляции в крупных российских компаниях, мы тратим от нескольких недель до нескольких месяцев на то, чтобы пройти все этапы верификации, подтверждения, согласования со службой защиты. Скажу с гордостью, что проходим даже в очень серьезных банковских организациях.

В «голом» Kubernetes, к сожалению, ограниченный набор инструментов защиты. В этом плане платформа также приносит большую ценность, поскольку направление защиты — одно из самых важных и при этом емких с точки зрения технологического развития. В Deckhouse есть огромное количество дополнительных компонентов, которые помогают в решении вопросов защиты.