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

У пользователей облака сегодня нет ни времени, чтобы самостоятельно развернуть всю необходимую для бизнес-задач инфраструктуру, ни желания, ни свободных рук. Многим клиентам 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-инженерами, не обладающими полным набором компетенций, необходимых для обеспечения надежности и безопасности конечных сервисов. Предполагаем, что с развитием сервисной модели такие внутренние проекты автоматизации ИТ-разработки будут уходить в прошлое, поскольку набирать и копить компетенцию внутри компании становится слишком затратно и трудно. Аутсорсинг выстраивания ИТ-разработки, напротив, станет еще более востребованным.