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

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

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

Понимание различных моделей аренды с технической точки зрения#

Архитектура с одним арендатором#

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

Характеристики#

• Изоляция: Каждый клиент или арендатор работает в изолированной среде с выделенными ресурсами, базами данных и конфигурациями.
• Кастомизация: Архитектуры с одним арендатором часто позволяют больше кастомизировать и обеспечивают гибкость в соответствии с конкретными потребностями клиента.
• Безопасность: Усиленная безопасность и конфиденциальность данных, так как данные клиента не смешиваются с данными других арендаторов.
• Масштабируемость: Масштабирование ресурсов и мощности может быть более простым, так как экземпляр каждого арендатора можно настраивать независимо.
• Обслуживание: Независимое обслуживание и обновление, так как изменения, внесенные в среду одного арендатора, не влияют на другие.
• Стоимость: Обычно более высокие затраты на инфраструктуру и эксплуатацию из-за необходимости поддерживать отдельные экземпляры для каждого арендатора.

Примеры#

• Выделенный хостинг: Традиционные веб-хостинг-провайдеры предлагают архитектуры с одним арендатором, где каждый клиент получает свои ресурсы, базы данных или конфигурации.
• Установленное на месте программное обеспечение: Некоторые программные приложения уровня предприятия, такие как системы управления взаимоотношениями с клиентами (CRM) или системы управления человеческими ресурсами (HRMS), предлагают варианты развертывания с одним арендатором для организаций с жесткими требованиями к безопасности данных и кастомизации.
• SaaS с премиум-уровнями: В некоторых предложениях Программного обеспечения как услуги (SaaS) премиум или корпоративные уровни предоставляют варианты с одним арендатором для клиентов, требующих усиленной безопасности, соответствия или кастомизации.

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

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

Архитектура с многопользовательской аренды#

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

Характеристики#

• Общие ресурсы: Несколько арендаторов используют одну и ту же инфраструктуру, включая серверы, базы данных и сетевые ресурсы, чтобы оптимизировать использование ресурсов.
• Изоляция: Данные и конфигурации арендаторов логически разделены, обеспечивая конфиденциальность и безопасность данных.
• Экономия на масштабе: Многопользовательская аренда может быть экономически выгодной, поскольку накладные расходы распределяются среди нескольких пользователей, снижая операционные и инфраструктурные затраты.
• Масштабируемость: Архитектура может масштабироваться горизонтально или вертикально, чтобы вместить увеличивающееся количество арендаторов и пользователей.
• Обслуживание: Обновления и обслуживание упрощаются, так как изменения применяются равномерно ко всем арендаторам, упрощая управление.
• Кастомизация: В то время как некоторый уровень кастомизации возможен, он обычно ограничен по сравнению с архитектурами с одним арендатором, чтобы поддерживать консистентность системы.

Примеры#

• Облачные SaaS: Большинство приложений Программного обеспечения как услуги (SaaS), таких как Google Workspace и Salesforce, используют многопользовательскую аренду для обслуживания нескольких организаций или пользователей на общей платформе.
• Общий хостинг: В веб-хостинге услуги общего хостинга размещают несколько сайтов на одном сервере, каждый из которых принадлежит разным клиентам или организациям.
• Общественные облачные сервисы: Публичные облачные провайдеры, такие как AWS и Azure, используют многопользовательскую аренду для обслуживания различных клиентов с изолированными виртуализированными ресурсами в общих центрах данных.
• Корпоративные инфраструктурные решения: Такие как общий кластер Kubernetes, который используется несколькими бизнес-единицами внутри организации.

Переопределение многопользовательских приложений в реальном мире#

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

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

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

На практике в разработке продуктов SaaS часто встречается ситуация, когда продукт в основном разрабатывается с использованием общей модели многопользовательской аренды. Однако определенные аспекты архитектуры или ресурсов могут наклоняться в сторону "одноарендаторской" методики.

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

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

Понимание этого термина в широком смысле может лучше помочь вам эмпатировать потребности вашего клиента и откуда они берутся.

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

Ключевые соображения для определения вашей стратегии модели аренды#

Возникает вопрос, как мне предложить стратегию аренды для моего продукта? Вот некоторые важные вопросы, над которыми стоит подумать:

• Каковы ваши бизнес-цели?
• Может ли одноарендаторское решение поддерживать ваши планы по росту в будущем?
• Насколько велика ваша операционная команда и насколько управление вашими инфраструктурами может быть автоматизировано? Заботите ли вы об агилитете и эффективности затрат?
• Удовлетворены ли ваши клиенты различными вариантами многопользовательской аренды?
• Как каждое решение влияет на соблюдение норм, как для вас, так и для ваших клиентов?
• Ожидается ли от вас соблюдение соглашений об уровне услуг (SLAs) или достижение определенных целей уровня услуг (SLOs)?
• Рассмотрели ли вы безопасность, стоимость, производительность, надежность и отзывчивость к индивидуальным потребностям арендаторов в целом?

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

Дальше#

Мы поговорили о "новом" определении многопользовательского приложения, но как насчет изоляции арендаторов, идентичностей и как определить, должны ли ваши идентичности быть изолированными или нет? Что означает, когда идентичности "изолированы"?

Путаница часто возникает, когда имеет место ситуация, где у одного реального пользователя есть две разные идентичности. Подходит ли в этом случае выражение - "изолированные идентичности"?

Мы рассмотрим эти вопросы в нашей предстоящей серии статей. Оставайтесь с нами!