Inquiries on ALZ-Bicep Integration, Configuration, and Best Practices
PolarbearChimney opened this issue · comments
Let us know the feedback or general question
Question
I'm hoping this is the appropriate place for my inquiry. I have several questions about ALZ-Bicep and would appreciate some insights:
Q: To begin with, why is it named Azure Landing Zones? This terminology often leads to confusion since the term "landing zones" primarily applies to "application landing zones." I've had numerous discussions where people suggest deploying the Azure Landing Zone as if it were a standalone entity, referring to the entire ALZ package. I find myself having to explain what a landing zone truly is, based on your documentation, before they understand that ALZ is not a landing zone per se, but rather a framework or tool designed to facilitate landing zones.
Q: Regarding GitHub actions, why have you made them so that they must they be executed in a specific sequence? Wouldn't having a single action that always runs in the correct order simplify the process? For instance, using dorny/paths-filter@v2 could maintain a filter on which files have changed and thereby determine the necessary job execution order.
Q: It appears that GitHub Actions primarily serve to execute pipeline scripts. Is this approach chosen to facilitate support for both GitHub and Azure DevOps, or are there other technical reasons behind it?
Q: How is the accelerator intended for use in a production environment, which ought to be controlled and managed through code? Without drift detection and only incremental deployment available, it seems it's only suited for initial deployments or perhaps for adding new policies.
Q: What is your thoughts about using Deployment Stacks instead of Resource locks?
Q: What's your view on managing "Application Landing Zones"? Should they be housed within the same repository or kept entirely separate? If in the same repo - could you provide practical examples or resources on how to effectively organize them within a single repository?
Thank you for considering my questions.
Code of Conduct
- I agree to follow this project's Code of Conduct
Hi @polarbear, thanks for taking the time to share your questions regarding ALZ-Bicep! These are very insightful questions that shed some light on areas that are important for understanding the framework. 👍🏼
Q: To begin with, why is it named Azure Landing Zones? This terminology often leads to confusion since the term "landing zones" primarily applies to "application landing zones." I've had numerous discussions where people suggest deploying the Azure Landing Zone as if it were a standalone entity, referring to the entire ALZ package. I find myself having to explain what a landing zone truly is, based on your documentation, before they understand that ALZ is not a landing zone per se, but rather a framework or tool designed to facilitate landing zones.
A: It's named so because it serves as a starting point or foundation for landing your workloads securely and efficiently onto Azure. However, I understand the confusion it can cause, especially considering the common association of "landing zones" with application deployment patterns. We have documentation clarifying that Azure Landing Zones encompass both Platform Landing Zones and Application Landing Zones. This ALZ-Bicep repo covers the provisioning of the Platform Landing Zones, while other modules like Bicep-LZ-Vending handle the initial setup of application zones in preparation for application teams and their workloads.
Q: Regarding GitHub actions, why have you made them so that they must they be executed in a specific sequence? Wouldn't having a single action that always runs in the correct order simplify the process? For instance, using dorny/paths-filter@v2 could maintain a filter on which files have changed and thereby determine the necessary job execution order.
A: You should only really need to run them in order for the initial deployment, as some modules have dependencies on others (like policy definitions and assignments). Once the initial deployment is complete, there are path-based filters for each workflow, so that only relevant workflows are triggered when a parameter file changes. We aimed to avoid relying on 3rd party actions/tasks for long-term supportability and to maintain consistency across CI/CD platforms. We also wanted to balance flexibility and simplicity.
Q: It appears that GitHub Actions primarily serve to execute pipeline scripts. Is this approach chosen to facilitate support for both GitHub and Azure DevOps, or are there other technical reasons behind it?
Partly yes, as we wanted to make it easier for us from a supportability standpoint and to avoid relying on marketplace actions/tasks that may lack long-term support. We chose PowerShell for consistency and simplicity, based on feedback from surveys indicating familiarity with PowerShell among users.
Q: How is the accelerator intended for use in a production environment, which ought to be controlled and managed through code? Without drift detection and only incremental deployment available, it seems it's only suited for initial deployments or perhaps for adding new policies.
A: We have conditional statements to detect when a PR is created, automatically performing a what-if check to determine changes before merging into the main branch. The aim is to avoid manual and thereby avoid configuration drift in the process as all changes can be managed through a version control system and automated pre- and post-validation steps.
Q: What is your thoughts about using Deployment Stacks instead of Resource locks?
A: We currently utilize resource locks as initially requested by the community. Transitioning to Deployment Stacks is a possibility for the future, pending investigation into community support and General Availability status.
Q: What's your view on managing "Application Landing Zones"? Should they be housed within the same repository or kept entirely separate? If in the same repo - could you provide practical examples or resources on how to effectively organize them within a single repository?
A: I highly recommend keeping them in separate repositories. Platform teams can manage the ALZ-Bicep framework in a dedicated repository, while application teams handle their own application landing zones code in separate repositories. This separation helps with permissions and operational scalability especially as organizations increase in size.
Again, appreciate your questions! I will go ahead and close this, but feel free to ask any additional questions as they come up and we can continue discussing. Have a great weekend!