Top 5 Reasons Companies Should Move Workloads to the Cloud

Moving some or all of an organization’s workloads to Microsoft Azure is a big decision that shouldn’t be taken lightly, especially if you want the switch to be successful. Depending on how large the application that is going to be migrated is, there may be a lot of risk for moving that application. However, when a migration project is well planned, and executed according to the plan, it can be successful and affordable at the scale that the application needs in order to meet user demands.

But while it may be possible to smoothly transfer workloads to a cloud environment, that doesn’t tell you why you should go to the trouble of doing it. In this article, I’ll explain the five main advantages to moving your organization’s workloads to Microsoft Azure.

Saving Money

OK, stop rolling your eyes.

We’ve all seen the Microsoft marketing spin for Azure where they say that it’s much cheaper than buying hardware. The reality is that if you just move your systems to Azure with the same number of CPUs that you have today, then things will be more expensive in Azure compared to purchasing new hardware every three to four years. However, if your plan when you move to the cloud is to replicate the size of your on-premises systems, then you are thinking about it the wrong way.

By right sizing virtual machines (VMs) when moving the workloads to the cloud, many machines will end up being cheaper in the cloud than on-premises. One massive difference between on-premises environments and the cloud is that the cloud is infinitely more flexible than on-premises environments. When you want to massively scale systems on-premises, you need to purchase hardware, which is expensive and takes time. And you’re going to have to continue to pay for those CPU cores when you aren’t using them. In Microsoft Azure you only pay for the resources while you are using them. If you have an eight vCPU VM in Microsoft Azure, and you need to add four cores for 60 days, you pay for those four cores for those 60 days, no more and no less.

Even more can be saved by moving services, when possible, to Platform as a Service (PaaS) servers. Many of the PaaS offerings will automatically scale themselves so that they are only using the resources that are needed to run the services. (See this article for a comparison between Infrastructure as a Service [IaaS] and Paas platforms.) As the performance requirements throughout the day increase, the PaaS service increases in size. As the utilization goes down at the end of the workday, the PaaS offering will scale down. With a web server farm for example, when running it on-premises, the web server VMs would need to be sized based on the peak size needed to keep the VMs running at their maximum performance. A web farm might need four virtual servers running four vCPUs to run the workload at peak usage. Putting that same workload in an Azure App Service, the App Service can start with a single four vCPU instance, and scale up to two, three, or four instances over the course of the day, then scale back down at night. Depending on the workload, by having the automatic scaling instead of just running four VMs, the savings could be as high as 75%.

Increased Redundancy

No matter how large your environment is, the Microsoft Azure environment is bigger and has more redundancy. Many of the Microsoft Azure regions include Availability Zones which allow you to put different VMs in different buildings, as well as spreading the PaaS services across different buildings within the Azure region. Without having multiple data centers all within a few blocks of each other, this level of redundancy simply isn’t possible. Never mind the contracts for power from different sources as well as isolated internet circuits for each of the data centers, both of which Availability Zones have, and they have it with under two milliseconds of latency between zones.

Those low-latency configurations would cost more than most companies can afford. Reaching the level of redundancy and latency Microsoft Azure can offer simply isn’t a financial possibility for most companies — unless you move those workloads to Azure.

Automatic Resource Scaling

It is basically impossible to automatically scale up and down resources (see the Saving Money section) in an on-premises platform. Adding a CPU to a server can be done via the hot-add CPU option in the major hypervisors, but hot removing a CPU is not an option. But that feature is available on a large percentage of the Microsoft Azure PaaS services. Auto scaling services not only lower the environment’s resource utilization, it also decreases the those resources’ operating costs.

Because of how hard/impossible scaling up and scaling down is on-premises, it requires an outage for systems like databases and manual intervention to add servers to a web server farm. But with the automatic scale features of the PaaS services within Microsoft Azure, there are no outages to end users as the automatic scale up and down is performed.

Reduced Server Deployment Time

With Microsoft Azure, there’s no buying hardware, dealing with long lead times, or installing and configuring hardware and software.

Deploying new servers in a data center takes time — sometimes a lot of time. Under the best-case scenario, buying a new server and having it shipped to the office takes two to three days. Then figure a few hours to rack the server, get the operating system installed and configured and hand it off to the team that needs the server. So, figure four days at best, and months at worst given supply chain issues and business problems.

With Microsoft Azure you can deploy new VMs in a matter of minutes. There’s no buying hardware, dealing with long lead times while getting hardware, or installing and configuring hardware and software. You can deploy not just one, but dozens of servers as a single ARM or Terraform script in just a few minutes. This can dramatically decrease the deployment time that it takes to release new servers for use within the corporate environment.

Not Worrying About Hardware Failures

One of the great benefits of Microsoft Azure over the on-premises world is not having to worry about hardware failures. With on-premises servers, no matter what kind of storage you have in the environment, you have to deal with failing hardware. The age-old premise still holds true: Things that spin will, at some point, fail. Most servers at the very least boot on spinning disks. Even if the servers have SSDs, those SSDs will eventually fail. The same holds true for disks in SAN or NAS devices.

In Microsoft Azure, failing hard drives simply aren’t an issue. When the physical hard drives in the Azure data center fail, it doesn’t impact the VMs which are using the hard drive. This is because of the way that Microsoft abstracts the storage and the redundancy that Microsoft has in place between the VMs and the storage components.

When it comes to fans (the other moving parts in servers), again, you don’t have to worry about them with Microsoft Azure. As we don’t worry about the physical servers, a failing fan is a Microsoft issue to address. When the fans in a physical server within the Azure data center start to fail, Microsoft will proactively move the VMs off of that physical server until they can replace it.

Azure Has a Lot of Benefits to Consider

When it comes to the cloud vs. on-premises data centers, the cloud has a vast number of benefits over on-premises environments. A like-to-like comparison between the cloud and on-premises is typically cheaper with the Azure environments. When you add in the benefits including faster server deployments, not having to worry about hardware failure anymore, and the automatic scaling features of Microsoft Azure, the cloud suddenly becomes a huge benefit over the traditional on-premises environments. Based on these features alone, many companies that are using on-premises servers — whether hosted in the office in a server room or data center, in a colocation facility, or hosted with a third-party server rental company — should strongly consider the cloud when it is time to renew the hosting agreements or purchase new or replacement servers.