Вопрос архитектуры SaaS от новичка

Question

Я разработал ряд ведомственных клиент-серверных приложений и теперь готов приступить к переводу одного из этих приложений на модель SaaS. Я сделал некоторые базовые веб-разработки, но я новичок, когда дело доходит до архитектур SaaS.

Один из первых вопросов, который приходит мне в голову, когда я пытаюсь спроектировать архитектуру, - это вопрос единственного или множественного владения. Плюсы и минусы каждого из них значительно различаются в зависимости от требуемого типа приложения и масштаба, поэтому я хотел бы описать свои потребности в приложениях и масштабировании ниже и надеяться, что другие могут прокомментировать, как мне начать работу с архитектурой.

Клиент-серверное приложение в настоящее время состоит из базы данных Firebird и приложения Windows. База данных содержит около 20 таблиц, содержащих несколько тысяч записей в 4 первичных таблицах, и несколько сотен записей в различных справочных и связанных таблицах. Хотя количество записей невелико, размер может быть большим, поскольку база данных может содержать большие BLOB-объекты. Каждый клиент настраивает свою собственную базу данных и имеет несколько пользователей в организации, связанных с ней. Когда я обновляю схему БД, выпускается новое приложение Windows, которое проверяет схему БД, а затем применяет обновления по мере необходимости.

Для приложения SaaS я проектирую для 100 (не 1000 или миллионов) новых клиентов в год. Моей первой мыслью было использовать модель с несколькими арендаторами, чтобы упростить обновления (завершите работу, примените обновления к одной базе данных, а затем запустите). С другой стороны, единая модель аренды предоставит средство для одновременного развертывания обновлений для группы клиентов и распространения риска повреждения данных - то есть, если что-то пойдет не так с базой данных, это повлияет на одного клиента вместо все клиенты. С этой идеей я думал о едином веб-интерфейсе, который подключался бы к единой базе данных клиентов при входе в систему. Таким образом, когда новый клиент создает учетную запись, создается новая база данных (каждый клиент будет иметь свою собственную базу данных с несколькими пользователями по мере необходимости для клиента).

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

Может кто-нибудь указать мне информацию для похожих приложений, которые были перенесены с клиент-сервер на SaaS? Или предоставить какие-либо указатели для рассмотрения? По сути, я ищу примеры архитектуры, где можно взять ведомственное приложение и сделать его доступным в качестве веб-сайта самообслуживания для нескольких клиентов. Спасибо за любые предложения, ресурсы и т. Д.

Answer 1

Хорошие вопросы.

Одна вещь, которая приходит на ум, это то, что если у вас есть несколько баз данных, которые вы развертываете поэтапно, чтобы уменьшить вероятность взлома всех ваших клиентов, вам придется решить вопрос, что делать, если структура БД изменения. Вы должны будете либо быть очень строгими в отношении обеспечения обратной совместимости, либо развернуть отдельные версии своей базы кода и каким-либо образом управлять, какие арендаторы связаны с какими базами данных.

Мы также предоставляем наше приложение, используя модель SaaS.

Первоначально это было приложение для Windows, которое работало аналогично вашему предложению с несколькими базами данных. После входа в систему приложение win будет проходить аутентификацию в одной базе данных «лицензиата», которая затем будет отвечать информацией о соединении для базы данных, специфичной для этого лицензиата. Приятно то, что это обеспечивало 1) физическое разделение данных лицензиата, которое нравилось нашим клиентам, и 2) позволяло нам физически размещать базу данных на сервере, географически ближе к пользователям, что одновременно повышает производительность и позволяет избежать некоторых потенциально сложных юридических и нормативные вопросы в отношении предоставления данных за пределы страны.

Конечно, так как приложение было толстым клиентским приложением, мы могли бы с легкостью вносить изменения в базу данных и отправлять их одному лицензиату за раз. Когда мы были готовы к обновлению, мы могли выдвинуть обновленный толстый клиент вместе с новой базой данных - таким образом гарантируя, что кодовая база соответствовала базе данных. Пока общая база данных аутентификации «лицензиата» оставалась согласованной, это работало довольно хорошо.

Однако, с другой стороны, это решение принесло с собой все проблемы, связанные с обслуживанием и управлением подходом «толстого клиента», что в итоге привело нас к «клиентскому» подходу на основе браузера.

В нашей новой модели все находится в одной базе данных. Когда у нас есть обновления, мы одновременно выдвигаем и код, и базу данных. Это решает проблему поддержания базы кода в соответствии со структурой базы данных. Однако сейчас мы сталкиваемся с проблемами, упомянутыми в пунктах 1 и 2 выше, которые нам еще предстоит решить.

Надеюсь, это даст вам пищу для размышлений.

Меня тоже интересует этот вопрос.

Спасибо за сообщение.

-S