What we build with it
Google Cloud is where the containers we build actually get somewhere to run. Managed Kubernetes, object storage, managed databases, load balancing and TLS termination, plus the identity and networking around them.
The reason to use a managed platform is not that it is cheaper per CPU — often it is not. It is that control-plane upgrades, certificate rotation and node patching stop being someone's job. On a small team that is the difference between infrastructure being a background concern and being a person.
Where it fits
Under the deployment story: containers built in CI, packaged with Helm, applied to a managed cluster. The application code stays portable — nothing in it knows which cloud it is on, which is deliberate.
When we recommend it
For products that need a real cluster, autoscaling, or managed data services, and for teams who would rather not own the undifferentiated parts of running servers.
We are not dogmatic about which cloud. The design we aim for is one where the choice is reversible: containers, Kubernetes and Helm are portable, so a move is a migration of managed services rather than a rewrite. If you are already on another provider, or your compliance requirements point somewhere specific, that is usually the stronger argument.
For a single small service with steady traffic, a cluster of any kind is more than the job needs — a managed container runtime is less to operate and less to get wrong.