Микросервисы в Kubernetes — это ответ!
… а какой был ваш вопрос?

Спонсор поста — Selectel.

Давайте порассуждаем, зачем вообще вам микросервисы и Kubernetes.

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

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

Именно сложность параллельной разработки на монолите приводит всех к микросервисам.

Казалось бы, можно и в монолите выстроить хорошую архитектуру, которая четко разделит домены и проведет мостики между ними, чтобы обеспечить пресловутые low coupling & high cohesion.

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

Микросервисы и API как мостики для взаимодействия между ними — системное решение для low coupling & high cohesion.

Архитектура буквально заставляет нас делать поменьше запросов между сервисами, потому что разработка API — сложнее, чем подключение зависимости внутри кода.

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

Можно всё собирать самому. Начать с Docker-compose на трёх виртуалках, самому поднимать nginx, самому настраивать маршрутизацию. В какой-то момент нагрузка потребует добавления виртуалок и каждый раз — это будет ручная работа и накладные расходы:
— Арендовать еще железа
— Поднять там виртуалки
— Настроить на них все компоненты
— Включить в балансировку
— ….🤯

Можно автоматизировать развертывание своих велосипедов на независимых компонентах, но скорее всего в итоге всё равно придём к Kubernetes.

А это еще больше накладных расходов на сетап и обслуживание компонентов K8s.
Да и в целом правильное управление k8s — это отдельная большая область знаний.
Зачастую в компаниях есть отдельные «DevOps’ы», которые занимаются чисто кубером.

Но Kubernetes — реально отчуждаемая часть, где гораздо проще отдать ответственность хостеру и потом требовать выполнения SLA.

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

Сервис сам разворачивает кластер Kubernetes с Control Plane, настраивает сетевое окружение, глобальный роутер и поднимает группу нод на выделенных серверах. Со стороны инженеров не нужно париться об администрировании. Вам нужно только выбрать тип кластера и конфигурацию в панели управления. При этом есть доступ к kubectl и всему, что требуется для деплоя ваших микросервисов и маршрутизации трафика снаружи и между ними.

Из плюсов именно Selectel — воркер-ноды работают не на виртуалках, а на выделенном железе. А это убегерает от спецэффектов «шумных соседей» и оверхеда виртуализации. Как итог — обещают экономию на 40% по сравнению с арендой виртуалок.

Подробнее — на лендосе Managed Kubernetes от Selectel.
Реклама, АО «Селектел», ИНН: 7810962785, ERID: 2Vtzqx9pGZm

———

Поделитесь в комментах — поднимали ли вы хоть раз кубер?
Сколько времени это заняло в первый раз и сколько времени тратите на поддержку?