Checklist for architecting and building multitenant solutions on Azure
Article
When you build your multitenant solution in Azure, there are many elements that you need to consider. Use this checklist as a starting point to help you design and build your multitenant solution. This checklist is a companion resource to the Architecting multitenant solutions on Azure series of articles. The checklist is structured around the business and technical considerations, and the five pillars of the Azure Well-Architected Framework.
Tip
After going through this checklist, take the SaaS journey review to evaluate your SaaS product by analyzing your understanding of multitenant architecture and its alignment with SaaS operation best practices.
Business considerations
Understand what kind of solution you're creating, such as business-to-business (B2B), business-to-consumer (B2C), or your enterprise software, and how tenants are different from users.
Define your tenants. Understand how many tenants you'll support initially, and your growth plans.
Understand whether you need to separate your tenants into different tiers. Tiers might have different pricing, features, performance promises, geographic locations, and so forth.
Based on your customers’ requirements, decide on the tenancy models that are appropriate for various parts of your solution.
Test the scale of your solution. Ensure that it performs well under all levels of load, and that it scales correctly as the number of tenants increases.
Apply the Zero Trust and least privilege principles in all layers of your solution.
Ensure that you can correctly map user requests to tenants. Consider including the tenant context as part of the identity system, or by using another means, like application-level tenant authorization.
Avoid antipatterns. Antipatterns include failing to track costs, tracking costs with unnecessary precision, real-time measurement, and using monitoring tools for billing.
Avoid deployment and configuration antipatterns. Antipatterns include running separate versions of the solution for each tenant, hardcoding tenant-specific configurations or logic, and manual deployments.
If you use shared infrastructure, plan for how you'll mitigate Noisy Neighbor concerns. Ensure that one tenant can't reduce the performance of the system for other tenants.
Determine how you'll scale your compute, storage, networking, and other Azure resources to match the demands of your tenants.
Consider each Azure resource's scale limits. Organize your resources appropriately, in order to avoid resource organization antipatterns. For example, don't over-architect your solution to work within unrealistic scale requirements.
Contributors
This article is maintained by Microsoft. It was originally written by the following contributors.
As a Microsoft Azure solutions architect, you advise stakeholders and translate business requirements into designs for Azure solutions that align with the Azure Well-Architected Framework and Cloud Adoption Framework for Azure.