Is Cloud Computing Killing Innovation? A Balanced Look at the Dependency Problem

The cloud was supposed to democratise computing. In many ways it has — a two-person startup can provision infrastructure that would have cost a Fortune 500 company tens of millions a decade ago. But as cloud adoption has matured from novelty to default, a quieter argument has emerged: by standardising on managed services and removing infrastructure decisions from engineering teams, cloud computing may be narrowing the range of technical approaches considered, making competitive differentiation harder, and creating financial dependencies that constrain future choices.

This is worth examining carefully rather than dismissing as nostalgia for on-premise server rooms.

The Commoditisation Argument

When AWS launches a new managed service — a message queue, a graph database, a search engine — thousands of companies immediately have access to infrastructure that, a year earlier, they would have had to build themselves. That is efficiency. But it is also standardisation.

When every company uses the same managed Kafka service, the same managed Elasticsearch equivalent, the same managed caching layer, the implementations converge. The engineering decisions that used to differentiate organisations — their specific tuning choices, their custom extensions, their operational expertise built over years — become irrelevant. Everyone runs the same thing with roughly the same configuration.

In some domains, that convergence is fine. Nobody needs a differentiated S3 experience. But in areas closer to the core product, homogeneous infrastructure can mean homogeneous capability. If every competitor uses the same vector database service and the same embedding model API, what is the differentiator?

Innovation Surface Narrowing Over Time
-----------------------------------------
2010: Build your own [message queue / search / cache / CDN]
      --> Deep expertise, differentiation, high maintenance cost

2018: Use managed services for all of these
      --> Fast, cheap, low maintenance, everyone uses the same thing

2024: Use LLM APIs, vector DBs, ML platforms (all managed)
      --> Even core ML capabilities commoditised
      --> Where does differentiation come from?

Vendor Lock-In Is Real and Underestimated

The managed service advantage comes with a dependency that is rarely fully appreciated at adoption time. When you use AWS Lambda with API Gateway, DynamoDB, SQS, and S3 in a tightly integrated architecture, you have not just rented infrastructure — you have built your application on top of a set of proprietary APIs and pricing models.

Moving away from that architecture is not a matter of re-pointing a configuration file. It requires:

• Rewriting integration code for each replaced service
• Replacing operational tooling (monitoring, alerting, cost management)
• Retraining teams on different APIs and mental models
• Accepting service gaps (the new provider’s equivalent service may not have feature parity)
• Absorbing data egress costs for migrating data out of the current provider

The lock-in becomes more severe as you adopt higher-level managed services. Switching EC2 to Azure VMs is relatively straightforward — both are Linux VMs. Switching from AWS Bedrock to Azure OpenAI is substantially more complex. Switching from a proprietary AWS ML pipeline built on SageMaker, Feature Store, and Model Monitor to a different provider’s equivalent requires near-complete reconstruction.

A company that built its data infrastructure on BigQuery and Pub/Sub is effectively a Google customer for the foreseeable future. That dependency shifts the power dynamic in contract negotiations.

The Cost Ceiling Problem

Cloud pricing scales with usage, which is the point. But for large, stable workloads that run continuously, the economics can invert.

The general rule of thumb that circulates among infrastructure engineers: if a workload is large, predictable, and needs to run 24/7 for years, bare metal or co-located hardware may be 50–80% cheaper than equivalent cloud compute. DHH (David Heinemeier Hansson) and the Basecamp team published their analysis in 2023 showing they expected to save $7 million over five years by repatriating workloads from cloud. 37signals is a specific case, but the directional math is not unusual.

For companies at sufficient scale, the cloud’s flexibility premium costs real money. And that cost may be constraining investment in other areas — including actual product innovation.

Cost Curve: Cloud vs Owned Infrastructure
-------------------------------------------
Cost
  |                        ___
  |                 ______/
  | Cloud          /
  |               / <-- break-even zone
  |              /
  | Own HW -----/
  |____________ ____________________
                Scale / Workload Size

Below break-even: cloud wins (flexibility, no capex)
Above break-even: owned infrastructure may win (total cost)

The Counter-Argument: Cloud Enabled Innovation That Could Not Exist Otherwise

The argument against this critique is compelling: most of the innovative products of the last decade would not exist without cloud infrastructure.

Netflix re-invented video delivery at global scale. Uber built real-time logistics. Airbnb launched without buying a single server. Zoom scaled to 300 million daily meeting participants in three months during the pandemic. None of this is possible without elastic cloud infrastructure that can scale from zero to global capacity without capital expenditure.

The companies that built genuinely new things did not build them on infrastructure; they built them on top of commoditised infrastructure. The differentiation was the product insight, the algorithm, the user experience, the business model — not the database engine or the networking stack. If cloud commoditises infrastructure, it frees engineering talent to focus on what actually differentiates.

A Calibrated View

The truth is that cloud dependency affects different types of companies differently.

For startups and mid-size companies building software products, cloud infrastructure is almost certainly a net positive for innovation. The cost and time saved on infrastructure operations funds product work. The managed services accelerate time-to-market. The elasticity enables experimentation.

For large enterprises with stable, predictable workloads and the engineering headcount to run infrastructure, selective repatriation of cost-inefficient workloads makes sense. Not everything needs to run on public cloud.

For any company, the risk worth managing is deep dependency on proprietary managed services in areas that define the product. Using SQS for a message queue is a reversible decision. Building your ML pipeline entirely on SageMaker’s proprietary training and deployment formats over five years is a much stickier dependency.

The engineers who ask “should we use the managed service or build it ourselves?” are asking a question that deserves a real answer based on the specific workload, the company’s scale, and the strategic importance of that capability — not a reflexive answer based on either ideology (cloud always wins) or nostalgia (we should own our infrastructure). The honest answer is almost always: it depends.