IaC with Azure Deployment Stacks!
Companies continuously solicit swifter ways to deploy, manage and scale cloud infrastructure. With Microsoft Azure leading the change in cloud innovation, the introduction of Azure Deployment Stacks delivers a rugged toolset for simplifying the deployment & management of complex environments.
This blog post delves into Azure Deployment Stacks, how they work, and how they can transform Azure cloud infrastructure management.
Azure Deployments Models
We are used to `ARM templates`, `Bicep`, or `Powershell`/`Az-Cli` as deployment models for Azure resources’ provisioning based on Azure Resource Manager. These models enable sufficient flexibility in resource creation and removal. However, they lack some capabilities!
Pain Points!
Some of the known pain points and missing capabilities when managing Azure infrastructure are not limited to:
- Lack of Resource Tracking!
In typical deployments in Azure, the deployment object is not that useful as it doesn’t help with resource tracking. Deleting the deployment object will do nothing; All the created resources will be left behind!
- Challenges for Resources Lifecycle & Cleanup!
In most cases, and for complex solutions, it gets harder to track and handle the lifecycle of a set of Azure Resources and or their cleanup!
Manual removal of a complex solution could lead to orphaned resources, which could be costly!.
Removing a Resource Group is not an option for most teams; thus, a better way should exist to manage resources efficiently (Tagging/Metadata are valid, but things could get tricky).
- Lack of Resource protection!
Protecting resources from unwanted actions and preventing drift in configurations remains challenging.
How do we limit what people can do, even to resource owners?
- Lack of a good practice to clean up resources!
We tend to remove a whole Resource Group to clean up non-needed resources or use tags to select the right ones (It happens that resources are not adequately tagged!). This could be an option, but things get more complex quickly! Is there any better way?
As we expect from the blog post’s title, the solution is Azure Deployment Stacks…
In a nutshell, Azure Deployment Stacks is a grouping capability that simplifies the lifecycle management of a set of resources.
Azure Deployment Stacks!
Azure Deployment Stacks is a feature of Azure Resource Manager (ARM). It aims to group linked resources into a single logical unit (a cohesive unit) for deployment, lifecycle, and dependencies management.
The goal is to simplify complex deployments using repeatable, consistent, and reliable processes.
This new capability is handy for managing complex environments with interdependent services, like multi-tier applications, data lakes, or networking setups; It doesn’t matter if such resources could be in a shared subscription and/or multiple Resource Groups.
Out of the Box, Deployment Stacks enables the following capabilities:
- We can manage resources as a group, making performing updates, rollbacks, and scaling operations easier. (Less operations to deploy/update/cleanup resources)
- We can define the life-cycle operations on the stack that will be created!
- Deleting the stacks leads to deleting all related resources, even if the deployment is spanned to multiple Resource Groups, which is excellent!
- Guardrails to prevent resources managed by the stack from being removed or altered. (known as Deny Settings)
The key is that resources within a particular stack should share a common lifecycle!
Microsoft Learn provides the opportunity to experience Deployment Stacks:
Deployment Stacks Concepts
Some concepts to share about deployments stacks, and which we should know about are:
- Managed resources: When creating a deployment stack (e.g., via bicep), the stack manages the resources described in the config file. Those Resources are known as managed resources.
- Deny settings: Deny modes can be enforced over a collection of resources (stack) as an extra security layer to protect resources from unwanted change with either ‘deny delete’ or ‘deny write and delete’, which may sound similar to Azure locks. (Settings enforced supersedes any RBAC assignments or locks in place!)
Wrapping Up
It is crucial to properly design the stack before deployment, as it could manage resources created under the same umbrella, meaning the same or child targets. The Deployment stack could span resources under multiple management groups, subscriptions, or resource groups.
The deployment stack should only consist of resources with a certain commonality, and we want them to share a lifecycle. If not, they should be defined in separate stacks!
