Как развернуть систему из нескольких микросервисов во внутреннем периметре организации без Docker?

Question

[kurtgn]

Есть одна серьезная организация с серьезными ИТ безопасниками, которые заказывают у нас продукт, но настаивают на том, что Kubernetes у них запрещен, и кажется, даже Docker использовать нельзя. Собирайте, говорят, rpm-пакеты и разворачивайте. Мониторинг и масштабирование - нужны, но без контейнеров.

У меня нет опыта работы с корпоративными системами в закрытом периметре. Я хипстер и знаю только новую школу: облака, 12 factor app, микросервисы, и т.д. и т.п. И продукт наш состоит из шести микросервисов. (не считая сервисов с БД, кэшем и очередями).

Нужен совет: как выглядит ежедневная эксплуатация такой системы? Условно говоря, как инженер эксплуатации узнаёт о том, что CPU, RAM или HDD такого-то сервера перегружен, и куда он нажимает, чтобы решить эту проблему?

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

Comments

[Дмитрий]

т.е. у вас есть требование что бы работало без контейнеризации, а вы сделали на контейнерах и теперь спрашиваете у сообщества что делать?

[kurtgn]

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

Answer 1

[#]

вам было бы проще, если это был 1 микросервис?

Comments

[kurtgn]

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

Но вопрос не совсем релевантен. Проще или нет - неважно, это уже не один микросервис. Это уже маленькое облако из сервисов, которое нужно портировать организации во внутренний периметр. Переписывать всё в монолит чисто под этого клиента - не вариант.

[#]

вам виднее..

[kurtgn]

если бы мне было виднее, я бы не просил здесь совета )

[#]

два вопроса:
- ваше решение работает с 1 внешним ip?
- клиент готов предоставить более одного физического компьютера?

[#]

ремарка - хипстер

[#]

.. и я не уверен, что вы правильно применяете это к себе ;))

[kurtgn]

в смысле - выставлен ли наружу для вебхуков только один внешний IP? да, он только один.
Клиент готов предоставить сколько угодно машин в закрытом периметре. Это банк )

[#]

ок. вот алгоритм:
прикиньте трудоемкость переписи в "монолит", и и сравните с предлагаемой суммой.. если покажется мало - да запросите больше

[#]

... или упражняйтесь в риторике

[#]

в смысле убедите клиента что дурак он а не вы

[#]

.. вы удивитесь.. но иногда можно это совместить - и убедить клиента что он дебил + выбить большую сумму... а иногда - как получится

[#]

главное - не стойте на месте. чем толще клиент, тем толще гарантия, что он общается не только с вами

Answer 2

[Александр]

Эк нынче разработчики обленились. Ну есть у вас во внутреннем периметре N тачек, подняли там днс для удобства, да доставляйте код как угодно, хоть пакетами, хоть рсинком, есть же системы управления типа ансибла, да хоть башскрипт для деплоя. Не понимаю проблемы в монолитности/не монолитности приложения в данном контексте. Поднимите мониторинг, благо выбор есть (Prometheus, TICK, да что угодно), шлите или забирайте метрики со своих сервисов.