private cloud on premises, that could result in a lot of work for administrators.
Familiarize yourself with the public cloud solutions available, and use them in the
right way. Use them where it makes sense, but don’t use them just to sidestep internal
provisioning processes or their shortcomings. Some organizations that I have worked
with took six weeks to provision a new virtual machine. Because of this long delay,
business units decided to use the public cloud instead, and often not officially. The
business units have a credit card and simply purchase public cloud services without IT
approval or oversight, commonly known as Bring Your Own IT (BYOIT). This BYOIT
by business units can lead to security, discovery, and retention requirements not being
met, which is a huge problem. That is a poor reason to use the public cloud. Fix the
internal process-using capabilities such as self-service and the private cloud that I’ve
talked about in detail in earlier chapters.
Moving services to the public cloud has additional advantages. Typically, those
solutions will ensure the availability of the service and perform the backups. It’s also
easy to scale up and down as you pay for what you use, but consider that many
services are consumed from anywhere. I check my email at home, on my phone, and
on a laptop at a restaurant, which means that my company would have to provide
Internet-based access to at least a portion of the corporate infrastructure if the service
was housed on premises. By leveraging a public cloud solution, the organization does
not have to provide that access. The service is already being offered on the Internet.
If you are creating a new custom application, consider whether it is a fit for a PaaS
solution such as Microsoft Azure. Something like this will minimize the ongoing IT
overhead required, because the only work to do is to maintain the application.
Remember, as I mentioned earlier, that when an application is written on the Azure
Resource Manager, it can be run not just in the public Azure PaaS, but on-premises or
with hosters via Microsoft Azure Stack. For other applications and workloads that you
want to run in the public cloud using IaaS, most should work without modification,
which is a key principle of IaaS.
If your organization utilizes Microsoft Azure for just development, testing, and stand-
alone projects, then no communication may be required between Azure and your on-
premises network outside of the standard Internet-based communications via load
balancers with NAT rules or VMs with public IPs. More commonly, seamless
connectivity between Microsoft Azure and the on-premises network is required to
enable cross-premises connectivity. To enable the cross-premises connectivity, you
need either to configure the Microsoft Azure VPN gateway site-to-site functionality
over the Internet or leverage ExpressRoute for dedicated connectivity over a private
network.
Before implementing connectivity to Microsoft Azure, you need to have created a
virtual network with subnets defined that will be used by virtual machines created
after you create the virtual network. The use of a virtual network is mandatory when
using Azure Resource Manager, but it is optional (although always recommended) for
the older Azure Service Manager. It is important to use an IP scheme for the virtual