Before jumping into a cloud solution, understanding what can and cannot be done is imperative. In this video we will outline some of the considerations to consider, including service level agreements (SLAs), costs, and bandwidth constraints.
- [Instructor] Just as with any service, there are gonna be limitations and considerations you must be aware of. It is important to understand exactly what you are, and more importantly, what you are not receiving with your service. Just as important, you must evaluate if a cloud solution is even a viable option for your company. Here are some common considerations you must consider before moving to a cloud solution. The first thing I'd recommend that you look at will be your connectivity. First, you must ensure your on-premise infrastructure is current and is able to support that new cloud deployment.
For example, a company with an aging 2003 infrastructure, which, on a side note, you should be getting rid of very quickly, would like to move to Azure. The Azure deployment works as expected. But when they connect to the solution from on-premise, the experience suffers. And this is because their network is still 2003. They need to upgrade that first. Another consideration is the equipment required for that connectivity to the cloud solution. For example, a dedicated VPN gateway may be required to connect to the Azure solution.
But be aware, before you go and purchase any VPN gateway, there are limitations to the specific devices, as well as your operating systems. Always understand the restrictions that may be experienced with a VPN device. And finally, bandwidth, in my experience, this tends to be the biggest limitation of an Azure deployment. The bandwidth required will be dependent on the Azure service that is being leveraged. I would suggest you always test your deployment prior to moving to a production environment.
To help determine your connectivity requirements, there are third-party tools available. And for those of you who are familiar with it, the Microsoft Assessment and Planning Toolkit, or MAPS, now includes a bandwidth estimator. The last thing you want in your implementation is to have sticker shock at the end of the month. You must be able to predict your costs. Azure is a pay-as-you-go service. So, understanding the cost associated with the deployment will help protect you from that sticker shock. Outside of the standard operating costs for Virtual Machines, and storage, and networking, there may be some unexpected costs.
These costs could include the egress or outbound data charges. Microsoft does not charge you to move data in the Azure, but they do charge you do move data out. And this cost can come and bite you in the butt at a later date if you're not aware of it. For example, I've worked with some companies that have had file servers in Azure. Sounds like a great solution. Except, what they were using these file servers for was file shares for CAD files. And they were pulling these CAD files down every day to work on them. And then sending them back up in Azure, and then pulling them back down again.
They incurred outbound data charges that they were not expecting. Really, the trick to Azure, and you'll hear me say this over and over again, is architecting and planning it. Really, that is the trick. So, be sure to factor in any of those outbound or egress charges that may occur. Another cost, will be your existing on-premise infrastructure. If we go back to what I just talked about, that aging 2003 infrastructure, if your infrastructure is 10 or even 12 years old, you're going to want to upgrade it to ensure the best possible experience moving forward.
Service level agreements, this is something you may not have considered before jumping into cloud. Sometimes, we assume that because the workload is in the cloud, that it's always available and backed up for us. That may not necessarily be true. For example, when provisioning Virtual Machine workloads in Azure, the SLA clearly states, for all Internet-facing Virtual Machines, you must have two or more instances deployed in the same Availability Set. We guarantee you will have external connectivity at least 99.95% of the time.
This statement clearly indicates that you need two Virtual Machines configured. And finally, know the limitations of that SLA. For example, going back to our Azure Virtual Machine model, if you misuse the service, you're in violation of that SLA, and Microsoft does not have to adhere to it. One of the reasons we would like to move to Azure is to move some of workloads there. That makes perfect sense. And moving your workloads to the cloud can be an exciting thing. But, sometimes, when we move them without understanding if they are even supported.
Most of your modern applications will be supported in a Virtual Machine. Therefore, they should be supported in Azure. But legacy applications may not have the support. Let's go back to our example of Server 2003. And if I haven't said it already, you should be getting off of it, now. So, you have a 2003 application that's running. You want to move into Azure because you want to get rid of the 2003 Server. Yes. What you may find, in all likelihood, is that that 2003 application will not run properly in Azure.
Also, in that case, if there's a problem with that application, you may not be able to get support for it because it will not be a supported workload. Not only do the applications need to be evaluated for cloud compatibility, the operating systems also need to be supported. Luckily, in the case of Azure, most 64-bit Microsoft Server operating systems are supported, as well as several flavors of Linux. For a complete list of supported operating systems, follow the link that's provided to you at the bottom of this screen. Non-supported operating systems may be run in a cloud service, with or without modification.
But, typically, these will not be covered under that SLA. There are a couple tools that'll help you determine whether or not your applications and operating systems can move into Azure. First, there's the MAPS Toolkit. And the Azure Virtual Machine Readiness Assessment Tool can help you determine if your on-premise environment can be moved to Azure. You should always be aware of the limitations for a subscription or the service before moving your entire infrastructure into Azure. Again, please consult the Azure service limit webpage before implementing a production solution.
This page will outline the default limits and maximum limits per service or subscription. If these limits do not meet your needs, you will either need to have these limits increased, or you're gonna have to modify the architecture itself. And finally, data protection, just as you have to protect your data that is on-premise, you also have to protect your data in Azure. For example, if you are running a file server in Azure, your files still need to be backed up. You are responsible for that.
Microsoft is not. Your Azure Virtual Machines are durable. But this doesn't protect you against a bad patch. Or worse, you know that fat finger delete? You need to protect your Azure Virtual Machines. Be aware of what the recovery options are per tier. The last thing you wanna do is be in a situation where you cannot recover data because the assumption was made that Microsoft was backing it all up for you. As I have already said, the trick to moving into Azure, is architecting or planning your solution before jumping right in.
Know the most cost-effective methods for the solution. Understand those limitations and evaluate other Azure offerings. There may be another option available to you. And just because we're in the cloud doesn't mean we don't test our solutions from end-to-end. From networking to connectivity, to the user experience and the workload behavior, we need to ensure the solution is acceptable before going into production. And finally, monitor the solution. Changes, such as increase in workloads or traffic, can affect your costs and your performance.
Before jumping into our Azure solution, you should be aware of the limitations for a subscription or the service that you're using before moving your entire infrastructure into Azure. Please consult the Azure subscription and service limits, quotas, and constraints webpage before implementing a production solution. This webpage will outline the default limits and the maximum limits that are available per service or subscription. If these limits do not meet your needs, you will either need to have these limits increased, or you may have to modify your architecture.
- 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