Azure Resource Groups, App Service Plans, and SQL Elastic Pools. These terms aren't very well understood by most developers, but it turns out that they're easy-to-learn ideas and knowing how to use them can save you both time and money.
Resource Group
Every time you add a resource to your Azure account, whether it's a virtual machine, a database, or any of the other hundreds of resources Azure offers, you have to assign the resource to a Resource Group, but what is a Resource Group? A Resource Group is nothing more than a logical grouping of Azure resources. The Resource Group itself doesn't use any resources and you don't get billed for it. It's just a list. The Resource Group doesn't have to be in the same location as any of the resources in it. Technically, it doesn't matter which resource group you put resources in and most Azure demos tell you to just make one up and leave it at that. So what good are Resource Groups? What's the RIGHT way to use Resource Groups?
You put all of the resources for each project in the same Resource Group. A standard here at CODE Magazine/EPS is to name the Resource Group after the project. There are a couple of exceptions to this mentioned below, but this is a great rule of thumb.
Naming the Resource group after the project is a good rule of thumb.
It's easy to see all of the parts of a project on one screen and to see what you're being billed per project. What if you have resources that aren't in the right Resource Group? You can move resources from one Resource Group to another using the Azure portal. You can even move resources to a Resource Group in another subscription, as long as you can see both subscriptions in the portal under the same login. This used to be impossible. Later it was possible but a gigantic pain. Now it's pretty easy, as shown in Figure 1.
App Service Plan
You can think of an App Service Plan as a logical IIS Server instance. Treat it just as you would an IIS Server. You can run a whole bunch of App Services (websites, Web jobs, Web API services) on the same App Service Plan. You get charged by the App Service Plan, not by the App Service. Changing the pricing tier of an App Service Plan changes every App Service on that plan. This is one place where you might deviate from the rule of-thumb for Resource Groups. You may want to share an App Service Plan across several projects versus paying for an App Service Plan for each project. Of course, the lowest pricing tier is free, and it doesn't cost any more to have 30 free App Service Plans than it does to share just one. But, if you need or want better performance or features than the free tier offers, you can share the cost of a single App Service Plan across many App Services.
SQL Elastic Pool
A SQL Elastic Pool is a special resource attached to a regular Azure SQL Server instance. Like an Azure SQL Server, the SQL Elastic Pool is a logical resource, not a physical one. It's really nothing more than a list of databases and settings that can have SQL databases assigned to them. The key difference is that on an Azure SQL Server, each database is charged and scaled separately. An Elastic Pool server shares resources (DTUs) and costs across all databases on the server. If you have four or five Basic SQL Databases at $5/month, this won't help you much, as the minimum pool size is 50 DTUs. If you're using 50 or more DTUs, you might be able to save some money with an Elastic Pool.
CODE Magazine/EPS recently had a client running three PRS1 instances, which is 125 DTUs each. We saved them money by creating an Elastic Pool at PRS2, which is 250 DTUs. All three databases share the 250 DTUs and pricing is similar to a single 250 DTU server. Because it would be extremely rare for all three databases to require high DTU rates at the same time, the perception of the client's users is that each database is running about twice as fast as it used to while costing 1/3 less than it used to.
The users only notice that each database feels like it's running twice as fast as it used to.
Summary
A few minutes familiarizing yourself with some common Azure terminology can make life a bit easier and even save you some money. Those included here are simplified explanations and not 100% complete, but they're plenty to help you be more productive. if you're the curious type or you wind up using these ideas extensively, I recommend reading the exceedingly long-winded, but complete and accurate versions in the documentation. You'll find even more useful information there.
