What Makes a Compute Instance Portable?

While the core concept of virtual machines and containers are consistent across environments, hyperscalers introduce proprietary extensions, management interfaces, and integration patterns.

As such, a compute instance that appears portable on the surface may actually depend on dozens of provider-specific services, APIs, and configurations. 

True compute portability comes about when infrastructure is designed around open standards, provider-agnostic tools, and abstraction layers. These isolate applications from underlying platform differences. This approach enables organizations to deploy the same workload configurations across AWS, Azure, Google Cloud, or on-premises environments with minimal changes.

Ephemeral compute portability - Containers

Kubernetes has emerged as the industry standard for portable compute orchestration. Vanilla Kubernetes provides consistent APIs for deployment, networking, and storage. However, managed services like Amazon EKS often introduce provider-specific extensions. These extensions can undermine portability.

What Makes them Less Portable?

The most significant portability barriers in Kubernetes environments stem from identity management, storage, and networking implementations. Traditional AWS approaches use IAM Roles for Service Accounts (IRSA). This is an AWS-specific mechanism that injects AWS credentials into pods and creates dependencies on AWS IAM infrastructure. Storage implementations using EBS CSI drivers with AWS-specific volume types like gp3 or io2 result in persistent volume claims that cannot be directly migrated to other providers.

Increasing portability consists of the following:

• Portable Identity Mechanisms - Instead of native identity services, portable clusters use standard Kubernetes ServiceAccounts with token-based authentication, OpenID Connect (OIDC) integration with external identity providers like Auth0 or Keycloak, or certificate-based authentication using the Kubernetes Certificate API. These approaches work across any certified Kubernetes distribution and maintain compatibility with standard APIs.
• Storage Portability is achieved through the Container Storage Interface (CSI) with dynamic provisioning through StorageClasses. While the specific CSI driver varies by environment—AWS EBS CSI Driver in AWS, Azure Disk CSI Driver in Azure—the application's PersistentVolumeClaim objects remain identical across environments. This abstraction allows the same application to provision appropriate storage regardless of the underlying infrastructure.
• Networking Portability requires using standard Kubernetes networking interfaces rather than provider-specific implementations. Portable deployments use CNI implementations like Calico or Cilium that work across environments. Network policies are defined using standard Kubernetes NetworkPolicy resources. For service exposure, standard Kubernetes Ingress resources with portable controllers like NGINX or Envoy replace provider-specific ingress implementations. This ensures consistent behavior across deployments.

Persistent Compute Portability - Virtual Machines

While containers provide natural portability advantages, many workloads still require virtual machine deployments. This may be the case for monolithic applications, compliance requirements, or performance optimization. Achieving VM portability requires addressing image management, orchestration, and configuration challenges. 

What Makes them Less Portable?

The foundation of VM portability lies in standardized image building and initialization processes. Traditional approaches using AWS AMIs create images with AWS-specific initialization code and user data scripts. These rely on EC2-specific execution guarantees. These images cannot run on other platforms without significant modification.

Increasing portability consists of the following:

• VM Images - Portable VM architectures use tools like HashiCorp Packer to build machine images from single templates that target multiple providers. A single Packer template can include builders for AWS AMI, Azure Image, Google Cloud Image, and VMware OVA formats. It uses the same provisioning scripts across all targets. This approach ensures consistent system configuration and application deployment regardless of the underlying virtualization platform.
• Configuration and Bootstrapping Portability is achieved through cloud-init. This provides provider-agnostic syntax for common operations like user creation, package installation, and file writing. Cloud-init's data source abstraction obtains configuration from different providers while presenting a consistent interface to initialization scripts. This eliminates the need for provider-specific metadata services.
• VM Orchestration and Scaling require moving beyond provider-specific auto-scaling groups. Tools like HashiCorp Nomad or Terraform can manage VM lifecycles across multiple environments. Instance requirements are expressed in terms of CPU, memory, and storage specifications rather than provider-specific instance types. Mapping to appropriate instances is handled by configuration rather than hard-coded assumptions.

Learn more about building extending DevOps pipelines using open source tooling, along with all the other common infrastructure and service setups used by cloud-native organizations in our eBook: Architecting for Openness: A Guide for Avoiding Hyperscaler Lock-in.

‍