Как лучше спроектировать облачный сервис?

Question

[aleks-th]

Делаю облачный сервис.
В двух словах маленькая учётная программа.
--
На nginx+django+postgree.
Возник вопрос.
Как сделать безопаснее и правильнее.
--
1. Все в одном приложении и на одной базе данных, и заморачиваться разруливать между пользователями правами.
--
2. Или для каждого сделать именно его изолированный микро сервер.
С его базой данных, его окружением.
---
Как бы в первом случае нет накладных расходов, но стрёмно, что если ломанут то сразу всех, или сломается у всех сразу.
Особенно безопасность беспокоит юзеров нужно будет друг от друга как то оберегать.
Но как бы и обновлять и управлять проще.
--
А во втором случае накладные расходы, каждый будет жрать чуть больше ресурсов.
Придется придумывать как их разом администрить, обновлять и разом все контролировать.
Но зато если, кого-то ломанут то его одного, да и если что-то сломается не у всех сразу.
И масштабировать если что удобнее, знай добавляй серверы если одного хватать вдруг перестанет.
---

Как считаете какой варант правильнее и надёжнее и почему?

Comments

[Василий Банников]

Вы в общем-то назвали основные минусы/плюсы обоих подходов.
Вопрос надёжности и безопасности в принципе решаем.
Я бы сделал монолитное решение, тк уже был опыт разруливания таких вещей.

Answer 1

[Sanes]

Или для каждого сделать именно его изолированный микро сервер

И добавить точек отказа.

А во втором случае накладные расходы, каждый будет жрать чуть больше ресурсов.

Особенно северы Postgre

Answer 2

[rPman]

Все так, но.

Разделение по инстансам по факту не сильно увеличивает надежность, ведь они будут однотипные, а значит уязвимость на них будет на всех сразу, если говороть о классических 0day уязвимостях... т.е. что в монолитном варианте что в рапределенном, если ломанут то скорее всего все сразу.

Распределенное решение обладает хорошими плюшками
- облегчается горизонтальная масштабируемость, возможен перенос особо нагружающих пользователей на отдельный сервер 'из коробки'
(монолитный вариант можно так же вынести отдельно, используя мастер-мастер репликацию, иногда дает огромный плюс, но за счет затрат памяти, так как данные копируются все полностью)
- немного уменьшается шанс все сломать из-за ошибки администрирования, особенно если интеграция обновлений будет производиться не сразу на всех, а возможно выделить группу отдельных пользователей для теста на живую, т.е. сломаешь все у тестовой группы а не у всех сразу... но шанс реально мизерный, ошибки по закону подлости всегда коварные и гадкие.