Comparison
of on-premises versus Azure
With an on-premises
infrastructure, you have complete control over the hardware and software that
you deploy. Historically, this has led to hardware procurement decisions
focused on scaling up; that is, purchasing a server with more cores to satisfy
a performance need. With Azure, you can deploy only the hardware provided by
Microsoft.
This leads to a focus on scale-out through the deployment of
additional compute nodes to satisfy a performance need. Although this has
consequences for the design of an appropriate software architecture, there is
now ample proof that the scale-out of commodity hardware is significantly more
cost-effective than scale-up through expensive hardware.
Microsoft has deployed Azure datacenters
in over 22 regions around the globe from Melbourne to Amsterdam and Sao Paulo
to Singapore. Additionally, Microsoft has an arrangement with 21Vianet, making
Azure available in two regions in China. Microsoft has also announced the
deployment of Azure to
another eight
regions. Only the largest global enterprises are able to deploy datacenters in
this manner, so using Azure makes it easy for enterprises of any size to deploy
their services close to their customers, wherever they are in the world. And
you can do that without ever leaving your office.
For startups, Azure
allows you to start with very low cost and scale rapidly as you gain customers.
You would not face a large up-front capital investment to create a new VM—or
even several new VMs. The use of cloud computing fits well with the scale fast,
fail fast model of startup growth.
Azure provides the
flexibility to set up development and test configurations quickly. These
deployments can be scripted, giving you the ability to spin up a development or
test environment, do the testing, and spin it back down. This keeps the cost
very low, and maintenance is almost nonexistent.
Another advantage of Azure
is that you can try new versions of software without having to upgrade
on-premises equipment. For example, if you want to see the ramifications of
running your application against Microsoft SQL Server 2016 instead of Microsoft
SQL Server 2014, you can create a SQL Server 2016 instance and run a copy of
your services against the new database, all
without having to allocate hardware and run wires. Or you can run on a VM with
Microsoft Windows Server 2012 R2 instead of Microsoft Windows Server 2008 R2.
