CODEWITHSUNDEEP
azureazure-sql-database
James
James

Reputation: 1188

Handling multiple deployments on Azure

What is the most graceful way to handle multiple deployments on Azure?

We are set to have multiple, unrelated customers. Each customer needs their own separate database and since we don't have multi-tenancy up and running, we have to also give each customer their own azure application too.

What is the best way of handling this? Is it to make a new account for each user and track each account? Or is it to have a master account? If so, how would I do that?

Upvotes: 1

Views: 526

Answers (3)

David Makogon
David Makogon

Reputation: 71028

Multi-tenant apps are not always straightforward, as you need to carefully look at things like authentication/authorization, resource utilization across tenants, metering across tenants, etc. Plus, if your app has a failure condition, all tenants are impacted, which could impact more than one customer's SLA. Then there's the database schema: You can stick with one db per tenant, or create a single db with some type of tenant ID field.

I really agree with the other answers, in that a multi-tenant app is the desirable approach, especially in terms of cost management and code base consistency. However, assuming you stick with a single-tenant app:

  • Create a separate deployment for each customer.
  • If you are managing the account and billing the customer, go with a single subscription until you reach capacity. No advantage to multiple subscriptions.
  • If the customer is deploying and maintaining the app, let them use their own subscription

You have a few advantages with a single-deployment model:

  • Ability to deploy a patch / customization to a single customer instead of the entire customer base
  • Unambiguous customer billing: Whatever the deployment costs, that cost is 100% applicable to a specific customer.
  • Ability to scale up/out to meet a specific customer's traffic needs
  • No risk of one customer abusing the system and starving out other customers

Upvotes: 1

Steve Morgan
Steve Morgan

Reputation: 13091

Until you've implemented an proper multi-tenant variant of your application, you could either use a separate subscription for each customer or as an interim, use multiple roles within a single subscription.

The biggest issue with multiple roles is that when you add a new customer, you'll have to redeploy. You can use multiple upgrade domains or stage-and-VIP-swap to avoid downtime, but it's not an ideal pattern. Not least because unnecessary deployments are risky and it really complicates your configuration management process.

In the short term, I'd stick to separate subscriptions. The total resources that are consumed, and hence the cost, won't be very different from running multiple roles within a single subscription. It will also make metering and billing easier. I just hope you're talking about a handful of customers, not thousands!

In the meantime, you can concentrate all your efforts on moving to a full multi-tenancy model. I'm in the process of writing some blog articles about just that, so if I remember, I'll update my answer when I'm done.

Upvotes: 3

Igorek
Igorek

Reputation: 15850

I hate to say this, but I think you'll have most success with getting multi-tenancy to work in some capacity. Having a separate database for each customer and then having some sort-of broker that delegates which databases belongs to which customer is not a terrible idea and is still multi-tenancy. But maintaining a single code-base and a single deployment for all your customers is key when in Azure. You will really not like the Azure experience (or frankly any other environment) if you attempt to deploy and run a separate code base for every customer.

Sorry, HTH.

Upvotes: 1

Related Questions