Cloud Installers in 2016: kops on AWS vs Azure Container Service

Introduction

As Kubernetes moved beyond DIY scripts in 2016, cloud-specific installers emerged to streamline production rollout. On AWS, kops (Kubernetes Operations) became the go-to tool for creating well-architected clusters. Microsoft answered with Azure Container Service (ACS), previewing Kubernetes as a managed control plane option alongside Swarm and DC/OS.

This comparison mattered because it highlighted an inflection point: teams were no longer debating whether Kubernetes was viable, but who should own day-2 operations—your team, or your cloud provider. The trade-offs show up quickly in upgrades, networking, and how fast you can recover from failure.

Historical note: ACS and the azure CLI flow shown below reflect the 2016 preview era. The lesson (control vs convenience) still applies, even though today’s equivalents look different.

kops Highlights

Infrastructure-as-Code: Generates CloudFormation/terraform for VPCs, subnets, IAM roles, and Auto Scaling Groups.
State Store: Persists cluster manifests in S3, enabling iterative updates and rollbacks.
HA Ready: Supports multi-master setups, etcd topology choices (stacked vs external).
Rolling Updates: kops rolling-update cluster orchestrates OS and component upgrades with PDB awareness.
Add-Ons: Installs DNS (CoreDNS), logging, and optional networking plugins via manifests.

Azure Container Service Preview

Managed Control Plane: Microsoft operated the masters; users managed agent nodes.
Template-Driven: Azure Resource Manager (ARM) templates spun up agent pools with Docker, Mesos, or Kubernetes.
CLI Integration: azure acs create --orchestrator-type=kubernetes simplified initial rollout.
Networking: Leveraged Azure Virtual Networks; kube-proxy configured load balancing rules automatically.
Support & Limits: Preview constrained to select regions, with manual upgrades and limited cluster size.

Feature Comparison (Late 2016)

Capability	kops (AWS)	ACS Kubernetes Preview
Control Plane Ownership	Customer-managed EC2 instances	Microsoft-managed masters
Upgrades	`kops upgrade cluster` + rolling update	Delete/recreate (no in-place upgrade)
HA Masters	Yes (multi-AZ)	Single-master during preview
Networking Options	Flannel, Calico, Weave, Cilium (manual)	Azure networking defaults
Customization	Deep (edit cluster spec, terraform export)	Limited to ARM parameters
Cost Visibility	Direct EC2/EBS billing	Control plane free (preview), pay for VMs

Choosing in 2016

Operational Control: Teams wanting full control gravitated to kops; they tuned etcd, networking, and OS images.
Managed Experience: Organizations prioritizing minimal ops overhead tested ACS despite preview limitations.
Hybrid Strategy: Some teams prototyped on ACS while running production on kops until Azure’s managed offer matured (later AKS).
Community & Support: kops enjoyed active SIG AWS support; ACS users relied on Microsoft preview channels.

Practical considerations teams ran into

Upgrade story: if you can’t do in-place upgrades, you’re really planning for re-creation and cutover—great for stateless, painful for stateful.
Networking defaults: “works by default” can hide sharp edges (IP exhaustion, LB limits, outbound SNAT behavior) until you hit scale.
Access & audit: managed control planes reduce toil, but can also reduce visibility when debugging API server behavior.

Getting Started Quickly

# kops (AWS)
kops create cluster \
  --name=prod.k8s.local \
  --zones=us-west-2a,us-west-2b \
  --state=s3://kops-state \
  --yes

# Azure Container Service preview
azure acs create \
  --orchestrator-type=kubernetes \
  --resource-group k8s-rg \
  --name k8s-cluster \
  --location westus \
  --agent-count 3

Conclusion

2016 marked the turning point from handcrafted clusters to standardized cloud installers. kops empowered AWS users with production-grade automation, while Azure laid the groundwork for its managed Kubernetes service. Both efforts set expectations for the fully managed platforms that would dominate in subsequent years.