What does a business need from Azure?
Creating a new Microsoft Azure deployment is a relatively straightforward process. Here’s a straightforward setup guide available through Microsoft that covers the basics. However, the important work for a business to prioritize should happen before someone performs those steps within the Azure portal. In most organizations, it’s far easier to create or add something than it is to change it or remove it. All the cloud service providers are fully aware of this natural trend in business. It surfaces as a hesitancy to curtail or eliminate IT expenditures out of concern that something might be adversely impacted.
This article is intended to help an organization start off every Azure deployment from the right footing. We will focus on the general decisions that a business owner or decision maker needs to make before a new server is setup. Keep this checklist handy and make sure you have solid decisions finalized on these 5 topics before you launch into any new cloud venture!
1. Anticipated Lifespan
Businesses typically request a new server, or some compute power or storage, for only one of three reasons:
- Piloting or testing a new initiative
- Building out a new system
- Upgrading an existing system
It’s critical to determine in writing the measurable goal and intention of any pilot or test system before it is launched.
The plasticity of the cloud can easily allow for goals to creep or shift, and resources to be tweaked. This should be strongly resisted by setting a clear lifespan for any pilot or test system. This can help reduce cybersecurity risks, especially since abandoned or gently used test systems that are integrated into your network or tenant can be exploited by hackers. Additionally, you can better keep costs down by both restricting pilot or test systems to a short lifespan. Nearly any pilot system will be at the most expensive “pay-as-you-go” pricing tier, so you need to keep a close watch on these systems. These test systems are also ripe for setting strict hours of operation for further savings, which we’ll discuss more in a later portion of this article.
If you are building out a new system, you likely have some combination of knowns and unknowns. Plan on the first year of any new system in Azure being set at a 1-year reservation to capture about 25-50% savings off of pay-as-you-go fees, but allowing you some flexibility to make adjustments and settle into a good predictable capacity commitment based on data and trendlines you can review towards the end of the first year.
If you are upgrading an existing system, especially a system that is proven to be well-integrated into your business, you can save considerably by requesting a long-term commitment (3 years, typically). Nearly every system that is being upgraded within Azure, or transitioned through the upgrade process to Azure, should ideally have a 3-year reservation. Your organization can save as much as 80% off of the pay-as-you-go rates if you agree to a 3-year reservation.
One thing that is important to clarify before we begin: Azure systems are not automatically going to scale based on needs unless you configure something called autoscaling. Any system that is going to dynamically adjust based on workloads is called an “elastic” system. Most businesses are only going to make occasional and manual adjustments to their systems in Azure, largely because the complexity of anticipating loads and the time it takes to analyze metrics and create autoscaling rules is non-trivial.
A decision-maker needs to start thinking about the scalability needs of the system prior to it being deployed.
Does the workload of the system change during a 24-hour workday, or on weekdays or weekends? What do we think peak load or usage will be on the system? What resources do we expect to become constrained first over time, such as storage, network bandwidth, or compute?
Most of the time the concept of scalability of a specific system considers only vertical scaling, or adjusting specific resources up or down on the system, such as increasing storage or RAM capacity. However, you should also consider whether the system might need horizontal scaling, such as adding or removing copies of itself?
Document expectations related to scaling and make educated estimates about what you’ll need over time for the Azure resource. Also try to anticipate what metrics you will need to see to help determine whether or not you will need to make adjustments over time, as these will be data that you want to get regular reports on.
Azure is a global collection of data centers, over 200 world-wide in over 60 defined regions. Any given region, like “US East”, is actually a collection of data centers in a specific area. Whenever you deploy any resource in Azure, you need to select which Region you intend that system to reside in. There are options to setup automatic replication and failover to other regions, but for most of your Azure deployments you are going to need to select a single Region to deploy your asset into.
The primary factor you want to think about when selecting your Region is whether you are deploying something that will be primarily used directly, or if your Azure system is more for a backup or failover. If you are deploying a resource that you intend your staff or customers to use directly, then deploy it in the Region that is the closest to your heaviest users of that resource. This will reduce latency and improve the end user’s experience. There’s a terrific list of the locations for each data center (limited to only showing the State that it’s in within the US) available here.
If you are deploying your Azure system as a failover or backup, then you likely want to choose a Region that is within your country, but far enough away that you get some additional georedundancy benefits.
If you have regulatory or compliance considerations, you also need to make sure you choose which Region carefully.
If you have data that should not leave the US, you should not pick a Region in Europe or Asia, for example. A good business decisionmaker will know to ask up-front before deployment if there are any compliance concerns or regulatory reasons to pick a specific region.
4. Operating Hours
One of the most powerful features of Azure is the ability to configure work hours and service hours for your systems. Azure also has tools that can help you forecast or predict service needs, but you won’t have the benefit of these pre-deployment.
As a business decision-maker, you can prompt stakeholders to start thinking about how much of the 168-hour workweek this server really needs to be operating at full capacity (or at all). When you think about what your business needs in a typical 8-5pm Monday-through-Friday week from a server, chances are there are minimal and potentially zero requirements to keep the resource running outside of normal working hours. If you only ran a system for 50 hours/week (allowing it to run for 10 hours/day Monday-through-Friday), you can literally save up to 70% of the costs of running a specific resource. Even if you just didn’t have the system running on the weekend, you could save close to 30%. And does your system need to run on holidays?
Start your deployment team thinking early about when the resource will really be used. Encourage your team to set up Azure’s Service Hour templates that you can apply to your upcoming deployment. These templates can help you potentially fully power down or just reduce the resources on your Azure setup during off-peak hours. This can result in massive long-term savings, as well as further reinforce to your team that you don’t intend them to work on weekends and holidays!
Your finance person or team will appreciate any time you prioritize thinking about costs before incurring them. When it comes to cloud computing resources like Azure, it’s very easy to be surprised by costs. Thus, it’s important to go into any new deployment with a clear spending plan. There are multiple online calculators for determining what your estimated monthly costs will be for various configurations and designs, so direct your IT team or Managed Services Provider (MSP) to give you a reasonable assessment of what your upcoming Azure deployment is likely to cost.
Setting a budget is more than just determining the expense, but also looking to what your returns will be as well. Will you potentially profit from this system or break even? Consider the cost of the deployment project along with the monthly costs. Document your expectations and how you expect to achieve this budget.
Azure is an amazingly flexible and powerful resource, but it can also create a lot of challenges for your organization if you do not dedicate some time to plan and consider the business needs prior to deployment. A good Azure deployment process will allow some period of time for the business decision-maker to explore the topics above. If you're interested in learning more, contact Net Friends today!