Назад | Перейти на главную страницу

Развертывание веб-приложения: одна версия для всех клиентов или каждому свою

У меня общий вопрос о развертывании программного обеспечения. На работе мы разрабатываем CRM, которая используется через веб-браузеры. Мне недавно сказали, что у каждого конкретного клиента есть свой сервер (хотя серверы принадлежат моей компании, они не принадлежат им и не находятся в их офисах).

Это меня немного беспокоит. С моей точки зрения, при разработке веб-приложения он должен иметь в виду, что он сможет поддерживать одну «мягкую» работу для всех своих клиентов (не говоря уже о репликации или балансировке нагрузки), возможно, с разными базами данных для каждое, но одно приложение ... Это особенно помогает поддерживать и держать всех в курсе с помощью исправлений и обновлений. Я ошибся ?? Не могли бы вы помочь мне лучше разобраться в этом вопросе с помощью ресурсов (мне, должно быть, не хватает подходящих ключевых слов или около того, чтобы найти их самому). На самом деле я не понимаю, почему они прошли «третий путь» между «одним централизованным веб-приложением для всех» и «одним распределенным настольным приложением для каждого».

Спасибо !

Это зависит от подхода. Гораздо проще поддерживать тысячи серверов, которые совпадают с современными технологиями (инструменты для автоматизации работы, такие как docker, puppet, chef, ansible и т. Д. - их сотни).

Наличие одного сервера для каждого клиента дает вам возможность более точно планировать ресурсы для каждого клиента и позволяет им платить за то, что они действительно используют. Это также уменьшает вашу проблему, что также имеет некоторые преимущества.

Представьте, что у вас будет 1000 клиентов в одной базе данных с общим объемом данных 2 ТБ. Вашим разработчикам необходимо идеально писать SQL-запросы, чтобы такая база данных была достаточно быстрой. Эта проблема намного меньше с небольшой базой данных для каждого клиента.

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

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

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

Исходя из моего опыта, я лично предлагаю иметь экземпляр для каждого клиента, если вы можете управлять множеством экземпляров.

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

У меня есть одна и та же версия программного обеспечения для каждого клиента в моей среде, которая помогает нам поддерживать и масштабировать серверы (я могу просто развернуть новый сервер, который идентичен другим, и просто добавить его в loadbalancer). Также мне не нужно работать с разными конечными точками для каждого клиента.

Я думаю, что это довольно ранняя установка, и вот несколько причин, по которым я считаю плохой идеей держать отдельные серверы поверх накладных расходов на ресурсы:

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

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

  • все успешные Saas-компании в конечном итоге используют агрегированные данные для объединенных анонимных функций, таких как отраслевая статистика, возможности обучения и т. д. Я видел, как это успешно используется Xero и Mailchimp, и я полагаю, что эти данные очень ценны.