When platform architecture needs attention
- Clusters launched without platform standards
- Unclear ownership between app and platform teams
- Security gaps in RBAC, network policy, and supply chain
- Painful upgrades and configuration drift
- Observability that cannot support incident response
How we work on this platform
- AKS, EKS, and GKE target architecture
- Platform engineering and internal developer platform design
- GitOps and CI/CD for cluster and app delivery
- Network policy, ingress, and service mesh decisioning
- Observability with Prometheus/Grafana-compatible stacks
- Migration from VMs or PaaS to containers
The architecture in context
Conceptual architecture illustrating decision boundaries. It does not represent a client environment.
Choose the managed service from the estate
AKS, EKS and GKE share Kubernetes APIs but differ in identity integration, networking defaults, add-ons and upgrade experience. Choose based on the primary cloud estate, identity model, team skills and adjacent services — not an isolated feature checklist.
Platform engineering quality usually matters more than minor managed-service differences. The platform-operations page is how we stay on after the cluster is designed.
What we do not assume
Kubernetes is not required for every modernization programme. Some workloads are better on PaaS, serverless, or well-managed VMs. Architecture should follow the workload.
Day-to-day helpdesk and workplace IT are not Kubernetes platform operations. Those sit with Podium Catchers.
Technology decisions in context
- Kubernetes
- AKS
- EKS
- GKE
- Helm
- GitOps
- Terraform
- Istio / service mesh patterns
What the work is intended to enable
- A supportable cluster and platform operating model
- Clearer developer self-service boundaries
- Reduced configuration drift through GitOps
- Improved security and upgrade readiness
A platform choice is an operating choice
We agree workload acceptance criteria, access ownership, change practices and recovery responsibilities before implementation. Provider services do not remove the need for application testing, cost accountability and an operating team.
Questions and answers
What is the difference between AKS, EKS, and GKE?
AKS, EKS, and GKE are managed Kubernetes services on Azure, AWS, and Google Cloud. They share Kubernetes concepts but differ in identity integration, networking defaults, add-ons, upgrade tooling, and surrounding cloud services.
#Do we need Kubernetes for every modernization program?
No. Kubernetes is valuable when you need portable container orchestration and platform leverage. Some workloads are better on PaaS, serverless, or well-managed VMs. Architecture should follow workload characteristics, not fashion.
#Who runs the cluster after go-live?
We can operate the platform we design. That is landing-zone and cluster operations, not managed IT.
#Where should service mesh decisions live?
On this page as an architecture choice, and in the published API gateway versus service mesh article. Mesh is not a substitute for a landing zone.
#