Same Patterns, Different Clouds
You've deployed your Task API to DigitalOcean. You've built a Hetzner budget lab. Now here's the insight that makes your skills portable across every cloud provider: 90% of what you learned is identical everywhere.
The provisioning command differs. The connection command differs slightly. But once you're connected to any Kubernetes cluster—whether it runs on DigitalOcean, Azure, Google Cloud, AWS, or Civo—every kubectl command, every Helm chart, every Dapr installation, every Ingress configuration works exactly the same way.
This is Kubernetes' superpower: true portability.
The Universal Pattern: Provision, Connect, Deploy
Every cloud deployment follows three steps:
┌─────────────────────────────────────────────────────────────────┐
│ STEP 1: PROVISION │
│ └── Create cluster using provider's CLI (provider-specific) │
├─────────────────────────────────────────────────────────────────┤
│ STEP 2: CONNECT │
│ └── Update kubeconfig to point to new cluster (minor variation)│
├─────────────────────────────────────────────────────────────────┤
│ STEP 3: DEPLOY │
│ └── kubectl, Helm, Dapr, Ingress (100% identical everywhere) │
└─────────────────────────────────────────────────────────────────┘
The ratio matters: you spend 10% of your time on provider-specific provisioning, 90% on universal Kubernetes operations.
Multi-Cloud Command Comparison
Here's the complete picture. Study this table—it reveals the pattern:
| Step | DigitalOcean | Azure (AKS) | Google (GKE) | AWS (EKS) | Civo |
|---|---|---|---|---|---|
| Provision | doctl kubernetes cluster create | az aks create | gcloud container clusters create | eksctl create cluster | civo kubernetes create |
| Connect | doctl kubernetes cluster kubeconfig save | az aks get-credentials | gcloud container clusters get-credentials | Automatic with eksctl | civo kubernetes config --merge --switch |
| Deploy (identical) | helm upgrade --install | helm upgrade --install | helm upgrade --install | helm upgrade --install | helm upgrade --install |
| Dapr (identical) | dapr init -k | dapr init -k | dapr init -k | dapr init -k | dapr init -k |
| Ingress (identical) | helm install traefik | helm install traefik | helm install traefik | helm install traefik | helm install traefik |
| Secrets (identical) | kubectl create secret | kubectl create secret | kubectl create secret | kubectl create secret | kubectl create secret |
| Scale (identical) | kubectl scale | kubectl scale | kubectl scale | kubectl scale | kubectl scale |
| Logs (identical) | kubectl logs | kubectl logs | kubectl logs | kubectl logs | kubectl logs |
Notice the pattern? Only the first two rows differ. Everything else is copy-paste identical.
Quick-Start Provisioning Commands
Here are production-ready provisioning commands for each major provider. Bookmark these—they're all you need to start on any cloud.
DigitalOcean (DOKS)
# Install CLI
brew install doctl # macOS
# Or: snap install doctl # Linux
# Authenticate
doctl auth init
# Provision cluster
doctl kubernetes cluster create task-api-prod \
--region nyc1 \
--node-pool "name=workers;size=s-2vcpu-4gb;count=2" \
--version latest
# Connect
doctl kubernetes cluster kubeconfig save task-api-prod
Output:
Notice: Cluster is provisioning, waiting for cluster to be running
..........
Notice: Cluster created, fetching credentials
Cost: ~$24/month for 2-node cluster
Azure (AKS)
# Install CLI
brew install azure-cli # macOS
# Or: curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash # Linux
# Authenticate
az login
# Create resource group
az group create --name task-api-rg --location eastus
# Provision cluster
az aks create \
--resource-group task-api-rg \
--name task-api-prod \
--node-count 2 \
--node-vm-size Standard_B2s \
--generate-ssh-keys
# Connect
az aks get-credentials --resource-group task-api-rg --name task-api-prod
Output:
Merged "task-api-prod" as current context in /home/user/.kube/config
Cost: ~$50/month for 2-node B2s cluster (includes Azure networking overhead)
Google Cloud (GKE)
# Install CLI
brew install google-cloud-sdk # macOS
# Or: snap install google-cloud-cli # Linux
# Authenticate
gcloud auth login
# Set project
gcloud config set project YOUR_PROJECT_ID
# Provision cluster
gcloud container clusters create task-api-prod \
--zone us-central1-a \
--num-nodes 2 \
--machine-type e2-small
# Connect
gcloud container clusters get-credentials task-api-prod --zone us-central1-a
Output:
Fetching cluster endpoint and auth data.
kubeconfig entry generated for task-api-prod.
Cost: ~$40/month for 2-node e2-small cluster
AWS (EKS)
# Install eksctl
brew install eksctl # macOS
# Or: curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp && sudo mv /tmp/eksctl /usr/local/bin
# Provision cluster (eksctl handles credentials automatically)
eksctl create cluster \
--name task-api-prod \
--region us-east-1 \
--nodes 2 \
--node-type t3.small
Output:
2025-01-15 10:30:00 [!] eksctl version is newer than cluster control plane version
2025-01-15 10:30:05 [i] creating cluster "task-api-prod" in "us-east-1"
...
2025-01-15 10:45:00 [!] cluster ready
Cost: ~$75/month (EKS control plane fee + EC2 instances)
Civo
# Install CLI
brew install civo # macOS
# Or: curl -sL https://civo.com/get | sh # Linux
# Authenticate
civo apikey save mykey YOUR_API_KEY
# Provision cluster
civo kubernetes create task-api-prod \
--size g4s.kube.small \
--nodes 2 \
--region NYC1 \
--wait
# Connect
civo kubernetes config task-api-prod --merge --switch
Output:
The cluster task-api-prod has been created
Merged "task-api-prod" as current context in ~/.kube/config
Cost: ~$20/month for 2-node small cluster (fastest provisioning: ~90 seconds)
After Provisioning: Everything Is Identical
Once connected, your existing commands work without modification:
# Same on ALL providers
kubectl get nodes
helm upgrade --install task-api ./charts/task-api
dapr init -k
helm install traefik traefik/traefik
kubectl create secret generic api-token --from-literal=TOKEN=xxx
kubectl get pods
kubectl logs deployment/task-api
This is why your skills are portable. The cloud provider is an implementation detail. Your Kubernetes expertise transfers completely.
Provider Selection Guide
When does each provider make sense?
| Provider | Best For | Key Advantage | Watch Out For |
|---|---|---|---|
| DigitalOcean | Startups, small teams | Simplicity, predictable pricing | Limited regions |
| Civo | Budget labs, learning | Fastest provisioning (~90s), cheapest | Smaller ecosystem |
| Azure | Enterprise, hybrid | Azure DevOps integration, compliance | Complexity, cost |
| Google Cloud | ML/AI workloads | GKE Autopilot, tight GCP integration | Pricing surprises |
| AWS | Large enterprises | Ecosystem breadth, market presence | EKS complexity, cost |
| Hetzner | Personal labs | Lowest cost ($3-5/mo for VPS) | Manual K3s setup |
For this book, we use DigitalOcean (production) and Hetzner (budget lab) because they optimize for learning: simple CLIs, predictable pricing, fast feedback loops.
The Career Value of Multi-Cloud Skills
Here's why this lesson matters beyond just commands:
Scenario 1: Your company uses Azure. A client requires AWS deployment. With multi-cloud skills, you swap two commands and deploy the same Helm charts.
Scenario 2: You interview at a company using GKE. You've only used DigitalOcean. You explain: "I know Kubernetes—the provider is just the provisioning step. Everything else transfers directly."
Scenario 3: Costs increase on your current provider. You migrate by changing one script and redeploying identical configurations.
This is the power of cloud-agnostic skills: you're not locked to any vendor. Your knowledge compounds across every platform.
Try With AI
Use your AI companion to explore multi-cloud patterns.
Prompt 1: Generate Provider-Specific Commands
I know how to deploy to DigitalOcean using doctl. Generate the equivalent
provisioning and connection commands for Azure AKS. Walk me through:
1. What's different about Azure's approach?
2. What extra concepts does Azure add (resource groups)?
3. After I'm connected, confirm that kubectl and Helm work identically.
What you're learning: Pattern translation—how the same abstract workflow maps to different concrete implementations.
Prompt 2: Analyze Cost Trade-offs
I have a Task API that runs on 2 nodes with 4GB RAM each. Compare monthly
costs across DigitalOcean DOKS, Civo, Azure AKS, GKE, and EKS for this
workload. Include any hidden costs (load balancers, egress, control plane
fees). Which provider gives best value for a learning environment vs
production traffic?
What you're learning: Cost analysis—understanding the full pricing picture beyond compute, including networking and platform fees.
Prompt 3: Design a Multi-Cloud Migration
My team currently deploys to DigitalOcean. Leadership wants us to also
support Azure for enterprise clients. Design a migration strategy that:
1. Keeps our Helm charts identical
2. Uses environment variables for provider-specific configs
3. Maintains a single CI/CD pipeline with provider as a parameter
What patterns would make this work?
What you're learning: Architecture design—creating deployments that work across providers without duplication.
Safety Note
When experimenting with cloud providers, always set up billing alerts first. Each provider has a different free tier and pricing model. Start with small clusters (2 nodes, small instance sizes) and tear them down when not in use. Never leave clusters running overnight during learning sessions unless intentionally testing persistence.
Reflect on Your Skill
Test your multi-cloud-deployer skill:
- Can it generate provisioning commands for at least 3 providers?
- Does it emphasize the "provision, connect, deploy" universal pattern?
- Does it include cost comparison guidance?
If gaps exist, update your skill with multi-cloud quick-start references and the command comparison table from this lesson.