Comparing the same service across clouds

The catalogue is organised by cloud, which is how you buy. It is also organised by service, which is how you decide. This guide is about the second view: 19 service hubs that put the same job side by side across 19 clouds, and what a comparison like that can and cannot settle.

Start from the service, not the cloud

A solution hub answers “who does managed Kubernetes, and what does each one's module actually prove?” rather than “what does AWS have?”. It is the right starting point when the cloud is still open, or when you are pricing a second one.

All 19 service hubs are listed together. A service only gets a hub when at least three clouds have a module for it, because a comparison of one cloud is not a comparison.

What actually ports between clouds

Less than the marketing suggests, and the honest split is roughly this. The shape of a workload ports: a container needs a registry, a scheduler and a load balancer everywhere. The interfaces sometimes port, which is why a Redis-compatible cache or a Postgres-compatible database is easier to move than a proprietary one. The identity model does not port at all, and the networking primitives port only in name.

That has a practical consequence when you read a hub. Two modules sitting in the same row are doing the same job, not offering the same knobs. Comparing their inputs one-to-one will mislead you; comparing what they provision, and what evidence each carries, will not.

Compare the evidence, not just the feature

Every hub shows each module's verification alongside it, and the distribution is usually uneven across clouds. That is not an accident of quality. Modules for clouds where we hold a sandbox account can be live-tested; the rest stop at static validation and say so. When you are choosing between two clouds that both do the job, the module with a real apply behind it is the lower-risk start, and that is often the deciding factor when nothing else separates them.

What that difference means for your decision is the subject of choosing a module by its evidence.

Where the comparison stops being useful

A hub compares modules, which means it compares what can be provisioned. It says nothing about the operational cost of running the thing afterwards, the egress bill, the support relationship, or whether your team has ever operated that provider before. Those usually dominate the decision, and none of them are visible in a module.

Use the hub to narrow the field to the clouds that can actually do the job with proven code. Decide between the survivors on the things a catalogue cannot see.

Once you have chosen

If several modules are going to work together, the reference architectures are curated sets that wire up as a foundation, in the order they connect. And installing through the registry protocol is how you pull any of them into your own configuration.