Azure deployment models
In Azure nomenclature, deployment refers to your provisioning resources in the Azure public cloud. You may be saying, “What’s this? Why is Microsoft Azure called a public cloud? Microsoft always says that different Azure customers can never see each other’s resources by default.” Hang on; hang on. Let’s explain.Public cloud
Microsoft Azure is a public cloud because its global data center fabric is accessible by the general public. Microsoft takes Azure’s multitenant nature very seriously; therefore, it adds layer after layer of physical and logical security to ensure that each customer’s data is private. In fact, in many cases, even Microsoft doesn’t have access to customers’ data encryption keys!Other major cloud service providers — including AWS, GCP, Oracle, and IBM (see the nearby sidebar “Other cloud providers”) — are also considered to be public cloud platforms.
Microsoft has three additional, separate Azure clouds for exclusive governmental use. Thus, the Microsoft literature contains references to Azure Cloud, which refers to its public cloud, and to Azure Government Cloud, which refers to its sovereign, special-access clouds. No member of the general public can access an Azure Government Cloud without being associated with a government body that employs it.
Private cloud
Very, very few businesses have enough financial, capital, and human resources to host their own cloud environments. Typically only the largest enterprise organizations can afford having their own private cloud infrastructure with redundant data centers, storage, networking, and compute, but they may have security prohibitions against storing data in Microsoft’s (or any other cloud provider’s) physical data centers.Microsoft sells a portable version of the Azure cloud: Azure Stack, which consists of a server rack that a company leases or purchases from a Microsoft-affiliated hardware or service provider.
The idea is that you can bring the hallmarks of cloud computing — on-demand self-service, resource pooling, elasticity, and so forth — to your local environment without involving either the Internet or an external cloud provider unless you want to.
Your administrators and developers use the same Azure Resource Manager (ARM) application programming interface (API) to deploy resources locally to Azure Stack as they use to deploy to the Azure public cloud. This API makes it a snap to bring cloud-based services on premises, and vice versa.
Hybrid cloud
When you combine the best of on-premises and cloud environments, you have a hybrid cloud.It's most often the case that the hybrid cloud deployment model makes the most sense for most businesses. Why? A hybrid cloud allows the business to salvage (read: continue to use) the on-premises infrastructure that it’s already paid for while leveraging the hyper scale of the Azure public cloud.
Take a look at the image below. In this topology, the on-premises network is extended to a virtual network running in Azure. You can do all sorts of nifty service management here, including
- Joining the Azure virtual machines (VMs) to your local Active Directory domain
- Managing your on-premises servers by using Azure management tools
- Providing nearly instant failover disaster recovery (DR) by using Azure as a DR site. Failover refers to having a replicated backup of your production servers available somewhere else so that you can shift from your failed primary environment to your backup environment within minutes. Failover is critical for businesses that cannot afford the downtime involved in restoring backups from a backup archive.
A hybrid cloud in which the on-premises corporate network extends to Azure.
Here’s an overview of what’s going on:
- On the left side is a local business network that connects to the Internet via a virtual private network (VPN) gateway.
- On the right (Azure) side is a three-VM deployment in a virtual network. A site-to-site VPN connects the local environment to the virtual network. Finally, an Azure load balancer spreads incoming traffic equally among the three identically configured web servers in the web tier subnet. As a result, the company’s internal staff can access the Azure-based web application over a secure VPN tunnel and get a low-latency, reliable, always-on connection to boot.
A local, physical network environment is referred to as an on-premises environment. In the wild, you’ll see stray references to “on premise”— sadly, even in Microsoft’s Azure documentation. Don’t make this mistake. A premise is an idea; premises refers to a location.
Usually, it’s only small businesses that are agile enough to do all their work in the Azure cloud. That said, you may find that after your organization gets its sea legs with Azure and begins to appreciate its availability, performance, scalability, and security possibilities, you’ll be working to migrate more on-premises infrastructure into Azure, and you’ll be targeting more of your line-of-business (LOB) applications to the cloud first.Azure service delivery models
Organizations deploy applications in three primary ways: Software as a Service, Infrastructure as a Service, and Platform as a Service.Software as a Service (SaaS)
An SaaS application is a finished, customer-facing application that runs in the cloud. Microsoft Office 365 is a perfect example. As shown below, you can use Word Online to create, edit, and share documents with only a web browser; an Internet connection; and an Office 365 subscription, which you pay for each month on a subscription basis.
Word Online, part of the Microsoft Office 365 product family, is an example of an SaaS application. With SaaS applications, you have zero visibility into the back-end mechanics of the application. In the case of Word Online, you neither know nor care how often the back-end servers are backed up, where the Office 365 data centers are geographically located, and so forth. All you care about is whether you can get to your cloud-hosted documents and whether Word Online behaves as you expect.
Platform as a Service (PaaS)
Consider a business that runs a three-tier on-premises web application with VMs. The organization wants to move this application workload to Azure to take advantage of the benefits of cloud computing. Because the organization has always done business by using VMs, it assumes that the workload must by definition run in VMs in Azure.Not so fast. Suppose that the workload consisted of a Microsoft-stack application. Maybe the business should consider using PaaS products such as Azure App Service and Azure SQL Database to leverage autoscale and pushbutton georeplication.
Georeplication means placing synchronized copies of your service in other geographic regions for fault tolerance and placing those services closer to your users.
Or maybe the workload is an open-source project that uses PHP and MySQL. No problem. Azure App Service can handle that scenario. Microsoft also has a native hosted database platform for MySQL called (appropriately enough) Azure Database for MySQL.
With PaaS, Microsoft takes much more responsibility for the hosting environment. You’re not 100 percent responsible for your VMs because PaaS products abstract all that plumbing and administrative overhead away from you.
The idea is that PaaS products free you to focus on your applications and, ultimately, on the people who use those applications. If PaaS has a trade-off, it’s that relinquishing full-stack control is an adjustment for many old-salt systems and network administrators.
To sum up the major distinction between IaaS and PaaS, IaaS gives you full control of the environment, but you sacrifice scalability and agility. PaaS gives you full scalability and agility, but you sacrifice some control.
To be sure, the cloud computing literature contains references to other cloud deployment models, such as community cloud. You’ll also see references to additional delivery models, such as Storage as a Service (STaaS) and Identity as a Service (IDaaS).
Infrastructure as a Service (IaaS)
Most businesses that migrate their applications and services to Azure use the IaaS model, if only because they’ve delivered their services via VMs in the past — the old “If it ain’t broke, don’t fix it” approach.In large part, IaaS is where the customer hosts one or more VMs in a cloud. The customers remain responsible for the full life cycle of the VM, including
- Configuration
- Data protection
- Performance tuning
- Security
Thus, whereas SaaS is a service that’s been fully abstracted in the cloud, and the customer simply uses the application, IaaS offers a split between Microsoft’s responsibility (providing the hosting platform) and the customer’s responsibility (maintaining the VMs over their life cycle).
Cloud computing in general, and Microsoft Azure in particular, use what’s called the shared responsibility model. In this model, Microsoft’s responsibility is providing the tools you need to make your cloud deployments successful — Microsoft’s data centers, the server, storage and networking hardware, and so on. Your responsibility is to use those tools to secure, optimize, and protect your deployments. Microsoft isn’t going to configure, back up, and secure your VMs automatically; those tasks are your responsibility.
Microsoft Azure Services
The Microsoft Azure service catalog has hundreds of services and is continually expanding. Microsoft maintains a services directory. You can review all services there, but a brief description is provided below.Azure history
In October 2008, Microsoft announced Windows Azure at its Professional Developers Conference. Many people feel that this product was a direct answer to Amazon, which had already begun unveiling AWS to the general public.The first Azure-hosted service was SQL Azure Relational Database, announced in March 2009. Then came support for PaaS websites and IaaS virtual machines in June 2012. The following image shows what the Windows Azure portal looked like during that time.
The Windows Azure portal, circa 2012.
Satya Nadella became Microsoft’s chief operating officer in February 2014. Satya had a vision of Microsoft expanding its formerly proprietary borders, so Windows Azure became Microsoft Azure, and the Azure platform began to embrace open-source technologies and companies that Microsoft formerly considered to be hostile competitors.
It can’t be overstated how important that simple name change was and is. Today, Microsoft Azure provides first-class support for Linux-based VMs and non-Microsoft web applications and services, which is a huge deal.
Finally, Microsoft introduced the (RM deployment model at Microsoft Build 2014. The API behind Windows Azure was called Azure Service Management (ASM), and it suffered from several design and architectural pain points. ASM made it super-difficult to organize deployment resources, for example, and it was impossible to scope administrative access granularly.