such as Office 365 for their messaging and collaboration. They not only don’t not need
infrastructure, but also don’t need messaging administrators to maintain it. Public
cloud IaaS is a great solution for virtual machines because, once again, no up-front
infrastructure is required and companies pay for what they use. As the company
grows, its utilization goes up and so does its operating expenditure, but it’s
proportional to the business. This type of pay-as-you-go model is also attractive to
potential financers because it requires less initial outlay and therefore reduced risk.
If your organization needs a highly available application but you don’t have the
infrastructure to support the level of availability required, Microsoft Azure is a great
fit. This can similarly apply to disaster recovery, and I’ve seen a lot of organizations
interested. Some organizations have a main datacenter but not a second datacenter
that can be used for disaster recovery. In this case, leveraging a public cloud IaaS can
be a good option for a disaster-recovery plan. There are a lot of considerations. First,
for the smoothest failover, the hypervisor used on premises should match that in the
public cloud, which for Microsoft Azure would be Hyper-V. Otherwise, messy
conversions are required when moving between the hypervisors. The good news when
using Azure Site Recovery, however, is that even if VMware is used on premises, there
is still seamless replication and failover to Azure and even failback. You also need to
consider the best way to keep the virtual machines and templates in Microsoft Azure
IaaS current, which definitely is simpler when the same hypervisor is used on
premises and in the cloud.
If you have an application that has a fairly short lifetime (maybe related to a specific
promotion or advertising campaign), Microsoft Azure is a great fit. The resources are
spun up in Microsoft Azure for the duration of the workload and then deleted.
Another popular type of workload is development and test workloads, which are lower
priority workloads but also tend to be constantly provisioned and deprovisioned,
resulting in a lot of churn and overhead for the on-premises infrastructure and IT
team. By moving these workloads to the public cloud, you remove that overhead, and
if the organization does not currently have private cloud solutions, then the end-user
experience will also be simpler, which will result in faster provisioning times. I urge
caution here, though, because the point of testing is to ensure that an application
works as anticipated. The operating system, application, and data would look the same
running on premises or in a public cloud IaaS, and if the same hypervisor is used, the
hardware would also look the same. However, the actual underlying networking and
the underlying storage is different, and so while initial development and testing can be
performed in a nonproduction-like environment, the final user acceptance testing
should be performed on premises to ensure that there is no difference in storage or
networking or even the compute that will affect the functionality of the application.
Microsoft Azure has some technical limitations that relate to elements of compute,
network, and storage (and I cover them later in this chapter). However, outside of
those, there is no workload that couldn’t run in Microsoft Azure IaaS.
The decision about whether a workload is a better fit for on premises or the public