Why We Didn’t Buy Kubernetes

Part 1. The Best Architecture Was the One We Never Built

Cloud projects rarely fail because engineers choose bad technology.

More often, they fail because engineers choose excellent technology for the wrong problem.

That distinction is uncomfortable because it challenges one of the strongest instincts in engineering: the desire to build for the future. We like systems that scale almost infinitely, survive failures automatically, and handle workloads that may never exist. Modern cloud platforms make those ambitions technically achievable. The question is whether they are economically justified.

This case started with what appeared to be a routine architecture review.

The company was preparing the next phase of its platform. Customer growth was healthy, new products were planned, and engineering teams expected the number of services to double within eighteen months. The existing platform relied heavily on Cloud Run. More than forty independent services processed API requests, data transformations, scheduled jobs, and machine learning inference. Deployments were automated, operational incidents were rare, and infrastructure management required surprisingly little effort.

From an engineering perspective, the platform was successful.

Then someone asked a familiar question.

“Shouldn’t we move everything to Kubernetes before we become too large?”

Nobody intended to create unnecessary work. The proposal came from experienced architects who had previously managed Kubernetes clusters in other organizations. Their arguments sounded convincing.

Kubernetes offered greater flexibility.

It supported advanced deployment strategies.

It provided complete control over networking.

It allowed fine-grained resource management.

Most importantly, it was perceived as the platform used by “serious” technology companies.

Within two weeks, the proposal had evolved into a formal migration initiative. Preliminary estimates suggested that the transition would take approximately nine months and involve almost every backend engineer in the company. The technical presentation contained beautiful architecture diagrams. Service meshes, autoscaling policies, node pools, ingress controllers, private networking, workload identity, and disaster recovery plans were explained in impressive detail.

The presentation ended with a single conclusion.

“Our platform has outgrown Cloud Run.”

The board looked toward the CTO, expecting approval.

Instead, he asked a question that nobody in the room had prepared for.

“What business problem are we solving?”

The room became unusually quiet.

One architect answered confidently.

“Scalability.”

The CTO nodded.

“What is our current peak traffic?”

The operations lead opened the monitoring dashboard.

“About six hundred requests per second across all services.”

“And what is the current utilization of Cloud Run?”

Another pause.

“Approximately thirty-two percent.”

“So,” the CTO continued calmly, “we’re proposing a nine-month migration to solve a scalability problem that doesn’t currently exist.”

Nobody argued.

Instead, another architect shifted the discussion.

“We’re preparing for future growth.”

That answer sounded much stronger.

After all, responsible engineering is supposed to anticipate future requirements rather than react to crises.

The CTO agreed.

“Good. Then let’s quantify the future.”

He walked to the whiteboard.

“What customer growth requires Kubernetes?”

Nobody knew.

“What latency target cannot be achieved on Cloud Run?”

Silence.

“What compliance requirement forces us to manage Kubernetes ourselves?”

No answer.

“What workload cannot run on Cloud Run today?”

Again, nothing.

For the first time, the migration proposal was being evaluated not as a technical achievement but as an investment.

The discussion changed immediately.

Instead of comparing features, the team started comparing business outcomes.

Engineering estimated approximately 4,500 development hours for the migration.

Finance calculated the opportunity cost of delaying planned customer features.

Operations estimated that two engineers would need to dedicate a significant portion of their time to cluster maintenance, upgrades, security patches, and operational support after migration.

The total cost of ownership looked very different from the architecture diagram.

Then the data engineering manager raised a point that nobody had previously considered.

“Our current deployment failure rate is below one percent. Mean deployment time is under four minutes. Production incidents caused by Cloud Run are almost zero. If we migrate, which KPI actually improves?”

No one could answer immediately.

The proposal had successfully demonstrated what Kubernetes could do.

It had not demonstrated why the business needed it.

The CTO ended the meeting with a simple assignment.

“Don’t prepare another Kubernetes presentation.”

He smiled.

“Prepare a financial justification.”

That sentence completely changed the project.

Over the following week, the architecture team stopped debating technology and started collecting evidence. They compared operational metrics, projected infrastructure costs, estimated engineering effort, and interviewed product owners about roadmap priorities. The objective was no longer to prove that Kubernetes was powerful.

Everyone already knew that.

The objective was to determine whether its additional complexity would produce measurable business value within the next three years.

The answer surprised almost everyone.

Complexity Is Not a Feature

The financial analysis took considerably longer than anyone expected. Not because the numbers were difficult to calculate, but because they challenged an assumption that had quietly existed within the engineering organization for years.

The assumption was simple.

As a company grows, it eventually “graduates” to Kubernetes.

Nobody could remember exactly where that belief had originated. Some engineers had worked with Kubernetes at previous companies. Others had attended conferences where almost every architecture diagram included a cluster somewhere in the middle. Recruitment advertisements listed Kubernetes experience as a competitive advantage, and many technology blogs described it as the natural destination for modern cloud platforms.

The migration proposal had been built on an industry trend rather than on business evidence.

The architecture team decided to compare the existing platform with the proposed one using a single rule: every claimed benefit had to be supported by measurable business impact.

The results were unexpectedly uncomfortable.

Question	Cloud Run	GKE	Business Impact
Handles current traffic?	Yes	Yes	No difference
Automatic scaling?	Native	Requires configuration	Minor advantage to Cloud Run
Infrastructure maintenance	Managed by Google	Internal responsibility	Advantage Cloud Run
Deployment flexibility	High	Very High	No measurable business benefit
Operational complexity	Low	High	Advantage Cloud Run
Engineering hours required	Minimal	Significant	Advantage Cloud Run

The table produced an awkward silence.

Nobody questioned Kubernetes as a technology. It remained one of the most capable orchestration platforms available. The problem was much simpler.

The company did not need most of its capabilities.

The finance department added another perspective.

The migration itself was estimated to consume roughly 4,500 engineering hours. Based on internal costs, that represented an investment of approximately $650,000 before a single business feature reached customers. Once the migration finished, annual operational costs would also increase. Cluster administration, version upgrades, security maintenance, networking, monitoring, and platform support would require dedicated engineering capacity that Cloud Run simply did not.

Then Product Management entered the discussion.

“What features are we postponing while engineers spend nine months rebuilding infrastructure?”

The answer was uncomfortable.

Two customer-facing products.

One fraud detection improvement.

Three analytics initiatives requested by commercial teams.

Several performance optimizations already committed to enterprise clients.

For the first time, Kubernetes was competing not against Cloud Run, but against business growth.

That changed everything.

One week later, the CTO asked the architects to perform one final exercise.

“Imagine we have already completed the migration. It is one year later. Tell me exactly what our customers can do that they cannot do today.”

The room remained silent longer than anyone expected.

Eventually, one architect answered honestly.

“They probably wouldn’t notice any difference.”

It was the most valuable sentence spoken during the entire project.

Engineers often measure success through technical sophistication. Customers measure success through faster products, better experiences, and new capabilities. Those two perspectives occasionally align—but not always.

The board cancelled the migration.

That decision surprised several engineers, particularly those who had already started experimenting with Kubernetes manifests and deployment strategies. Some initially viewed the cancellation as a lack of technical ambition.

Six months later, the numbers told a different story.

Instead of rebuilding infrastructure, engineering teams delivered seventeen customer-facing features, reduced API response times by almost thirty percent, expanded into two additional markets, and launched a machine learning service using Cloud Run without introducing any additional operational burden.

Infrastructure costs remained predictable.

Operational incidents remained low.

Deployment frequency increased.

The platform continued scaling without difficulty.

Ironically, the architecture team still documented a future Kubernetes strategy. The difference was that it now contained measurable entry criteria instead of assumptions.

The document stated that GKE would only be reconsidered if at least one of the following conditions became true:

• Cloud Run service limitations blocked business growth.
• Regulatory requirements demanded infrastructure control unavailable in managed serverless services.
• Workloads required orchestration patterns impossible or economically inefficient on Cloud Run.
• Operational metrics demonstrated that platform limitations, rather than product development, had become the company’s primary bottleneck.

Until then, Cloud Run remained the preferred platform.

Not because Kubernetes was inferior.

Because architecture should solve today’s business problems while remaining flexible enough for tomorrow’s opportunities.

One of the architects later admitted something that became an internal joke.

“We almost spent three quarters of a million dollars proving that Google engineers are very good at managing Kubernetes.”

Everyone laughed.

The joke contained an important truth.

Google already operates Kubernetes at extraordinary scale. Managed services like Cloud Run exist because many companies gain far more value from building products than from operating clusters.

The objective of cloud architecture is not to maximize technological complexity.

It is to maximize business outcomes per engineering hour invested.

Executive Takeaways

• The most advanced technology is not automatically the most valuable investment.
• Every infrastructure migration should compete against product development for budget and engineering capacity.
• Managed services reduce not only operational work but also organizational complexity.
• Future scalability should be justified by measurable forecasts, not by industry trends.
• A migration is successful only if customers or the business experience meaningful benefits.

One Question Every CTO Should Ask

“If we completed this migration tomorrow, what would our customers be able to do that they cannot do today—and is that benefit worth the investment?”