Modular Landing Zones – The next frontier for Cloud Foundations

By Johannes Rudolph

Modular landing zones enable cloud foundation teams to deliver cloud tenants to application teams that these teams can flexibly extend and configure with optional building blocks like virtual networks, on-premise connectivity or vertically integrated DevOps toolchains. The capability to build and deliver modular landing zones is essential for delivering use-case tailored landing zones for the variety of different workloads most organizations have from traditional lift & shift deployments over container platforms to cloud-native workloads.

Our cloud foundation platform meshStack helps cloud foundation teams deliver modular landing zones at scale with full self-service for application teams. We see a clear trend that application teams expect these landing zones to serve as internal platforms for their workloads. This means that the landing zone should not only deliver a secure cloud tenant but also come with “batteries included” building blocks that accelerate application deployment and reduce operational overhead.

Building landing zones and internal platforms is challenging. In this post I want to share our plans and vision for improving the experience for enterprise architects and platform engineers designing and building these landing zones. I will also be covering how meshStack’s current marketplace features will evolve to align with this vision.

Key Challenges delivering Modular Landing Zones

Based on our learnings helping cloud foundation teams build more than one hundred landing zones, we identified four key challenges faced by enterprise architects and platform engineers who want to deliver a modular landing zone.

1. Publishing building blocks for self-service
2. Cloud foundation teams make building blocks available to application teams via a publishing process that enables staging and versioning. Application teams must be able to discover the building blocks available for their landing zone in self-service. Self-service makes it possible to add, modify and remove building blocks without manual interaction by the cloud foundation team and ensures there’s a single source of truth for the configuration of every cloud tenant.
3. Resource orchestration using familiar tooling
4. Building blocks typically have to orchestrate cloud resources into a configuration that provides a reusable capability like a secured object storage bucket or virtual network. Platform engineers already use infrastructure as code tools like terraform very successfully to automate resource configuration. It must thus be possible to easily define building blocks from existing automation like terraform modules instead of adding additional complexity with yet another tool.
5. Incremental automation
6. Many landing zone capabilities like on-premise connectivity have dependencies on legacy infrastructure like on-premise firewalls or IP address management systems that are difficult to automate. It’s thus crucial that cloud foundation teams can take an incremental approach to automate building block implementation, maybe even starting from a fully manual fulfillment approach backed by old-school ITSM over to a semi-automated workflow. Incremental automation allows cloud foundation teams to focus their efforts on those building blocks where automation provides the best return on invest.
7. Enable composition of building blocks
8. Building blocks have to compose seamlessly with landing zones, cloud tenants and other building blocks. This enables use cases like modeling the dependency between a “firewall rule” building block and a “default VPC” building block added to a cloud tenant by mandatory landing zone configuration.

Modular Landing Zones Support in meshStack

meshStack has historically supported the capabilities to build and deliver modular landing zones using an internal service marketplace, which we appropriately enough called “service marketplace”. The service marketplace has been an integral part of meshStack since the earliest inception of the product and many of our customers have developed a strong and successful service ecosystem for their landing zones. In fact, the number of service instances managed by our marketplace far outweighs the number of cloud tenants.

While we think that meshStack’s service marketplace fundamentally provides the right kind of self-service experience to application teams, we are highly aware of some major shortcomings in its current technical design when it comes to empowering cloud foundation teams to deliver modular landing zones.

1. Leveraging familiar tooling like terraform requires a lot of plumbing with unipipe and a GitOps workflow, adding a lot of complexity to simple automation use cases like “just deploy this terraform module”.
2. Starting with a manual service implementation as part of an incremental automation strategy is not possible directly from meshStack’s user interface, instead requiring unipipe and manual GitOps operations via its companion cli tooling.
3. Service instances are independent of cloud tenants by default. It requires additional steps to connect them to a cloud tenant, increasing complexity of standard landing zone use cases like a Virtual Network Service that adds a default virtual network to a cloud tenant.
4. Service instances are also “flat” and do not compose with each other, requiring clever workarounds to model dependencies and interactions between different services.

After a lot of discussions with our customers and cloud foundation stakeholders we have decided to fundamentally reboot our approach to building and delivering modular landing zones with meshStack. Which brings us to…

Building Blocks – Modular Landing Zones with Ease

Going forward, building blocks will become the new universal primitive for assembling landing zones and cloud tenants in meshStack. Each building block represents an encapsulated piece of functionality provided to an application team. Explained in a single picture below, application teams can flexibly assemble building blocks on the landing zone’s “baseplate” as required to support their use case.

To design landing zones, cloud foundation teams can designate building blocks as mandatory (pink) and optional (blue) building blocks, giving application teams a great deal of flexibility while retaining essential control.

Key Design Elements of Building Blocks

On a high level, here are the key design elements of meshStack’s new building blocks.

Building blocks:

• are individually reconciled, receiving inputs and producing outputs
• can depend on other building blocks, forming a directed acyclic graph (DAG)
• can attach directly to cloud tenants (meshTenants), with each tenant having its own independent building block graph
• are mandatory and optional components of a modular landing zone, delivered to application teams in a self-service experience similar to meshStack’s current service marketplace
• provide swappable implementation options:
• “manual” building blocks enable incremental automation starting from a GUI-based manual process
• meshStack will include out-of-the-box support for deploying terraform modules as building blocks
• platform engineers can implement custom blocks using on an external block-runner API
• are aware of their desired and actual state

How Building Blocks address Key Challenges of Cloud Foundation Teams

The new building block design directly addresses the key challenges faced by cloud foundation teams:

• out-of-the-box support for popular IaC tooling like terraform for implementing building block leverages widely available skills and enables plug&play reuse of existing automation assets instead of requiring complex GitOps pipeline setup
• incremental automation becomes a first class concept supported by meshStack’s GUI, enabling cloud foundation teams to first focus on overall landing zone design before investing into automation to solve operational challenges
• a conceptually simple yet powerful composition of building blocks enables advanced scenarios without requiring challenging API integrations or hidden backchannels between services to coordinate their functionality

Moving forward with Building Blocks

I will be sharing some more in-depth insights about the technical design of building blocks in an upcoming post. Our vision is that building blocks will ultimately supersede the existing tenant replication and marketplace functionality – unifying both in a single design that is conceptually less complex yet more flexible. This will make meshStack considerably more useful across a wider array of platform use cases.

Building on building blocks as a foundation, we plan to empower cloud foundation teams to define custom cloud platforms and landing zones more easily, for example to integrate internal developer platforms and specialized cloud providers. We will enable this by making more of the meshObject model available as APIs so that cloud foundation teams can tap into the same concepts meshStack uses to deliver out-of-the box capabilities for building AWS, Azure, GCP and other cloud platforms.

We are very excited about these changes and will ship our first MVP of building blocks this week. As part of the MVP we will first enable “manual building blocks”, followed by supporting building blocks based on terraform modules. We will be sharing more updates about our planned and upcoming features soon, including how building blocks will integrate with meshStack’s other capabilities like cost management, security and compliance.

This post originally appeared on meshcloud.io