What “Service Breadth” Means and When You Need It

AWS advertises more than 150 services. Hetzner sells servers, storage and a
few network components. Comparisons describe this as a difference in breadth and
usually imply that more is better. Whether it is depends entirely on how many of
those services you will use, and for most teams the honest answer is a
surprisingly small number.

What is actually in a large catalogue

Those services fall into recognisable groups:

• Core infrastructure: compute, block storage, object
  storage, networking. Every provider has these. This is the floor, not the
  differentiator.
• Managed data stores: relational databases, caches,
  document stores, search. Common in mid-sized catalogues too.
• Application services: queues, event buses, notification
  delivery, scheduled execution.
• Analytics and data: warehouses, streaming pipelines,
  transformation tooling.
• Machine learning: training platforms, model hosting,
  pre-built vision and language APIs.
• Developer tooling: build pipelines, artefact registries,
  deployment orchestration.
• Governance: identity, policy, audit logging, cost
  management.
• Specialised services for particular industries, devices and
  protocols, which account for a large share of the headline number and are
  irrelevant to almost everyone.

The headline count includes that last group, which is why the number is
larger than the number of services any single organisation uses.

What breadth genuinely buys you

Not having to build it. A managed queue with delivery
guarantees is weeks of engineering you are choosing not to do, plus the
operational burden you are choosing not to carry.

Integration that already works. Services within one platform
share identity, logging and networking. Assembling the same capability from
separate vendors means you own the integration.

Room to change direction. If the product turns towards
something you did not anticipate, the capability is already there rather than
being a migration.

Hiring and answers. Large platforms have large communities,
so when something breaks at two in the morning someone has already written about
it.

What it costs you

Complexity you pay for whether or not you use it. The
identity model, networking model and billing model of a large platform are
shaped by the need to support all of those services. You learn that complexity
to run one application.

More ways to misconfigure something. A larger surface means
more settings, and the well-known cloud security failures are
misconfigurations rather than breaches.

Pricing that is harder to predict. Many meters means many
sources of surprise, which is the subject of
why your first cloud bill is
higher.

A gentle pull towards deeper integration. Each proprietary
service you adopt makes the platform slightly harder to leave. That is not a
conspiracy, it is what using a platform means, but it accumulates.

A test worth applying

Write down the services your application will use in the next six months.
Not might use. Will use.

If that list is compute, object storage, a database and a load balancer, then
every provider on this site covers it, and breadth is not a factor in your
decision. Choose on price, support, regions and how much you like the interface.

If the list includes a managed data warehouse, a model serving platform, an
event streaming service or managed Kubernetes with real governance requirements,
breadth is the deciding factor and you should buy a platform that has those
things.

The middle ground exists

Providers like DigitalOcean and Linode occupy a sensible position: core
infrastructure plus managed databases, object storage, load balancers and
managed Kubernetes. That covers the large majority of what most applications
actually use, without the complexity of a catalogue built for every industry.

For a great many teams that is the correct amount of breadth, and the choice
is not between minimal and maximal but between adequate and excessive. The
comparison of
the developer-focused
providers covers where each of them draws that line.