Интерес к семейству ПО для контейнеризации OpenShift был довольно высоким в корпоративном сегменте в прежние годы. По данным мониторинговой службы Datadog, только за прошлый год во всем мире количество пользователей платформ от RedHat увеличилось на 28%. Весной IBM объявил об уходе из России и прекращении поддержки всех программных продуктов для текущих клиентов. Разберемся, насколько критичной оказалась данная ситуация для заказчиков, и какие варианты действий существуют, чтобы минимизировать возможные риски отключения от сервиса.

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

На текущий момент большинство учетных записей пользователей РФ заблокированы. Обновление продуктов (новые подписки, доступ к репозиториям образов и пакетов) превращается в квест. Как минимум, неудобно регистрировать новую учетку и получать обновления. Как максимум — кластеры, живущие в онлайне, могут стать недоступны.

Нет особой надежды и на аутсорсинг. Редкий игрок на этом рынке возьмется исправлять ошибки в вендорском продукте или накатывать апдейты без возможности отката, так как есть реальная перспектива того, что проблем станет только больше.

Есть ли риски для клиентов после отказа вендора от поддержки OpenShift в нашей стране?

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

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

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

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

Какие варианты решения проблемы существуют сегодня?

Ничего не предпринимать и остаться на неподдерживаемой версии OpenShift. В этом случае клиентам нужно будет взять риски на себя, самостоятельно поддерживать работу платформы или попытаться найти сервисного партнера с необходимой экспертизой. Также важно тщательно тестировать обновления на отдельных кластерах перед внедрением.
Перейти на OKD. При подобной схеме нет прямой зависимости от разработчика, но при этом потребуется наличие более глубокой экспертизы по продукту внутри компании. Кроме того, большую роль играет коммьюнити. Такой вариант подходит для тех, кто хочет пользоваться основным функционалом OpenShift, так как у Open Source версии он частично воспроизведен, при этом у компании нет необходимости в вендорской поддержке. По такому пути пошли в одной страховой компании. В ней микросервисный ландшафт используется для разработки, тестирования и продуктивной работы цифровых страховых услуг, а поддержка оказывается провайдером в формате управляемого сервиса.
Перейти на Kubernetes. Стоит отметить, что этот вариант требует максимального уровня экспертизы и глубинного понимания работы как самого Kubernetes, так и всевозможных сервисов инфраструктурной обвязки и инструментов автоматизации. Данный вариант рекомендуется рассматривать только клиентам, имеющим большой опыт внедрения подобных решений, или компаниям, имеющим возможность привлечь квалифицированного сервис-провайдера.

Как осуществляется переезд с OpenShift?

Единого алгоритма, универсального для всех компаний, в этом процессе нет. Ему предшествует подробный опрос клиента с требованиями к инфраструктуре, безопасности, особенностям интеграции. Обычно мы также интересуемся у заказчиков, какими инструментами они пользуются, что в них нравится/не нравится. На основе этих данных можно определить целевую архитектуру решения. С точки зрения инфраструктуры — такая платформа может быть развернута в публичном облаке или в частной инфраструктуре (в тех случаях, когда требования служб безопасности не позволяют выносить любые данные за периметр организации). Также мы даем рекомендации, как построить процессы CI/CD, каким образом выстроить процессы защиты ИТ-инфраструктуры и какие дополнительные инструменты лучше использовать.

С оригиналом статьи можно ознакомиться на IT Channel News.