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

ОК

Но в целом похоже на модель nextcloud провайдеров

Аля Heroku?

Имхо надо двигать в кубер, пользоваться его scheduler

Нужен:
1) любое k8s как сервис
2) набор запакованных сервисов в докер, с вынесенными конфигами и параметрами через енв
Тулзы:
1) go (binary)
2) pulumi|terraform
3) go (operator)
Workflow:
1) клиент задает параметры которые ему необходимо
2) go (cli) генерит *.tf файлы
3) pulumi создаёт все ресурсы инфраструктурного уровня в управляемом k8s кластере
4) go (operator) читает cdr и создаёт сервисы из этого описания с теми настройками, которые там заданы

И масштабировать ресурсы в соответствие с клиентской базой

С Кубером конечно понятно, но я пока не спец в нем, как раз хочу научиться на данном проекте после его масштабирования. Сначала будут обычные docker compose.

@AutomationD @sanyo_devops  задача решена

Это медленно и ненадёжно

Полностью согласен, для пилотного варианта пока сойдет по быстрому, а потом можно и в Кубер.

Кубер не так сложен

Особенно без свистелок энтерпрайза

Зато окупится.

Большое спасибо за решение в целом, но мне хотелось бы вернуться к своему варианту, когда CLI работает через MQ, что в этом плохого?

Недавно хорошая (с моей чайниковской точки зрения) статья выходила про Хк-Хк и Спарк

Потому, что слишком много точек отказа, а роль очереди вообще является дублирующей очередь API твоего провайдера

+

@sanyo_devops когда ты начинаешь работать с каким-нибудь провайдером ты фактически общаешься через апи, у которого уже есть своя очередь и возводить апи за апи с очередями это фактически дублировать архитектуру провайдера. Что увеличивает время реализации, сумму владения и so on