При рассмотрении мультитенантной архитектуры необходимо принять несколько решений и элементов, которые необходимо учитывать.
В архитектуре с несколькими арендаторами вы делите некоторые или все свои ресурсы между ними. Этот процесс означает, что архитектура с несколькими арендаторами может обеспечить вам экономичность и эффективность работы. Однако мультитенантность представляет сложности. Вам нужно задать себе следующие вопросы:
- Как определить, что такое клиент , для конкретного решения? Соответствует ли клиент, пользователь или группа пользователей, например команде или семье?
- Как вы будете развертывать свою инфраструктуру для поддержки нескольких арендаторов и насколько велика будет изоляция между арендаторами?
- Какие коммерческие модели ценообразования будут предлагать ваше решение, и как ваши модели ценообразования влияют на ваши требования к мультитенантности?
- Какой уровень обслуживания необходимо предоставить клиентам в таких измерениях, как производительность, устойчивость, безопасность и соответствие требованиям, такие как размещение данных?
- Как вы планируете развивать бизнес или решение? Будет ли оно масштабироваться до количества ожидаемых клиентов?
- Есть ли у кого-то из ваших арендаторов необычные или особые требования? Например, нужна ли вашему крупнейшему клиенту более высокая производительность или более надежные гарантии, чем другим?
- Как отслеживать, управлять, автоматизировать, масштабировать и управлять средой Azure, а также как мультитенантность влияет на стратегию управления?
- Какие компоненты решения обрабатывают подключение клиента и управление и как следует разрабатывать эти компоненты?
Независимо от архитектуры, важно, чтобы у вас было четкое представление о требованиях клиентов или клиентов. Если вы выполнили обязательства по продажам клиентам, или если у вас есть договорные обязательства или требования к соответствию требованиям, необходимо знать, какие требования применяются при разработке решения. Но в равной степени ваши клиенты могут иметь неявные ожидания о том, как должны работать вещи, или как вы должны вести себя, что может повлиять на то, как вы разрабатываете мультитенантное решение.
Например, представьте, что вы создаете мультитенантное решение, которое вы продаете предприятиям в отрасли финансовых услуг. У ваших клиентов есть очень строгие требования к безопасности, и они должны предоставить полный список всех доменных имен, которые использует ваше решение, чтобы они могли добавить его в список разрешений брандмауэра. Это требование влияет на используемые службы Azure и уровень изоляции, который необходимо предоставить между клиентами. Они также требуют, чтобы их решение было минимальным уровнем устойчивости. Существует множество аналогичных ожиданий, как явных, так и неявных, которые необходимо учитывать во всем решении.
В этом разделе мы рассмотрим некоторые рекомендации, которые необходимо предоставить, требования, которые следует вызвать, и некоторые из компромиссов, которые необходимо сделать, при планировании мультитенантной архитектуры.
Целевая аудитория
Статьи, приведенные в этом разделе, особенно важны для технических руководителей, таких как главный технический директор (CTOS) и архитекторов, а также менеджеры по продуктам. Аудитория также включает независимых поставщиков программного обеспечения (ISV) и стартапов, которые разрабатывают решения SaaS. Кроме того, любой, кто работает с мультитенантными архитектурами, должен иметь некоторое знакомство с этими принципами и компромиссами.
Следующие шаги
Рассмотрите различные модели аренды для решения.