Many of us have been there. You’re whiteboarding a new system. It needs to be containerized, it needs to scale, and it needs to be resilient. The hand reaches for the marker and draws the familiar hexagon: Kubernetes.
It’s the industry standard. It’s what the “big players” do. But I believe infrastructure should be a response to a requirement, not a default setting.
I’ve been guilty of the “K8s-first” mentality myself. But in 2026, the “Complexity Tax” of a cluster is harder to justify than ever.
What are you actually paying for?
When you choose GKE (or any K8s flavor), you aren’t just choosing a way to run containers. You are choosing to manage:
- Node Pools: Sizing them, scaling them, and worrying about bin-packing.
- Control Planes: Handling upgrades and version compatibility.
- The Ingress Maze: Managing SSL, load balancers, and complex networking manifests.
For a massive microservices mesh with complex inter-service dependencies, that’s a fair price to pay. But for a collection of stateless APIs or background workers, it’s often overkill.
The Evolution of the “Serverless” Container
The reason many of us skipped “Serverless” in the past was because it felt too restrictive. We wanted the power of a microVM, not the limitations of a “function.”
However, Cloud Run has evolved into a powerhouse that bridges this gap. It isn’t just for “Hello World” APIs anymore. With second-gen execution environments, it has become the pragmatic choice for heavy-duty workloads.
Beyond the API: The Serverless Worker Pool
One of the most underutilized patterns for Cloud Run is using it as a distributed worker pool.
Because of its deep integration with Eventarc and Pub/Sub, you can build a system that:
- Listens for messages from Kafka, RabbitMQ, or Pub/Sub.
- Scales from zero to a thousand instances in seconds.
- Processes the job and immediately scales back down.
You get the same parallel processing power of a GKE consumer group, but with zero idle costs and zero node management.
Why “Senior” means “Simple”
The most “senior” architectural move isn’t picking the most powerful tool; it’s picking the tool that lets you delete the most management overhead.
If you can fit your use case into a managed environment like Cloud Run—leveraging sidecars for observability and persistent mounts for state—you free up your team to focus on the Go code, not the YAML.
The Rule of Thumb: If your infrastructure is taking more of your time than your business logic, you’re paying too much tax.