Providing a solid base to build your infrastructure as a service (IaaS) on is as important as building your on-premise base. In this video, Sharon will explain Azure resource groups, virtual networking, and storage—the foundations of building your infrastructure. The different types and uses of Azure storage, creating virtual networks and subnets, and VPN gateways will be discussed.
- [Instructor] The trick to building a solution in Azure is planning the deployment. Just as we architect out our on-premise deployments we must do the same for our Azure deployments. Building or extending to the cloud still requires prep work. We still need to consider our IP addressing needs, our storage requirements, and who has access to what. I know, networking and storage not nearly as exciting as creating virtual machines, but to ensure your implementation is successful prepping for the deployment is crucial.
Before we get into the exciting services, like virtual machines, we need to first ensure that we have all the components ready to host these virtual machines. If you are working in the new portal you will need a resource group, if you're still in the classic portal a cloud service will be your container. You will also need a virtual network configured with IP addressing schemes, subnets, and DNS servers, a VPN gateway for connectivity, and finally, storage. In the new Azure portal you must assign a service to a resource group.
Personally I find it must easier to have my resource groups created and then start adding the services as necessary. Think of an Azure resource group as a container that holds all of the resources for a specific deployment. For example, a company may have a resource group for all the company resources and then they would have a second resource group maybe for their test and dev environment. Resource groups can be managed as a single unit, which means you could delete all those resources within that resource group with essentially a single click.
And because of that reason you're gonna wanna be aware of who has access to what resource groups. For example, a reader role let's a user view everything, but not make any changes to that resource group. Tags provide a method to associate resources to a specific group. For example, to group all the resources associated to the test and dev team you could assign a tag to that team and then assign that tag to the resources. One of the newer features in resource groups and in my opinion maybe one of the most beneficial, is the ability to see the estimated cost associated with a specific resource.
This will help you with estimating your costs and hopefully avoid sticker shock. And finally, and just again recently added, is the ability to export the resource group as a single template. After you have spent the time to perfect the resource group that entire group can now be exported as a single template, you can then customize it, and then redeploy it, saving you time and ensuring the exact build is deployed over and over again. Virtual Networks in Azure are critical.
Virtual Networks, or VNets as we call them, provide isolation between your resources. They're very similar to the VLANs on your physical network. They provide IP addressing and DNS functionality to the virtual machines within your network. Virtual Networks are also required for connectivity. Not only to your on-premise environment, but to the other Virtual Networks that you may have running in Azure. I've already mentioned what we do on-premise is what we do in Azure, and just as we do on-premise, storage resources must be allocated.
The advantage of Azure Storage compared to the on-premise solution is durability. At a minimum there are three copies of your data in a single facility. For increased durability geo-redundant storage can be leveraged. Geo-redundant storage maintains six copies of your data across two Azure regions. Storage is also incredibly scalable. Additional storage can be provisioned as required and can be accessed from anywhere at any time. You can leverage Azure Storage for files, virtual machines, structured data, messaging queues, and even just plain, simple backups.
To wrap up, before creating virtual machines I would suggest you build your resource group first and add the configured Virtual Networks to your resource groups. Just as we plan our IP addressing schemes for on-premise we must do the same in Azure. Have your IP addressing ready to go and configured in your Virtual Networks. Add in new DNS servers if you're using your own DNS servers. And if necessary, add the gateway settings for connectivity to your on-premise environment or other Virtual Networks.
Again, this makes it much easier when deploying virtual machines, since the virtual machines will now be assigned the appropriate IP addressing and other networking resources as necessary. And finally, plan for the storage requirements for the solution.
- Understanding cloud technologies
- Why Azure?
- Creating virtual networks and storage
- Using Azure Active Directory for identity management and protection
- Disaster recovery with Azure Backup and Azure Site Recovery
- Working with virtual machines