Container Platform Landing Zone
🚧 This building block reference page is a draft.
If you want to be notified when the building block reference page is finished, click here.
Many organizations have in-house application development teams. Unless they established DevOps (proper) and have dedicated resources embedded within every application team, providing a central platform bundling infrastructure operations makes sense (internal developer platform)
Many application teams target containers and kubernetes specifically as an abstraction layer. Reduced vendor lock-in, reasonable abstraction over cloud infrastructure
Central platform teams can build multi-tenant k8s on top of managed cloud provider offerings (e.g. GKE, AKS etc.) more easily. Should look into this angle first before offering Kubernetes Cluster as a Service - it’s easier to operate fewer bigger clusters than many small cluster
Caveat: Kubernetes is not specifically designed for hosting multi-tenant workloads, albeit this is usually fine in an in-house platform context with semi-trusted workloads. Some kubernetes based platforms like OpenShift offer better implementations
Developer experience essentially “serverless”, i.e. no infrastructure responsibility.
Can “augment” these landing zones with cloud-native tenant access, e.g. for object storage, cloud-native DBs (Dynamo DB etc.) → very powerful
Alternative is a proprietary fully-managed serverless stack, e.g. AWS lambda, Azure Functions etc. Using containers is optional here, but has advanatages (see toolchain below)
Landing Zone should set IAM policies and resource Quotas
Should include Private Cloud pay-per-use chargeback
meshStack has built-in support for building and operating OpenShift, AKS and other Kubernetes based Landing Zones including IAM, quota management and consumption metering.Learn More