Roadmap for Mission LZ

[brooke-hamilton]

Priority Areas

Summary

Our current priority areas include:

• Improved examples informed by real-world deployments: examples tag
• Enhanced security and compliance: compliance & security tag
• Refinement of core features: core tag

See the project board for detailed prioritization and current in-process work. Take a look at the contribution guidelines for an overview of the development process.

Improved Bicep Examples

Our goal for the Bicep examples is to provide useful add-ons to Mission Landing Zone that can be the foundation for customer deployments into MLZ environments. The most important existing example is the tier 3 deployment, which sets up a peered vnet that can host workloads or team environments.

Our planned work for examples includes providing a comprehensive example for hosting an internet-facing workload in which all traffic transits the network hub for inspection. #293 is still in draft form, and we are adapting the scope of this work from an example created here.

Another major focus area is improving and standardizing the pattern we have for how parameter values are mapped from an existing MLZ deployment into parameters for Bicep or Terraform deployments. We have some examples that use the shared variable file pattern. We like this pattern, but there are other ways of pulling MLZ deployment data from an existing deployment and we'd like to provide those with every example. This work is in #618.

Enhanced Security and Compliance

We recently completed #258 to deploy the Zero Trust TIC 3.0 workbook to Sentinel, and #607 to generate a Software Bill of Materials (SBOM). We have current work with #677 to enhance how SBOMs are generated.

Refinement of Core Features

We continue to receive high quality feedback from people deploying Mission Landing Zone. Our current priority in Core Features is to fix #627 to implement an Azure portal form in the Azure Marketplace. A related issue is #617 in which a change in the Azure portal which has caused our portal user interface form to fail to render the SSH key entry box. We had to revert to only accepting a user name/password for the Linux jump box until we implement a good workaround.

Other upcoming work includes #561 to refactor the directory structure of src/bicep.

Future Focus Area: NoOps/GitOps

A future area of exploration is how to enable NoOps or GitOps, in which an IT organization has a highly automated way a deploying infrastructure changes without a large IT staff, and have those changes driven by updates to configuration files (in a git repo for those doing GitOps.) MLZ is already highly modular, but we can make the individual tiers more modular and optional, and do more testing for idempotency. This is a way of managing infrastructure that not a lot of customers are doing right now because it's difficult and complicated to set up. We think that if MLZ can simplify the setup of NoOps/GitOps then more customers will be able to adopt the pattern, and we can further reduce the time it takes for an IT organization to deploy production workloads.

We plan to explore this area in incremental stages, with each stage having distinct value to Mission LZ stakeholders.

1. Finish Implement a standardized pattern for setting parameters on Bicep examples #618. Having multiple, clear options for adding onto and extending Mission LZ is essential to incremental, modular deployments.
2. Explore how much we can modularize the individual tiers of Mission LZ. Can each tier be deployed independently? Can we break down some of the features of the individual tiers into individual modular deployments? Can we do those things while still having the simple default deployment we have today? Support standalone deployment of the network hub and tiers 0, 1, 2 #658 represents this work.
3. How can Mission LZ simplify the assembly of a NoOps/GitOps process?

Feedback

We gratefully accept feedback in the form of issues and discussions created in this repo.