A recurring mistake in platform selection is treating “big cloud” and “developer cloud” as tiers of the same thing, as though one is simply a larger version of the other. They are better understood as different bargains.
The bargain each one offers
-
Hyperscale platforms
Offer nearly every capability you could need, at the cost of requiring you to make many decisions – about identity, networking, instance families, storage classes and more – before anything runs.
-
Developer-focused platforms
Offer a smaller, opinionated set of building blocks with sensible defaults, at the cost of occasionally not having the thing you need.
Neither bargain is superior. A team with platform engineers benefits from the first. A team of five shipping a product usually benefits from the second.
Where the difference bites
| Area | Hyperscale | Developer cloud |
|---|---|---|
| Time to first running service | Longer; more setup decisions | Shorter; defaults chosen |
| Identity model | Powerful and intricate | Simpler, fewer options |
| Networking | Explicit VPC design expected | Sensible default network |
| Pricing | Usage-based, needs modelling | Mostly flat and predictable |
| Unusual requirements | Usually a managed service exists | You may build it yourself |
| Scaling ceiling | Very high | High enough for most workloads |
The scaling ceiling is rarely the deciding factor
Teams often choose a hyperscaler because of where they might be in three years. It is worth being honest about that. Most applications never approach the limits of a developer cloud, and the ones that do usually rewrite significant parts of themselves on the way there anyway. Choosing for a hypothetical future scale has a real cost in present velocity.
A reasonable rule of thumb
- If you need a specific managed service that only exists on one platform, go there.
- If a compliance requirement names a platform or region, go there.
- If you have dedicated platform engineers, hyperscale pays off.
- Otherwise start on the simpler platform and revisit when a real constraint appears.
Moving a containerised application between platforms later is work, but it is bounded work, and it is far less than the cost of operating a complex platform badly for two years.
Summary
Capability is not the differentiator; decision load is. Pick the platform whose bargain matches your team’s size and skills, and be willing to revisit the choice when the workload actually demands it. You can compare both kinds side by side in the cloud account catalogue.