Углубленное изучение понятия "многопользовательская аренда" и обмен нашими представлениями о том, как мы его воспринимаем.
Мы часто слышим о важности создания многопользовательского приложения, особенно в контексте разработки приложения как услуги (SaaS).
Существует некоторая путаница в понимании концепции "многопользовательского приложения" и различных моделей, используемых для его разработки. В этой статье мы рассмотрели эти термины более практическим образом.
Архитектура с одним арендатором - это модель программного обеспечения или облачных вычислений, в которой каждый клиент или арендатор имеет выделенный экземпляр приложения или услуги. Если мы рассмотрим происхождение модели B2B, она начинается с того, что каждый экземпляр программного обеспечения обслуживает только одного клиента или организацию.
Архитектура с одним арендатором часто используется в сценариях, где соответствие является первостепенным или нужны индивидуализированные требования к безопасности. Например, в таких отраслях, как финансы, здравоохранение и государственные учреждения, где есть строгие нормативные требования, часто предпочитают решения с одним арендатором для обеспечения соблюдения норм.
Однако важно отметить, что архитектуры с одним арендатором могут требовать больше ресурсов и быть сложнее в управлении по сравнению с многопользовательскими архитектурами, так как экземпляр каждого клиента требует собственной инфраструктуры и обслуживания. В результате они могут быть более подходящими для приложений с меньшим количеством, но более крупными клиентами или когда критически важна кастомизация и изоляция.
Многопользовательская аренда программного обеспечения - это архитектура программного обеспечения, в которой один экземпляр программного обеспечения работает на сервере и обслуживает нескольких арендаторов. Системы, созданные таким образом, являются "общими" (а не "выделенными" или "изолированными"). Арендатор - это группа пользователей, которые имеют общий доступ с определенными привилегиями к экземпляру программного обеспечения. С архитектурой с многопользовательской аренды программное приложение разрабатывается таким образом, чтобы предоставлять каждому арендатору выделенную часть экземпляра - в том числе его данные, конфигурацию, управление пользователями, индивидуальную функциональность арендатора и нефункциональные свойства. -- Википедия
Мы предоставили определения с архитектурной точки зрения, делая их простыми для различия между многопользовательскими и одноарендаторскими дизайнами. Однако это больше склоняется к техническому определению. Если использовать эти определения в нашей реальной среде разработки при проектировании моделей аренды, такой способ мышления предполагает, что многопользовательское приложение должно иметь исключительно общую многопользовательскую инфраструктуру.
Однако, бизнес и продукт сильно отличаются и имеют множество индивидуальных требований, поэтому нет единого решения для всех случаев.
Представьте себе ситуацию, в которой арендатор использует ресурсы общей инфраструктуры, но из-за конкретных бизнес-потребностей ему требуется одна или две части системы, которые будут исключительно для него. Эти выделенные части могут быть базой данных, экземплярами или комбинацией других компонентов, при этом общая инфраструктура будет оставаться общей. Это называется архитектурой со смешанной арендой.
На практике в разработке продуктов SaaS часто встречается ситуация, когда продукт в основном разрабатывается с использованием общей модели многопользовательской аренды. Однако определенные аспекты архитектуры или ресурсов могут наклоняться в сторону "одноарендаторской" методики.
AWS использовали следующий пример, чтобы донести эту концепцию: многопользовательская аренда - это широкая концепция, и каждый случай индивидуален в выборе и комбинировании правильной стратегии для определения того, чего вы хотите достичь с помощью общих ресурсов и изоляции данных.
Другими словами, иногда люди все еще называют эту модель "Многопользовательской арендой", поэтому в широком определении многопользовательской аренды это не подразумевает, что каждый компонент решения является общим. Скорее, это подразумевает, что как минимум некоторые компоненты решения используются несколькими арендаторами.
Понимание этого термина в широком смысле может лучше помочь вам эмпатировать потребности вашего клиента и откуда они берутся.
Вместо того, чтобы фиксироваться на одной архитектурной модели, многопользовательская аренда отражает практичность архитектуры SaaS-продукта в реальном мире. Когда мы говорим о многопользовательском приложении, это не обязательно означает, что приложение придерживается одной архитектурной модели; оно может использовать различные стратегии аренды, указывая на то, что как минимум некоторые из его компонентов являются общими.
Возникает вопрос, как мне предложить стратегию аренды для моего продукта? Вот некоторые важные вопросы, над которыми стоит подумать:
Помните, что нет жесткого разделения в вашем продукте, где обязательно выбрать либо чисто многопользовательскую, либо только одноарендаторскую модель. Ваше решение должно основываться на том, как вы разделяете архитектурные компоненты вашего продукта и какие уровни изоляции требуют ваши клиенты или бизнес. Затем вы можете применять разные подходы соответственно.
Мы поговорили о "новом" определении многопользовательского приложения, но как насчет изоляции арендаторов, идентичностей и как определить, должны ли ваши идентичности быть изолированными или нет? Что означает, когда идентичности "изолированы"?
Путаница часто возникает, когда имеет место ситуация, где у одного реального пользователя есть две разные идентичности. Подходит ли в этом случае выражение - "изолированные идентичности"?
Мы рассмотрим эти вопросы в нашей предстоящей серии статей. Оставайтесь с нами!