Getting the most out of Azure in your MSDN subscription

It’s come to our attention that a lot of people who have access to some awesome Azure benefits through their MSDN subscription don’t really know what those benefits are or how to really use them. So, this post is basically dedicated to going through 4 pretty fundamental things we think every developer should have an understanding of, to ensure they’re getting the most out of the Azure benefits that are included in their MSDN subscription.

  1. What is included in your MSDN subscription with regards to Azure
  2. How do you plug your development environment into Azure
  3. How to take advantage of multiple subscriptions
  4. How to migrate from MSDN Dev/Test to production (PAYG / EA) 

Cool, so first up…

1. What is included in your MSDN subscription with regards to Azure?

Here's an overview of everything that’s currently in Azure (some in preview) that you can use:


As you can see, there’s quite a lot there and there’s even more documentation online to show you how to get stuck into the goodness that is Azure. We also have heaps of hands-on-labs over at Microsoft Virtual Academy that will take you through step by step on how to set things up, but there’s also a heap of deep dive content too.

If you get a chance, you should attend the TechEd session titled What’s New in Azure by Mick Badran from Breeze. He’ll be presenting it at both TechEd Melbourne and Sydney. 

I also wanted to give you a quick overview of what the different MSDN subscription levels get:

  • MSDN Ultimate - $160/month Azure credit, dev/test instances only
  • MSDN Premium - $110/month Azure credit, dev/test instances only
  • MSDN Professional - $60/month Azure credit, dev/test instances only
  • BizSpark - $160/month Azure credit, dev/test and production instances

You can use your monthly credit on any Azure service based on your needs. You also get other discounts, please check the links above to your corresponding MSDN subscription for details on what discounts are included in your subscription level.

Any unused monthly credits don’t get carried over to subsequent months and can’t be transferred to other Azure subscriptions.

Just to give you an example of how this translates – If you have an MSDN Premium subscription, you could set up an environment like the ones I mention below and not pay a thing for it because it would all be covered under your monthly $110 Azure credit:

  • 3 VMs for 16 hrs a day
  • 80 VMs for 20 hour load test
  • 50 HD insight nodes for 10 hours
  • Up to 100 websites and DB

If you’ve got certain services/environments in mind and you want to scope out the price, check out the Azure Benefit for MSDN Subscribers page or the Azure Benefit for BizSpark Members page.

Hopefully you’ve got a better understanding now of what it is you have access to with your MSDN subscription.


Next up…

2. How do you plug your development environment into Azure?

These articles are a great place to start:

  1. Continuous Delivery for Cloud Services in Azure
  2. Continuous Delivery to Azure using Visual Studio Online
  3. Continuous Delivery to Azure using Visual Studio Online and Git

But if you want to know more, make sure you check out these sessions at TechEd Melbourne or Sydney:

Also, if you’re going to be at TechEd Sydney, Anthony Borton from Enhance ALM is delivering a session titled Build for the cloud, using the cloud: A look at Visual Studio Online.

Or if you’re just looking for a general overview of Visual Studio, Adam Cogan is also presenting a session titled What’s New in Visual Studio + ALM at both TechEd Melbourne and Sydney.

It only seems logical now to walk you through…

3. How to take advantage of multiple subscriptions

What you can and can't do -
One of the things that people sometimes get in trouble with is trying to run large or production sites from their MSDN Azure accounts.  Keep in mind that these accounts are not intended for production systems, they are intended for development and research.  So your spending is capped based on the level of MSDN subscription you have as we described above.  But you need to be sure that you don’t run small production environments in an MSDN Azure account either. 

If you need to run a production environment, set up a PAYG account or Pre-Pay account and run it there.  You can make the owner of the MSDN account the Admin of the other ones as well.  In my case under my accounts in the portal, I have two,

I can administer one, the other or both of them from the portal (new portal shown).  So make sure you aren’t using your MSDN subscription for the production workloads.

Testing subs, dev subs, CI/CD subs  -
In some cases, you might want to divide things up to the point of having different billing accounts for different aspects of your development.  You can actually have subscriptions for Testing, Development, and Continuous Integration / Continuous Deployment.  This will give you a fine grained and individualised billing option for each division. 

This is appealing from a payment angle where the department is responsible for paying its own bills, but it’s difficult for larger accounts that want one bill to pay.  Again as we saw above one person can be assigned to multiple subscriptions to manage the billing.  Keep in mind that currently they also have the ability to manage the actual services so some means of sanity must apply there to keep an accountant from stopping the product system when they think the bill is getting too high. 

You can have different levels of access though that you can assign people to as shown in this screenshot below

This will allow you the ability to have some people, say your AP team with reader access and some with full Admin etc.  Enterprise accounts with an EA capability have the ability to have an umbrella account.

Emulate pooling effectively (How do you get two MSDN subscription accounts to talk to each other) –
One of the questions I get more than any other from ISVs and organisations with multiple MSDN subscriptions is can we pool our credits?  At this point the short answer is No.  However, that does not mean you can’t take advantage of the multiple credits to create larger scale development systems. 

For example, you can use one account to create the UI layer, and one to create the Business Layer and one for the Data Layer.  You can call from one layer to the next as if they were calling across any web services style system. One accounts Web Services for example can be called from the UI of another account as if it was making any other call to any other web based web service.

If you have your VMs or other services set up in virtual networks, you can also use Vnet to Vnet connectivity to connect your virtual networks from one account to the other account, or the cloud to on premises if you have some of your systems local and some cloud hosted.

This will let you get the most out of all of your subscriptions and effectively emulate pooling.  The only area you may have problems with is if you have a massive scale requirement and need to run 500 cores for one role or deployment. But to be honest, if you can design your system to scale out across 3 VMs, or Roles, then 500 will work fine.  (Disclaimer: in theory!)

4. Migrating from MSDN Dev/Test to production (PAYG / EA)

How to change the bill 
To go from MSDN to PAYG you can just remove the spending limit on your MSDN account. However it remains an MSDN account and is still not to be used for production.  That being said, you can create your PAYG account with a credit card / invoice, and then migrate the workload to the new account.  You might want to set up resource groups to get a nice tidy package for this, and also set up Vnet to Vnet connectivity so you can transfer the images etc from the MSDN account to the PAYG account over our network instead of yours. 

Going from PAYG to an Enterprise Agreement (EA) is a bit more involved and requires you to submit a billing support request.
Step 1. Log into portal and go into billing support.
Step 2. Raise a ticket and select the option to move subscription from PAYG to Enterprise.
Step 3. Support will require subscription/agreement details and voila.

Transfer or redeploy? –
In some cases, you can use resource groups or PowerShell to just copy the VM images over to the other account and start them up.  If you don’t want to make many changes this is fine.  If you do want to make some significant changes when you migrate you may as well just redeploy from your on-site system, or your TFS / GIT repository.  You will usually do this when you do an upgrade or something has gone through on premises testing and you want to deploy to a production account instead of the MSDN account. 

There isn’t much advice here as it really depends on your situation and how you want to do it.  You can use things like Express Route to speed up the process from your DC to ours, or use the Vnet to Vnet connectivity described above to go from account to account in Azure.

Think Support –
You would think that by now this would go without saying.  But time and time again I see major customers decide they don’t want to pay for support thinking that they can just call up their account manager and they’ll fix the problem.  This is not how the world works.

When you are managing mission critical or production systems, you need to have support.  Either internal support to fix your systems and code, or contracted.  When it comes to the cloud provider, if something appears to be wrong on the cloud infrastructure, you need to be able to lodge a support call and get someone on it.

People say support is too expensive, but compare that to how much an outage would cost you.  You are in the big leagues now, you need to be up 24/7.  Don’t treat your product like a hobby.  Give it the support it needs.

Compare the response times with what you have promised your downstream customers.  Make  sure you consider this plus your response time.  When you move into production, you need to have someone you can call when things go tango uniform on you.

Now that you have the tools, and the path  forward, go out and conquer the world!