@aleks-th

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

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

Как считаете какой варант правильнее и надёжнее и почему?
  • Вопрос задан
  • 89 просмотров
Пригласить эксперта
Ответы на вопрос 2
Sanes
@Sanes
Или для каждого сделать именно его изолированный микро сервер

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

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

Особенно северы Postgre
Ответ написан
Комментировать
@rPman
Все так, но.

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы