How to Start with Dev/Test Environments in Microsoft Azure
Contents
Introduction
If you are starting to do Dev/Test on the cloud, but you're new to Microsoft Azure. You may have some questions:
- How do I get organized in Azure?
- How can I see what's happening with Azure services in my subscription?
- How do I manage my spend with Azure?
- How can I control access to resources inside of Azure?
- How can I make sure my apps are being developed securely in the cloud?
This post is a guide to hit the ground running. Note that this post assumes a greenfield dev/test environment using the new Azure Resource Manager deployment model. Azure services deployed with the older Azure Service Management (ASM) model does not expose many of the dev/test features mentioned in this post. There are extremely few reasons to use ASM for new projects. Note that when you're are using the Azure Portal, you'll see resources associated with ASM labeled as "(classic)". Avoid classic VMs, Storage Accounts, Virtual Networks, etc for your new dev/test environment.
Resources
Think of a resource in Azure as distinct billable units. A resource in Azure can be different types; for example a database, a storage account, a VM, or a Web app. From a billing and permissions perspective, a resource is an atomic unit; it cannot be reduced further. Resources are grouped into Resource Groups. You deploy resources into Azure Subscriptions. Subscriptions are members of Azure Accounts. Here's a breakdown of how these elements are organized and relate to each other:
| Accounts | Accounts are containers for subscriptions. Every Azure customer gets an account. Enterprise Azure customers can have multiple accounts. Accounts contain subscriptions. |
| Subscriptions | Subscriptions are a collection of resources. Subscriptions belong to only one account. When a subscription is created, a service administrator is assigned to the subscription with full admin rights. It's important to understand that the account owner is not necessarily the subscription admin. This helps keeping the financial management and the technical management of Azure subscriptions as separate concerns. The business manager may want insight into the spending pattern of Azure subscriptions, rolled up to the account level, but may/should not have access to the actual services deployed. There are several types of Subscriptions available, see the link for more information. |
| Resource Groups | Resource groups are a container for various resources. Resource groups can only belong to one subscription. You can create resources and resource groups with the same name across subscriptions (they don't need to be globally unique), but there is no affinity between them across subscriptions. A resource group lives in a single Azure datacenter region, but the resources inside of it can be in any location. For instance, my website resource group lives in the East US, but it contains Azure Web apps deployed to both East US and West US regions. The group location is just a logical construct and has no physical impact on the resources inside of it. Resource Groups can contain different kinds of resources: For instance, a resource group can contain a database, VMs, and a network. Resource groups only contain resources; Resource Groups cannot be nested. |
| Resource | A distinct billable unit for an Azure service. A resource can only belong to one resource group. A resource is an instance of a Resource Provider. The providers details what the resource type is, the properties on the type and what versions are available. |
This logical separation of resources into groups, subscriptions and accounts is a way to organize according to one dimension. There are other ways you can organize resources that are cross-group or cross-subscription.
| Tags | You can tag resources with an arbitrary set of key-value pairs. This allows you to create associations between resources even though they live in different groups or subscriptions |
| Location | Resources can live in different Azure datacenter region, despite being part of the same group or subscription. A database can live in the West US, while a geographically load-balanced set of web sites live in West US, Central US and East US. These can all be in the same subscription and the same resource group. When deciding where to locate your dev/test resources, it may be useful to test the latency between where your developers and testers are and the various Azure regions. There are tools available to help you with this. |
In addition to organizing your resources, you can also dictate who can access resources and how they are created.
| RBAC | RBAC is Role Based Access Control. For each resource, you can assign different levels of permissions to different users and groups in your organization. You can use pre-built roles or define your own. You can assign roles at the resource level, or to entire resource groups or subscriptions. In the case of resource groups and subscriptions, roles are inherited by the underlying resources. |
| Azure Policy | You can write specific policies about how resources are created. You can enforce rules like required tagging, naming policies or location choice. |
Recommendation: If you're just starting in Azure, don't create RBAC or Policies yet. Give everyone on the team a chance to explore Azure and get comfortable with deploying different resources. Give your developers a chance to discover native Azure solutions to help them meet their needs. Once a cloud architecture for your apps has been decided upon, then it makes sense to start locking down the dev environment in preparation for production.
Resource Groups vs Subscriptions
Now that you understand how to organize our resources in Azure, how should you move forward with our dev/test environment? If you're developing a single app or you have a single team that will be working with Azure, it makes sense to keep the development in a single subscription. But what if you have multiple teams working on multiple projects? Should they all be in the same subscription with separate resource groups or should they each get their own subscription? There are some factors to consider when making this decision:
| Factor | Separate Subscription | Resource Groups |
|---|---|---|
| Apps have nothing in common | Use separate subscriptions if resource limitations may become an issue (Public IP Addresses, Storage account instances, etc). Use separate subscriptions for spending caps. | Use to Reduce costs |
| Applications Share some tiers (UX, App, and/or DB) | A good option, reduces stepping on toes; clear separation of concerns, but may require automated updating of environments to keep changes from either team in sync | Challenging option, makes resource ownership less clear |
| Applications have dependencies on other applications | Can work well if the depended-upon apps can be deployed into the dependent subscription. Or, if the depended-upon apps deployed in other subscriptions are reachable via Internet | Easier to implement if the Azure resources in each solution are not shared (and can be assigned to separate groups). |
| Apps need to be on the same VNet (see "Developing with VNets" section too) | A site-to-site VPN can be established between VNets across subscription. Or, a 3rd subscription can be created to host the VNet and other shared resources (AD Controller, DevOps orchestrator, etc). | This works, but you can use RBAC to set up a shared VNet and give each team contributor access to it so any changes need to be agreed upon. |
| Apps will be managed andmonitored tested | Dashboards are currently subscription-specific so it's hard to see all resources under one pane of glass | Creating dashboards is easier |
| Enterprise Azure Portal | If you've signed up for the Enterprise Azure portal (via a Microsoft Enterprise Agreement), creating and managing multiple subscriptions across different organizational departments can be required. Creating separate subscriptions | A better option for smaller teams |
Recommendation: If everyone is new to Azure, start off by giving every team their own Azure subscription so nobody is stepping on anybody else's toes. If teams need to work together, they will eventually self-organize and choose a primary subscription to work in.
Developing with VNets
Developing applications on VMs that need to talk to other applications on a VNet can present some challenges:
- Who owns the VNet?
- What port are allowed on the VNet?
- What subnets can talk to what subnets?
- What VMs can reach the Internet?
- What VMs can be reached by the Internet?
- Can I connect my VNet to another VNet?
To solve these challenges, Azure provides several capabilities:
| Network Security Groups (NSG) | These are rules that apply directly to VMs on a VNet or to a Subnet (and all the VMs inside the VNet. There are inbound and outbound rules. For each rule you can define source and target IP address ranges, ports and protocols. Multiple rules can be applied to each NSG with precedence. |
| Load Balancers | Internal Load Balancers and External Load Balancers for sending requests to a defined set of VMs or subnet. Rules on the load balancers can be defined per protocol and port. External Load Balancers can have NAT rules to route to specific machines. |
| Application Gateway | The Application Gateway has layer 7 load balancing features like cookie-affinity and SSL termination. |
| IP Addresses | Static Public IP Addresses and Static Internal Addresses can be assigned. Public IP addresses come with a domain name. You can use Azure DNS or set up your own |
| VNet-to-VNet | You can create connections between VNets in the same subscription or across subscriptions |
If you're developing apps in separate subscriptions, you can create a VNet-to-VNet connection so that the apps can talk to each other but not interfere with either's VNet settings.
If you're developing apps in the same subscription you can use resource groups to separate the development environments but also create a separate resource group to manage the VNet. That way each app can attach VMs to the VNet, but they can't alter the configuration or NSGs. For an example of how to do this, check out this blog post: https://blogs.technet.com/b/ad/archive/2015/10/12/azure-rbac-is-ga.aspx
Governance
Once you're up and running with Azure, how do you manage and control the environment? How do you know what's happening in your subscription(s)? Azure has several options:
| Dashboards | Many Azure resources come with counters. You can build and customize graphs based on these counters in the Azure portal. You can build a dashboard of these graphs and counters on your Azure portal homepage. You can build multiple dashboards and share them with other users in the subscription. |
| RBAC | Use RBAC to make sure that only the right users have access to the right resources. Instead of assigning roles to individuals, use Azure AD groups to make management easier. |
| Azure Policy | As users begin to create various resources, it may be difficult to keep track of them all. Policies can enforce naming conventions, require tagging, limit skus that can be used and regions where resources can be deployed. Policies can help the service admins keep uniformity and transparency within the subscription. |
| Security Center | Even though you're doing dev/test, Azure Security Center is a free advanced capability that will analyze your resources and make security recommendations for you. Catching these before production can help you make sure your apps are secure when they reach your customers. |
| Subscription Spending Limits | In the account portal, where you see all your subscriptions, you can set spending limits per subscription. When used with policies, subscription soft limits and RBAC, you can make sure that your Azure spend is predictable and when exceptions arise, you have a transparent process for handling it. |
| Subscription Soft Limits | Every subscription comes with soft limits for the amount of resources you can deploy. These limits are there to protect both you (from accidentally spending more money than expected) and Azure (to maintain predictable capacity requirements). If you need to raise your limits, you can make an Azure Support request. |
| Network Security Groups | Use NSGs strategically to make sure that apps are built with network security in mind. |
| Azure Trust Center | If your applications need to comply with regulations or respect data sovereignty laws, the Azure Trust center can guide you on what Azure services are compliant with regulations. Don't ignore these during dev/test so that you build an application that is compliant in production. |
| Azure Dev/Test Labs | Azure Dev/Test Labs is a great resource for creating and managing test environments. You can set up additional quotas and policies within the dev/test lab. You can build VMs with reusable templates that match your dev/test spec requirements. To save money, you can automate shutting down those VMs at night when your dev team goes home. |
Tools
There are many ways to interact with Azure when building your dev/test environment. Developers should be aware of all the ways you can deploy resources to Azure. While you can use the portal to deploy resources, it's important to understand what tools are available for automating these environments.
| Portal | Use the Azure portal for manually deploying Azure resources. |
| Powershell | Azure can be automated with Powershell Cmdlets. |
| Cross Platform Command Line tools | If you're dev environment is not Windows, you can use these tools on Mac or Linux workstations. |
| REST APIs | The Portal, Powershell and CLIs all use the REST APIs under the covers and you can too! |
| ARM Templates | When you have a dev/test environment defined you can easily export it as a JSON-based template. You can deploy that template as a repeatable process. You can tear down the entire environment every night and automate rebuilding it every morning. You can store the JSON in source control so it's part of your app development process. You can also share the templates and have it deployed into different subscriptions (think dev, test, qa, staging, production). |
Hopefully this will be a handy guide to get up and running with Dev/Test on Azure. If you have any feedback or further questions, please leave a comment or reach out to me directly.