Building Out an Application’s Azure Infrastructure

This post is a continuation of our prior post First Things First for Azure Application Infrastructure. If you haven’t checked that one out already – give it a look.

At this point we have our planned Azure asset set and infrastructure architecture and now it’s time to start building out our infrastructure (and you know we’re not going to do it interactively!). As we know, your Microsoft Azure cloud success relies on an informed approach and we are about to reap those planning benefits.

Let’s Review Our Planned Azure Asset Topology

In our previous First Things First for Azure Application Infrastructure post, we designed our application’s planned topology of services/assets. We started with an engineering drawing of the topology that looked a little bit like this:

Strategically, our selection of Platform as a Service (PaaS) assets (as opposed to Infrastructure as a Service options like virtual machines) will yield a significant reduction in IT staff manpower required to keep infrastructure running. App Services, Azure Functions and SQL Azure are built-in flex points that will pay long-term dividends.

Get An Azure Tenant Rocking

In the world of cloud software, “tenant” is a fancy term for your customer account within a cloud provider’s system. As a global provider of a broad range of cloud services, Microsoft differentiates their customers’ accounts by creating an isolated tenant for each customer.

Many of you will already have Microsoft/Azure tenants by virtue of existing Microsoft 365 or Azure use. If so, we recommend the creation of a subscription dedicated to your enterprise applications; this will provide a later budget management and reporting bucket that will help you separate application infrastructure costs from other cloud IT costs. Each Azure tenant can be composed of one or more subscription and each subscription functions as a security and reporting divider between a group of cloud services.

If you are not an existing Microsoft cloud customer, you can easily create a tenant by visiting the Microsoft Azure new account page to enroll and create an account. Once you’ve created your account, you can create a subscription within your Microsoft tenant to contain the Azure infrastructure for your enterprise application.

There is certainly more to know about Microsoft tenant, subscriptions, licensing and cost management that are outside the scope of this post. We will close this topic by calling out that your Azure infrastructure assets will be created within your selected Azure subscription.

Script the Asset Creation

Azure Resource Manager (ARM) templates provide the ability to define Azure resources declaratively using JSON notation. While ARM templates simplify the creation and visibility of resources, JSON is verbose and has a bit of a learning curve to its use for Azure resource creation. Enter Bicep.

Bicep is a domain-specific language built as an abstraction of ARM templates with a cleaner/more concise syntax. This abstraction yields several benefits including readability, long-term maintenance and easy movement from formulation to deployment. Bicep’s concision for Azure infrastructure creation is illustrated below.

MercuryWorks is highly biased on the topic of PaaS vs IaaS strategies and in the vast majority of cases recommend and implement PaaS services like App Services and Functions. IaaS does have its place for specific cases and while we don’t strictly rule out its use, we are sure to script the creation and configuration of all assets and services with Infrastructure as Code (IaC) using Bicep. to power asset instantiation and configuration with Azure ARM (Azure Resource Manager) files.

IaC and Bicep implementation is a broad and technical topic. If you are interested in getting diving deeper and growing skill on asset scripting, we recommend our blog post ARM Day: Infrastructure as Code workout with Bicep as a start. Microsoft also provides a great introductory course through their Learn course Introduction to infrastructure as code using Bicep.

Advisable Extras

While not strictly required, there are a couple additional Azure services that we deploy for enterprise applications. While these two services aren’t directly used to power the application, they are practically no-brainers for performance of your application and your ability to operate and maintain it.

Content Delivery Network (CDN) for Performance

The Azure Front Door service not only provides a security barrier/web front end but also provides a CDN to cache static resources closer to users. This reduces UI load time for interface markup, JavaScript libraries, CSS and interface images. While the back-end operation of your enterprise application will likely hinge on business-critical APIs, having a snappy UI and asynchronous CDN-powered UI will provide the desktop-like experience modern users have come to expect.

Azure Monitor for Long-term Operation

We also typically implement Azure Monitor for each enterprise application (utilizing mainly Application Insights) to provide conditional alerts for user-impacting performance and availability. Azure Monitor will provide real-time emergent application availability and performance alerts (if an API query all of a sudden starts running for 15 seconds, you want to know) and lower-grade chronic application issues. I can’t imagine responsibly operating an enterprise application without Azure Monitor (or something similar) in place.

Next Up: Construct a CI/CD Pipeline for Automated Build and Release

As you can see, MercuryWorks recommends committing time to develop a methodical and actionable cloud asset strategy that meets your application’s “jobs to be done”.  Your resulting plan will prescribes not only a sound starting point for implementation but also a record of both why and what you did when uplifting to Microsoft Azure.

At this point you’re ready to go.  But what does it mean to “go”?  We will cover the journey through a first Azure implementation in a future post.

---

Interested In Moving Your Application to the Cloud?