Managed services против PaaS: плюсы и минусы каждого подхода
Мнение экспертов

Managed services против PaaS: плюсы и минусы каждого подхода

2567
4 минуты

Облачный рынок движется в направлении упрощения сервисов для конечных пользователей. Особенно ярко это видно на примере PaaS – услуги, выручка от предоставления которой, по разным оценкам, за последний год выросла на 20–30%. Но в настоящее время это не панацея.

У пользователей облака сегодня нет ни времени, чтобы самостоятельно развернуть всю необходимую для бизнес-задач инфраструктуру, ни желания, ни свободных рук. Многим клиентам PaaS (платформа как сервис) видится некой готовой «коробкой», которая в одночасье решит все инфраструктурные проблемы. Однако в крупном корпоративном сегменте такое происходит далеко не всегда. Возьмем в качестве иллюстрации Kubernetes as a Service – один из наиболее востребованных PaaS-сервисов у компаний, ведущих ИТ-разработку.

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

Есть масса примеров, когда классические облачные Kubernetes-сервисы не очень справляются или не справляются вовсе с возложенными на них задачами:
  • когда нужно тонко настроить ядро ОС или среду исполнения контейнера (container runtime) для соответствия международным стандартам безопасности, таким как openSCAP или CIS Benchmark;
  • когда необходимо внедрить CNI plugin, отличный от того, что предлагает облачный провайдер;
  • когда необходимо настроить внутренние потоки трафика через узел защиты ИТ-инфраструктуры (например, межсетевой экран);
  • когда необходимо настроить интеграции с внешними сервисами компании или системами защиты сред контейнеризации (как правило, в PaaS это все же реализуемо, но чаще всего работает через боль и страдания);
  • когда необходим доступ к узлам master nodes, чтобы собирать оттуда статистику и логи. Обычно в PaaS это невозможно, потому что заказчикам доступны только worker nodes, а master nodes от него скрыты;
  • когда заказчик просто не может использовать публичные облака, но при этом хочет получать Kubernetes как сервис (да, такое тоже возможно).

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

Краткий итог: PaaS как концепция – это здорово, и данный класс сервисов бурно растет и будет активно развиваться в будущем, устраняя свои изъяны. Но в настоящее время это не панацея. Если вам нужны кастомизированное решение и сложные интеграции или у вас повышенные требования к защите ИТ-инфраструктуры, то PaaS, вероятно, не выход.

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

Managed Kubernetes на базе выделенной инсталляции в облаке – это возможность спроектировать уникальную инфраструктуру, учитывающую все требования и пожелания клиента в части общего функционала, требований безопасности и внешних интеграций. В данной концепции заказчик не привязан к сервису конкретного облачного провайдера, а значит – вправе самостоятельно выбирать решения, которые лучше подойдут для его задачи, необязательно те, которые «из коробки» предлагает провайдер. В плане доработок по безопасности Kubernetes, предоставляемый в формате управляемого сервиса, также более полноценен в сравнении с «чистым» PaaS. В таких проектах платформа донастраивается согласно требованиям служб безопасности и внутренних регламентов. Где-то это может быть приведение кластеров Kubernetes в соответствие со стандартами безопасности (CIS, OpenSCAP, PCI/DSS) и внедрение дополнительных средств защиты в соответствии с 152-ФЗ. Где-то – интеграция со специализированными средствами защиты контейнеризованных сред, например Aqua Security и Prisma Cloud. Где-то нужно установить на границе Kubernetes средство межсетевого экранирования и настроить через него внутренние потоки трафика. И часто необходимо реализовать все вышеперечисленное.

Важный момент: в подобных проектах провайдер предоставляет документацию, которую клиент может использовать, если, например, решит в дальнейшем самостоятельно развивать инфраструктуру для ИТ-разработки. При работе с PaaS такая возможность ограничена, так как в документации на инфраструктуру придется учитывать особенности сервиса того провайдера, на базе которого осуществлялось развертывание. Если же заказчик через полгода захочет перейти к другому провайдеру, у которого PaaS устроен совсем иначе, или вовсе вынести приложение на собственный Kubernetes in-house, то проблем при донастройке не избежать.

Таким образом, при работе с Kubernetes общая рекомендация может быть следующей: если нужен быстроразвертываемый стандартный сервис – смело используйте PaaS. Если проект требует кастомизации, соответствия различным стандартам защиты ИТ-инфраструктуры, глубоких и тонких интеграций и в конце концов поддержки в виде выделенной команды экспертов, на которую всегда можно опереться, – выбирайте Managed PaaS у проверенного провайдера.

Есть, правда, еще один вариант. Он подходит смелых и уверенных в себе: развернуть нужную инфраструктуру локально собственными силами и поддерживать ее самостоятельно. Однако с каждым годом эта задача усложняется, так как потребность в специалистах растет лавинообразно, а качество их подготовки падает. Мы сталкивались в своих проектах с не оптимально выстроенными инфраструктурами, которые проще было создать заново, чем поправить. И с DevOps-инженерами, не обладающими полным набором компетенций, необходимых для обеспечения надежности и безопасности конечных сервисов. Предполагаем, что с развитием сервисной модели такие внутренние проекты автоматизации ИТ-разработки будут уходить в прошлое, поскольку набирать и копить компетенцию внутри компании становится слишком затратно и трудно. Аутсорсинг выстраивания ИТ-разработки, напротив, станет еще более востребованным.
28 марта 2024
Резервное копирование Elasticsearch и другие мартовские обновления Облака КРОК

В Облаке КРОК появилась поддержка резервного копирования еще для двух сервисов PaaS: Elasticsearch и ELK. А для уже установленных сервисов PaaS стало возможным менять параметры и окружение, в котором они работают. Кроме того, в Terraform добавили поддержку транзитных шлюзов и перешли на новую схему нумерации версий. Подробнее об этих и других обновлениях ниже.

2 минуты
274
19 июня 2023
Семь трендов на рынке облачных услуг в 2023 году
До 2022 года на рынке облаков в России главенствовали мировые тренды, но сейчас наша страна пошла своим путем. О том, для чего сейчас компании используют облачные технологии и как меняется рынок, рассказал директор по развитию КРОК Облачные сервисы Сергей Зинкевич.
1 минута
2461
16 июня 2023
Рулевой в океане контейнеров
Выпуск#3 видеоподкаста «Откровенно об ИТ-инфраструктуре» посвящен Kubernetes и профессиональным платформам оркестрации контейнеров. Обсудили, как сегодня складывается ситуация на российском рынке контейнерных платформ, что востребовано и почему, особенности и перспективы работы с Kubernetes.

В гостях Александр Баталов, Генеральный директор Флант
1 минута
1637
29 марта 2023
Сетевые балансировщики нагрузки и другие обновления Облака КРОК

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

2 минуты
984
scrollup