## The Lock-In Problem
Cloud providers are very good at making their services useful and interconnected. They're also very good — though this is rarely stated explicitly — at making it difficult to leave. The more deeply you use provider-specific services (AWS Lambda, Azure Functions, Google BigQuery, managed databases, proprietary ML services), the more expensive and time-consuming it becomes to move workloads elsewhere.
This isn't necessarily a problem if you're happy with your provider relationship and never need to move. But business needs change. Providers' pricing strategies change. Providers get acquired. Regulatory requirements about data location change. The ability to move workloads — or at minimum, to credibly threaten to do so in commercial negotiations — has real value.
Cloud workload portability is about building your applications on abstractions that work consistently across cloud providers, so that moving a workload doesn't require fundamental rearchitecting.
## Kubernetes as the Portability Layer
Kubernetes has become the de facto standard for container orchestration, and it's the key enabler of cloud portability. A well-architected Kubernetes application can run on AWS EKS, Azure AKS, Google GKE, or on-premises Kubernetes clusters with minimal configuration changes. The application itself is portable; only the infrastructure plumbing beneath it is provider-specific.
The practical implementation of Kubernetes-based portability requires a few specific choices. Use Kubernetes-native service types (LoadBalancer, Ingress) configured through standard APIs rather than provider-specific annotations where possible. Store persistent data using storage classes that can be mapped to different providers. Use secrets management in a provider-agnostic way (HashiCorp Vault, Kubernetes secrets with appropriate encryption). Avoid provider-specific Kubernetes extensions that would create portability barriers.
GitOps — using Git as the single source of truth for both application code and infrastructure configuration, with automated deployment triggered by Git commits — provides the operational workflow for multi-cluster Kubernetes management. Tools like ArgoCD and Flux CD manage application deployment consistently across clusters in different environments and providers, reducing the operational overhead of running workloads in multiple locations.
## Platform Engineering for Cloud Portability
The platform engineering approach to cloud portability builds an internal developer platform (IDP) that abstracts provider-specific details behind standardised APIs and workflows. Developers declare what their application needs (compute, storage, networking, databases) through platform abstractions, and the platform provisions the appropriate provider-specific resources.
This abstraction layer is the key to making portability practical for large teams. Rather than every development team needing to understand the specifics of each cloud provider, they interact with a standard platform API that works consistently. The platform team manages the provider-specific implementation details and can migrate workloads between providers without requiring changes to application code.
Backstage (from Spotify, now a CNCF project) has become the most widely adopted open-source foundation for internal developer platforms, providing a plugin-based architecture that integrates with cloud providers, CI/CD tools, observability platforms, and more. Building your IDP on Backstage gives you a community-supported foundation that reduces the build cost considerably.
*Lara IT Solutions designs cloud-native and multi-cloud architectures for UK enterprises. Call 0330 043 1930.*