When you start thinking about adopting cloud computing platforms, you know you want to get well supported infrastructure, cost control, and the latest technology. But how do you make it easy for the engineers who will implement your vision? That’s where a strong framework and solid foundation comes in. Following industry best practices is made so much simpler when you can adopt a well-architected set of purpose-built tools.
Intro to Azure CAF
What is a CAF?
A Cloud Adoption Framework (CAF) is a toolkit consisting of several steps (planning, readiness, adoption, governance, and management). In simple terms, a CAF is a set of tried-and-true strategies to help you migrate to the cloud in the best way possible.
Microsoft’s Azure CAF sets out to solve cloud adoption challenges for a wide range of users. Because of this deliberately broad focus, their templates require significant knowledge in Azure architecture to successfully implement. Additionally, many of their offerings are MS Azure specific.
We saw an opportunity to make things easier and more focused. With ease of implementation as our goal, we set out to make an Azure CAF based implementation using Terraform. We’ll dive more into why it is our favorite Infrastructure as code (IaC) tool in a future post. Here, we will simply say that Terraform allows us to create code that is easy to read, maintain, and extend. We aim to minimize up front input choices and give you a usable deployment experience right at your fingertips.
What is a Landing Zone?
A Landing zone is the foundation on which you will build your own cloud infrastructure to support workloads. It provides the foundation to get started quickly and securely by helping you focus on your application’s infrastructure rather than the time consuming prerequisites to begin deploying your application. Landing zones account for scale, security governance, networking, and identity.
Why is it important?
A common pattern in large organizations when migrating to the cloud is that teams will dive head first into experimentation by doing initial cloud infrastructure POC’s. The intent behind these POC’s is to gain context through trial and error and return to fix issues later. This ephemeral infrastructure eventually needs to be replaced for a production deployment. Often security and audit compliance needs are not addressed until it is time to work on a production “go-live” effort. Or worse, the subpar POC configuration becomes the de-facto production standard. Instead of defaulting to this “wait until the end” approach, an Azure CAF Landing Zone allows you to build production ready deployments from the beginning.
Landing Zones make migration to the cloud easier, while ensuring consistency up front for security, regulatory compliance, networking, and identity management. You are then free to focus on delivering your applications and innovating to meet customer needs quickly. POC’s can be standardized with less need to work on building a stable baseline infrastructure and more time for simply testing your business application ideas.
Perhaps even more importantly, you can build trust that allows rapid production deployment since the cloud infrastructure patterns have been proven through repeated use and validation.
What approach has Microsoft used?
Microsoft has their own IaC solutions in Azure Resource Manager (ARM) templates and Bicep. These are Azure specific tools for managing cloud infrastructure.
Microsoft has also ventured into creation of modules using Hashicorp’s Terraform. However, their effort to cover all use cases makes those Terraform options somewhat difficult to consume, especially for new users in the Azure space. On the plus side, Terraform’s platform independence has led to broad industry support. Check out our Solution Brief to hear our thoughts on ARM vs Terraform.
After working directly with Microsoft’s CAF supermodule in Terraform, as well as their Terraform Enterprise Scale CAF module, we chose to invest time in creating our own opinionated framework for Azure CAF. We wanted to create an implementation of CAF readiness automation that provides a concise vision. While Microsoft Enterprise CAF has a lot of functionality it doesn’t provide an opinion about many of its complex components.
We wanted to emphasize ease of management, incremental rollout, and limit the amount of decisions blocking a sensible starting point. In short, we wanted to make it simple to consume.
Our Approach
When deciding to create our own Terraform implementation we came across many complex decisions that we wanted to codify for the sake of its consumers. Rather than accounting for every possible instantiation of Azure CAF readiness infrastructure, we wanted to emphasize ease of management, incremental rollout, and limit the amount of decisions blocking a sensible starting point. In short, we wanted to make it simple to consume. Azure’s voluminous service catalog is ever expanding and with this comes an overload of choice that can be daunting to navigate. Our approach aims to mitigate this by offering out-of-the-box functionality.
Our Azure CAF based landing zones provide opinionated sensible defaults to allow you to begin using Azure’s cloud offering quickly. You are still free to choose each implementation detail, but typically the default selections will get you what you need in order to deploy infrastructure and applications securely. For example here are a few of our features:
- ~Azure Policy
- ~~Here we specify safe default policies that include and enhance the Azure default policies, while being mindful of cost
- ~~One goal here is to make policy management more accessible while sticking with our everything-as-code philosophy
- ~Networking Infrastructure
- ~~Our modules include a private DNS resolver service by default that is in turn linked to VNets in landing zones you deploy
- ~~The VWAN service from Azure allows easy management of hub and spoke topology by abstracting networking complexities
- ~Landing Zones
- ~~We compartmentalize infrastructure required for supporting different flavors of workloads
- ~~The modules utilized by our implementation are designed to hook into existing networking and structural components
- ~Shared Services
- ~~In order to support private workloads hosted in the cloud, we include a shared services cluster for reusable workloads such as github self hosted-runners.
In this introduction of Liatrio’s Terraform Azure CAF implementation we have introduced the founding principles of the module as well as some of the benefits it provides. Next time we’ll take a deeper look at our tool of choice: Hashicorp’s IaC tool, Terraform!
