Docker & Kubernetes
Docker is non-negotiable. Every service we ship runs in containers — local development, CI, and production all share the same image. Kubernetes is opinionated about when it's the right tool: workloads that genuinely need orchestration (multi-service applications with complex pod-to-pod communication, ML inference fleets, long-running stateful services). For most projects, simpler container hosts (AWS ECS, Cloud Run, Fargate) do the job with a fraction of the operational overhead. We've seen too many teams adopt Kubernetes for a workload that ECS would have handled in a quarter of the engineering time — we'll talk you out of that mistake.
What you get
Real examples
ECS Fargate for a standard production app
Illustrative scenario: a SaaS deploys a Next.js + Python API in containers. AWS ECS Fargate handles orchestration, ALB + Auto Scaling handles load, CloudWatch handles monitoring. No Kubernetes complexity, no nodes to patch, deployment takes 2 minutes via GitHub Actions. Ops team of one can manage it.
Kubernetes for self-hosted LLM inference
Illustrative scenario: a sovereign-data client runs Llama 70B in their VPC. Kubernetes orchestrates vLLM pods across GPU nodes with horizontal autoscaling based on queue depth. KEDA scales pods on metrics, Prometheus + Grafana provides observability, IRSA handles AWS IAM. K8s is genuinely the right tool here — the alternatives don't handle the multi-GPU coordination story as cleanly.
Talking a team out of premature K8s adoption
Illustrative scenario: a startup's CTO is considering migrating their monolith to Kubernetes because they read it on Hacker News. We model the cost of migration vs ECS Fargate, identify zero benefit for their workload shape, recommend Fargate. They save 6+ months of engineering and meaningful ongoing ops budget. Sometimes the highest-value advice is 'don't'.
Common questions
When is Kubernetes the right call?
Three scenarios. One, multi-service applications with complex internal networking (service mesh territory). Two, ML inference fleets with GPU orchestration needs. Three, workloads where the team genuinely will operate K8s competently. Outside these, ECS Fargate or Cloud Run delivers the same outcomes with a fraction of the ops surface.
What about Kubernetes alternatives?
AWS ECS Fargate is our default for client projects without K8s-specific needs — managed, serverless containers, no nodes to maintain. Cloud Run on GCP is comparable. Both deliver the 'containers in production' story without K8s overhead. We use them on 4 out of 5 projects.
Do you use Docker Compose?
Yes, for local development on multi-service projects. One compose file spins up the app + database + dependent services. Production runs ECS / K8s / Fargate; Docker Compose doesn't make it to production.
How do you handle Kubernetes ops complexity?
Managed K8s (EKS, GKE) for the control plane, not self-managed. Use the cloud-native operators for managed services (databases, secrets) rather than running them in-cluster. Argo CD for GitOps deployment. Strong observability from day one — Prometheus + Grafana minimum, often supplemented with Datadog or NewRelic. The shape that minimises ongoing ops burden is well-understood; we follow it.
Can you migrate us off Kubernetes if it's overkill?
Yes, and we've done it. The pattern: containerise to standard Docker, deploy to ECS Fargate or Cloud Run, decommission the K8s cluster. Typical timeline is 4-8 weeks for a mid-sized application. The team's ongoing ops cost drops by a half to three-quarters in most cases.
Ready to get started?
Tell us about your project and we'll tell you honestly how we can help.
Get in Touch