As more companies consider a cloud-only or "born in the cloud" solution, Sharon will outline the considerations for this type of deployment and some of the pitfalls. Topics covered will include selecting the right series of virtual machine, the most appropriate location, configuration options, and high availability.
- [Instructor] In some cases, you may wanna move your entire infrastructure into the cloud, and that is definitely doable. For the most part, the same infrastructure that you deploy on-premise can be deployed in a cloud solution. When you move your solution from on-premise into a cloud solution, you're essentially moving from CAPEX to an OPEX model, being you are no longer providing and provisioning and incurring the cost for that on-premise infrastructure. Now you're moving into an OPEX model, where you're paying for that solution monthly or yearly.
A cloud solution is totally flexible. You can build it, scale it, shrink it, move it as necessary. For the most part, anything you do on-premise, you can do within Azure. Azure comes with many pre-configured virtual machine templates. You can quickly deploy one or more virtual machines with a few clicks of the mouse. And the best thing with working with Azure is you do not have to relearn everything you know about infrastructure. All those best practices that you are currently practicing, you're gonna use those same processes within Azure.
Now, I'm not saying that everything is gonna be exactly the same. There will be some tweaking along the way. As you've heard me say a few times now, the trick to a good Azure deployment is the planning. This is no different than on-premise. You don't walk into an on-premise deployment with that beige box under your arm going, "Hmm, I wonder what I'm going to do today." It is the same with Azure. You go in with a plan. That really is the trick. You need to have your networking in place. Understand what your IP addressing scheme will be.
Understand will you need the DNS server. Calculate out your storage requirements. Again, no different than what you do on-premise. The advantage here is is if you need to add more storage at a later date, you can easily do so. Do you require high availability? And to be honest with you, here's where I draw the line on high availability. If you do high availability on-premise, meaning your environment can never go down, then you will have to do high availability in Azure. If you or your customers can live with a few minutes of downtime, that is not high availability, and you don't have to do it in Azure.
But that's kind of the drawing line. Everybody says, "Oh yeah, I can never be down." And then the IT firm or the Microsoft partner comes in and says, "Great, we're gonna do high availability. "Here's the cost." And then the companies goes, "Whoa." And they realize they can live with the 10 minutes that they might be down, or the 20 minutes. Next, you need to plan out your workloads. What workloads are you going to put into Azure? You're not just gonna haphazardly go, "Oh, we're just gonna throw SQL up there, "and we're gonna throw "that line-of-business application up there." You need to plan it.
You need to test your workloads. Again, no different than what you do on-premise. Take those same best practices and move them into Azure. And finally, our backups. You need to understand that yes, your storage, your virtual machines have copies. But those copies within Azure are replicated copies. This is not your backup strategy. You are still responsible for you backup strategy. Again, this is no different than on-premise. You don't just walk in on-premise, set up an infrastructure and go, oh, oh, I don't have to worry about backups.
It'll be the same thing in Azure. I'll spend a moment on networking. You need to plan your IP addressing scheme prior to deploying in Azure. You need to plan your subnets. A little hint here. If you've created a subnet that does not have enough hosts, and then you proceed to create another subnet after that, the only way you can add more hosts to the subnet that does not have enough is by deleting the following subnet, expanding the one that is short, and then recreating.
If your solution requires connectivity to on-premise, and in most cases, they do, VPN will be required. That VPN will have to be on-premise. Microsoft provides a list of recommended VPN appliances. Not only do you have a VPN appliance on-premise with a static IP, you are also going to have to have a static IP within Azure. This all falls under networking, as you will have to create the gateway subnet and generate the IP address. And finally, DNS.
I know this is more of a workload, but I like to keep it under networking. The reason being is that you have to include the IP address of the DNS server within the networking module. The IP address of the DNS server within Azure provides a pointer back to that DNS server for authentication to Active Directory. You will have to plan for storage. And with all the cloud providers, it is a race to the bottom right now. Storage, for the most part, is fairly inexpensive. How much storage are you going to need? And again, what type of storage are you gonna require? So how much? You're gonna provision storage not only for your virtual machines, you may require it for an SMB file share.
You may require storage for media or for videos or for streaming. Again, very similar to our on-premise environment. Calculate out your storage needs and then build it appropriately. And then what type? In Azure, we have four different types of storage. The two I'm gonna focus in on here are geo-redundant and locally redundant storage. Locally redundant storage is three copies of your data in one data center. And geo-redundant storage is six copies across two different data centers. Again, this storage is replicated storage.
It is not backups. So if you're playing with a virtual machine at three in the morning and a little tired and you hit the wrong button, and your virtual machine goes poof, that poof is replicated across those replicas. The next stage in our planning is evaluating our workloads. What workloads do we wanna put up in Azure? If your moving from on-premise into a completely cloud-only environment, as of today, you're gonna need a domain controller. And when I refer to a domain controller, I'm referring to a Server Active Directory.
Again, this does not change from what you do on-premise. If you're running Server Active Directory in Azure, you will have a DNS server. You'll have to provision your DNS servers, and again, going back to networking, once you have the IP address of that DNS server, that IP address needs to be added into the networking component. One of the more popular applications within Azure that I have seen is running Remote Desktop Services. For those of you who have terminal servers or have run Remote Desktop Services, this'll be a very familiar setup for you.
There's actually already templates already built in Azure for you to go ahead and deploy this. For those of you who may not be aware of what a terminal server or Remote Desktop Services is, this is a way where we can access applications securely on the server from remote access. The applications are basically streamed to that device. All the data is still maintained on the backend on that server. There are some licensing issues around this, so please be aware of those if you do decide to Remote Desktop Services or terminal services in Azure.
One thing I wanna make very clear is you cannot do VDI or virtual desktop infrastructure in Azure. Yes, there are templates to run Windows 10 operating system within Azure, but the licensing clearly states this cannot be used for production. And finally, what operating systems, roles, and features are you going to run within Azure? For the most part, most Microsoft operating systems are supported within Azure, just are most roles and features, but not all.
For example, you cannot do DHCP within Azure. The role isn't even available for you to install. And here's a pro tip for you. Several months ago, Microsoft put out a very quiet announcement that it would now support Server 2003 R2, the 64-bit version of Server 2003. This means you can run a 2003 R2 Server operating system on Azure and it is a supported operating system.
You do not have to tweak it to make it run. What this does not mean is that Microsoft is not patching that operating system. Server 2003 is at end of support and you still run the risk of running that operating system, whether that operating sits on-premise, in Azure, in Amazon, or anywhere else. Microsoft still is not patching that. Big difference between hosting the operating system and supporting the operating system. As part of your planning, you're gonna wanna look at the cost of the VMs.
When comparing on-premise to cloud, it really is an apples to oranges comparison. On-premise, not only are you dealing with the hardware, you're dealing with the operating system cost, you're dealing with the heating and cooling, you're dealing with the patching, and everything else that's associated with that VM running. In Azure, you're only paying for the consumption of that virtual machine. The licensing is included. When you're doing a cost compare, keep that in mind. Just because your virtual machine is sitting in Azure, does not mean you can ignore it.
You still have to patch it. You still have to provide updates. You are still responsible for that virtual machine. If you're moving from on-premise into Azure, do you have somebody who's gonna manage all those patches and updates for you? If you're a new company, you may be looking at a complete born-in-the-cloud solution. In that case, who is gonna handle those patches and updates? Something to be aware of. You're going to need to right size your VMs. By this, I mean select the VM for the greatest workload that it could handle and then scale back.
Depending on the VM skew that you choose, you may not be able to scale up. If that is the situation where you find yourself stuck, you're going to have to delete the VM and recreate it. It's easier to overplan it and scale back than it is to underplan it and try to scale forward. Another consideration is your egress charges. Be aware of charges for moving your data out of Azure. Maybe it makes sense to put your entire infrastructure in Azure and run everything there.
If you are gonna have a lot of data coming back and forth, be aware that there will be charges for that. The new MAPs toolkit will help estimate some of these charges for you. If you're just starting out, monitor this one closely until you have a really good sense of what those egress charges are going to be. If you find those egress charges are a little higher than what you anticipated, go back to the planning stage. Architect it out. You may find that moving certain workloads into Azure will reduce these egress charges.
And finally, bandwidth restrictions. Always check your connectivity, not only on-premise, but your connectivity into Azure. I live out of Canada, and we don't have the same infrastructure per say as the U.S. In some cases, some companies I've worked with, their internet providers are using point-to-site connectivity. In those cases, those companies, they cannot look at a cloud solution. They just don't have the bandwidth to support it. And in some of those cases, even email can be a challenge.
My advice, when you're looking to move into an Azure solution or any cloud solution, test it. Do a proof of concept. Build it out after you have tested it and sure that the experience is what you anticipated on-premise. With the proper planning and architecting, your Azure solution could be the replacement for your on-premise infrastructure.
- 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