Google Cloud

Google Cloud solves a specific problem well: it moves you from administering machines to administering services. The database upgrades itself, storage does not fill up on a Sunday, and the cluster replaces a dead node without anyone noticing. When that is the problem, it pays. When it is not, it is a second platform to maintain on top of the one that serves users.

The honest test is what the workload actually does. With predictable traffic and a single service, a well-configured server wins on simplicity and on cost. With several services, teams that release independently and peaks nobody can predict, the orchestration pays for itself.

Where it is justified, most of the value sits in the boring parts: resource requests and limits that reflect measured usage rather than guesses, health checks that fail for the right reasons, secrets that never reach an image, and manifests templated per environment so staging and production differ only in what should differ.

The experience behind this is operating platforms of that size on GKE, with Cloud SQL as the managed database, Cloud Storage for served content and images published to Artifact Registry from continuous integration. The conclusion that follows is usually to use less infrastructure, not more.

What decides the bill is not the hourly price of the machines. It is how often data crosses zones, how many replicas are switched on just in case, and how long a test environment nobody turns off keeps running. Those three explain most end-of-month surprises, and all three are fixed by design decisions rather than by changing provider.

What stands out most when taking over someone else's project is how much infrastructure is switched on that nobody can explain: a test cluster from two years ago, replicas raised for a peak that has passed, storage buckets with no lifecycle policy. That inventory is always the first deliverable, because it decides both next month's bill and what can safely be touched.