What it is
Google Cloud, often called GCP, is Google's public cloud. Resources live in a project, and projects live in folders and organisations if a company has set that up. The project is the unit of billing and of enabling APIs. IAM grants roles to users and to service accounts. Cloud Run runs a container as an HTTP service. Compute Engine is a virtual machine. Cloud Storage stores objects. Cloud SQL manages relational databases. BigQuery is an analytics warehouse, not your application's transactional database. Vertex AI is the umbrella for many of Google's hosted model and ML tools.
The shape matches AWS and Azure: identity, compute, data, logs. The names differ. Picking a cloud because one service is nicer is reasonable. Picking one because a diagram used its colours is not.
Why and when it is used
Choose GCP when the organisation already uses it, when Cloud Run's model fits a container you want on the internet quickly, or when your data and analytics path is already BigQuery. Choose it for a specific AI API only after you have read where prompts are processed and stored. A startup can be happy on GCP, AWS or Azure. The failure mode is using all three by accident because three teams each had a credit.
Do not enable a project per experiment and then lose them. Name projects. Attach billing alerts. A project with no owner is how a key survives a former employee.
How it works
You authenticate with a user account or a service account. Application code on Cloud Run should use the runtime service account, not a JSON key downloaded to a laptop and copied into the image. APIs are off until you enable them, which is surprising the first time a call returns that the API is disabled. Region matters for latency and for where data sits. Cloud Run scales copies of your container, including to zero if you allow it; cold starts are the trade. Environment variables and secrets (Secret Manager) configure the container at deploy time.
IAM roles are broad (Owner, Editor) or specific. Editor on a project is not a reasonable runtime identity. Logs go to Cloud Logging. If you do not look at them once during the prototype, you will not know how when production fails.
Technologies and dependencies
A project, billing with an alert, the gcloud CLI, and IAM that does not rely on a long-lived JSON key. A container if you use Cloud Run (Docker). A database if you have state. Environment Variables and Secret Manager for configuration. The same application can run elsewhere; do not import GCP client libraries into code that only needs a Postgres connection string.
How to get started
- Create a project with a name you will recognise. Set a budget alert.
- Install
gcloud, log in, and set the project as the default so you do not create resources in the wrong place. - Deploy a small container to Cloud Run that returns a configuration value. Give it a service account with no extra roles.
- Add a secret in Secret Manager and mount it. Confirm the value is not in the image.
- Open the logs and find the request.
- Delete the service when the experiment ends, or expect the bill for idle minimum instances if you set them.
Do not download a service-account key "because the tutorial did" if the runtime can use an attached identity. Keys leak.
Cautions and trade-offs
Project IAM is easy to make wider than the task. A key file committed once is a permanent credential until you revoke it. Public buckets and allUsers bindings on storage are the usual data leaks. Check them.
Cloud Run's simplicity hides a few sharp edges: request timeouts, body size limits, and concurrency (one container handling many requests) which will break an app that stores user state in a global variable. BigQuery is the wrong place for row-by-row transactional updates. And Google Cloud's product names change. Learn the idea (run a container, store an object, grant a role) so a rename does not erase your mental model. The same advice applies to every cloud on this site.