Modular Landing Zones

โญ๏ธโญ๏ธโญ๏ธโ˜๏ธ PlatformLanding Zones are extendable with with services. These services have their own lifecycle and can be reconfigured during the lifespan of a tenant. The modular design allows combining services like LEGOยฎ blocks.

Why Modular Landing Zones?

A Landing Zone describes the desired state of a cloud tenant. Landing Zones are applied to cloud tenants before DevOps teams access tenants for the first time and are re-applied regularly to avoid a configuration drift.

Modular Landing Zones have a baseline and are extendable with optional modules.

The baseline determines

  • Where a tenant lives in the cloud providerโ€™s resource hierarchy (which has consequences on the applied policies, see Resource Policies - Blacklisting)

  • Which roles team leads can assign their developers

Common examples for optional modules are

image-a825efcf-03c0-4696-abd2-9fb31febb7c8

Already a small number of optional modules can lead to a large number of combinations of those modules. Modular Landing Zones allow tailoring Landing Zones to the needs of every DevOps team while keeping redundancy low and complexity manageable.

Secure your Cloud Accounts across all Clouds

Having large numbers of accounts with multiple cloud providers requires an airtight management solution: The creation, administration, security configuration and deprovisioning has to be easy and transparent.

Learn more โ†’

Proven Patterns for Building Modular Landing Zones

Split up Existing Monolithic Landing Zones

You do not have to start form scratch, if you already have an existing Monolithic Landing Zone (see Monolithic Landing Zone). When splitting up existing Landing Zones, a general guideline is: Policies and security settings go into the Landing Zone baseline. Infrastructure that requires workload (e.g. Managed Key Vault, Virtual Network Service) goes into modules.

Use a Cloud Foundation Platform

Cloud Foundation teams need control over who gets access to what Landing Zone (see Control access to cloud platforms and Landing Zones). At the same time, a low time-to-cloud is only sustainable via self-service onboarding for DevOps teams (see Self-Service Multi-Cloud Tenant Database ). Therefore a highly integrated solution is necessary for applying a baseline of Landing Zones to tenants. This makes Cloud Foundation Platform the best choice for managing the baseline of Landing Zones.

Use Infrastructure as Code Tooling

Most teams build the optional modules for Landing Zones with Infrastructure as Code tooling. Common examples are Terraform, Azure BluePrint or Bicep, Google Cloud Resource Manager or AWS Cloud Formation.

Manage Services GitOps Style

GitOps is a proven pattern for managing optional Landing Zones modules. Having easily accessible definitions of Infrastructure as Code files in a version control system makes inspecting and updating Landing Zones a lot easier. When integrating with Cloud Foundation Platforms that support Open Service Broker API for implementing Landing Zones modules, the open-source UniPipe Service Brokeropen in new window can be used to implement a GitOps workflow.

Find the Right Balance between Control and Freedom

Do DevOps teams get IAM management rights in their tenant? An โ€œopenโ€ approach to tenant permissions allows DevOps teams to iterate faster. A โ€œclosedโ€ approach minimizes risks stemming from misconfigured permissions.

  • meshStack

    meshStack enables the use of modular landing zones by building marketplace services on top of landing zones.

    Learn More open in new window
Last Updated: