ContosoAssets - Please see my other sample to understand how marketplace integration works.
I am not currently working on this sample to keep it up to date. Please see my other sample to understand how Marketplace integration works.
This sample intends to demonstrate how to integrate an existing solution to Azure Marketplace to publish it as a SaaS offer.
The multi-tenant solution uses its own identity management for managing the customer users. The users a can track their company's assets. The solution keeps track of the usage, and checks it against the plan the customer signed up for.
To run
- Register a multi-tenant application for landing page and another application for API interaction on Azure Active Directory
- Modify the appsettings.json files with the new application's App Id and App Key
- Run docker-compose up
Please see the related section on my marketplace REST API client implementation for an overview of the integration concepts.
I have worked with various teams and helping them plan, architect and develop multi-tenant SaaS solutions over the past many years. There are of course many other pillars for building successful solutions, however, I'd like to focus on the multi-tenancy aspect. I would like to emphasize that my discussion points in this section are generic, and not particular to Azure Marketplace integration.
I can distill my learnings in the following perspectives.
- Customer onboarding, provisioning and tenant boundaries
- User identities, user management and realm discovery
- Usage metering
- SKU management
The natural implication of a multi-tenant solution is to have tenant boundaries. Boundaries imply groups of resources per customer. Customer onboarding and provisioning refers to the overall activities for drawing the boundaries and allocating resources as necessary for a new customer. Let's take the simplest example of a three tier solution. Let's assume no branding on the UI layer, and fully shared business layer. This brings us to the data store. We can talk about tenant boundaries in a number of ways:
- Share tables, where customer data is identified by values on a column
- Share database, a separate table for each customer
- Share server, a separate database for each customer
- Share platform, a separate server for each customer
As you can notice, creating the boundary is a major aspect, but provisioning (allocating) resources for customers depends on many other aspects of the solution, such as scalability, security concerns etc.
The solution should use an identity provider (IP) such as Azure Active Directory, or any other user management solution to identify a user, and map the user to a customer, as well as management of the users who can use the solution for that customer.
The solution should track the usage of the solution features. I recommend metering anything you can meter, regardless of their relevance to offered SKUs. Such metering can give you valuable information how your solution is used, and monetize the components as necessary in the future. Metering and instrumenting the usage will give you opportunities to identify areas where you can attract more customers, and monetize your solution better.
The solution should model the usage limits per resources and map them to SKUs. The metering data then can be used to check against the resource usage limits, and determine upsell opportunities, as well as keeping the customer within their subscribed SKU boundaries.
Secrets such as API keys are managed through "dotnet user-secrets" command. For example, to set the value for "FulfillmentClient:AzureActiveDirectory:AppKey" use the following command:
dotnet user-secrets set "FulfillmentClient:AzureActiveDirectory:AppKey" "secret here"Please see the user secrets documentation for more details.