< Previous Challenge - Home - Next Challenge >
The goals for this challenge include understanding:
An application may require the composition of many underlying infrastructure resources in Azure. As you have now seen with just a single VM and its dependencies, an ARM template can grow large rather quickly.
Bicep introduces the concept of modules. These are similar to linked templates but are much simpler to work with. When you write a Bicep file you can call another Bicep file as a module. When your template is transpiled into JSON, a single ARM template is produced including the code from your module(s).
When templates get big, they become monoliths. They are hard to manage. By breaking your templates up into smaller modules, you can achieve more flexibility in how you manage your deployments.
In many companies, deployment of cloud infrastructure may be managed by different teams. For example, a common network architecture and its security settings may be maintained by an operations team and shared across multiple application development teams.
The network architecture and security groups are typically stable and do not change frequently. In contrast, application deployments that are deployed on the network may come and go.
In this challenge you will separate your existing Bicep template deployment into two modules.
By separating the networking resources into their own modules, an application team can test its infrastructure deployment in a test network. At a later point in time, the networking module can be replaced with a production module provided by the company’s operations team.