Google Cloud

Your proposal says Google Cloud. Here's what you'd be renting, and who runs it.

The short answer

Google Cloud is one of the three large general-purpose clouds, alongside AWS and Microsoft Azure. You rent computing, storage and databases by the second instead of buying servers. It gets picked most often for data work, machine learning and Kubernetes, which came out of Google. The constraint is who operates it afterwards.

You know Google, and that's the problem, because what you know is the search box and Gmail. The thing in your proposal is a rental business for computing that most of Google's customers never see. Here's what it is, where it's genuinely the better pick, and what it asks of your side.

Rented computing, sold by the project

Underneath the product names, a cloud is a rental arrangement. Google rents you slices of its data centres: a machine by the second, storage by the gigabyte, a database somebody else patches. The charge stops when the thing stops.

It's the same category of product as AWS and Microsoft Azure. All three bill for use rather than for a licence, and mostly sell the same ideas under different names. By the usual reporting AWS is largest, Azure second, Google Cloud third, which tells you how many people you can hire and little else.

The organising idea worth knowing is the project. Every machine, database and storage bucket belongs to exactly one, billing attaches to one, and projects are what change hands at handover. So ask early whose organisation yours will sit in. It's a two-minute question at the start of a build and a lawyer's question at the end.

  1. Your organisation

    Set once

    The top of the tree, tied to a domain your company owns. Policy set here applies to everything below.

  2. Folders

    Optional

    Optional grouping, usually by team or to keep the test environment away from the live one. Small builds skip them.

  3. Projects

    What changes hands

    The unit that owns things. Every resource belongs to one, and this is what transfers at handover.

  4. Resources

    The running parts

    The machines, databases, storage buckets and queues that actually run, each named inside its project.

  5. Billing account

    Your card

    Attached to a project, and it can belong to whoever created it. Check the name on it is yours.

The hierarchy above a running machine: an organisation setting policy, optional folders, the project that owns every resource and changes hands at handover, then the resources and the billing account attached to that project.

Google built it for itself first, and that shows

Google didn't set out to sell computing. It built infrastructure to index the web and serve video to much of the planet, and the problems it solved were about data and scale rather than about hosting somebody's website. The commercial cloud came out of that machinery later.

Two internal systems have public descendants at the centre of the platform. Borg, which decided what ran on which machine, is the ancestor of Kubernetes, open-sourced in 2014 and later handed to the Cloud Native Computing Foundation. Dremel, for querying enormous datasets quickly, is the ancestor of BigQuery.

That's why the strengths cluster where they do. A requirement that rhymes with something Google solved for itself lands on well-worn ground. A small business website doesn't.

Three places it gets chosen on merit

Set aside the companies that land here because they already pay Google for email. Three real reasons come up.

Data and analytics. BigQuery is a warehouse you load data into and ask ordinary SQL questions of, with no cluster to size and nothing idle between questions. You pay for what's stored and for the work each query does, so an analyst can start without a platform team behind them.

Machine learning. Google designs its own chips for this work and rents them out, and it sells access to its own models alongside open ones through Vertex AI. If the centre of gravity of the project is a model rather than an application, that's a reason rather than a preference.

Kubernetes. It came out of Google and it's the standard way to run containerised software across many machines. Every large cloud runs it well now, so that edge has narrowed, and it stays a big thing to operate. Cloud Run runs the same container without any of it.

Metered pricing, and where the surprise lives

Everything is counted. A machine bills by the second once it's on, storage bills for what's kept, and the line that catches people out is data leaving Google's network for the internet, charged by the gigabyte while data arriving isn't. Video has a different cost shape from forms.

Some discounts arrive without a negotiation. On some machine types, running an instance most of the month lowers the rate automatically, and committing for a year or three lowers it further. Published rates change, so price your design with Google's free calculator rather than a number in an article, this one included.

The comparison worth drawing isn't Google against another cloud. It's metered computing against a flat monthly platform, because the two fail in opposite directions.

Metered cloud

Flat monthly platform

A quiet month

Metered cloud: You pay for what ran, and a machine left switched on bills all month regardless.

Flat monthly platform: The whole fee, whether or not anybody visited.

A sudden spike

Metered cloud: It absorbs the traffic, and the invoice explains it afterwards.

Flat monthly platform: It holds to the plan's ceiling, then it's an upgrade or a queue.

Patching the server

Metered cloud: Yours, unless you picked a managed service that does it for you.

Flat monthly platform: Included, along with the limits that come attached to it.

Putting a number in a budget

Metered cloud: An estimate resting on traffic you haven't had yet.

Flat monthly platform: A figure you can commit to, until growth moves you to the next plan up.

Where the surprise lives

Metered cloud: Data leaving the network, and things nobody switched off.

Flat monthly platform: The ceiling, met on the day it matters most.

Metered cloud pricing against a flat monthly platform, on five things that decide which one hurts less. Every row states what both sides cost you.

Where it stops

It's the wrong shelf for a website. A marketing site with a few forms behind it can run here, and it will cost more attention than it returns. Managed hosting gets it live sooner with nothing to operate.

The hiring pool is smaller, which is the practical edge of that ordering. Plenty of firms know Google Cloud well, and in most markets more people know AWS. You feel that when you want three quotes for one job.

The worry about Google retiring things is half fair. The consumer products it has closed aren't the cloud business, and Google publishes a deprecation policy covering a named set of cloud services with long notice before they change. The narrower question: is anything in your design still labelled preview, because preview carries no such promise on any cloud.

The lock-in is architectural, not contractual. Google said in 2024 it would stop charging for the data transfer involved in leaving, and the other large clouds announced much the same. What doesn't move is the design. It needn't be all or nothing, though: companies use BigQuery on its own while the application runs elsewhere.

Who has to be reachable when it breaks

This decides more of these builds than anything technical, and it isn't Google's part of the problem.

A cloud account is a live system with permissions, budgets, alerts and updates attached. Somebody has to hold the top of that tree, notice the morning something costs four times what it did, and be reachable when a service has a bad day. Managed services shrink that job, never to zero.

For most businesses it isn't a hire. It's one named person and an arrangement, agreed before launch rather than discovered after it.

Worth knowing before you start

  • Ask which organisation your projects will live in and whose billing account is attached. A project inside a build partner's organisation is theirs to administer, and moving it out later is a scheduled job.

  • Set a budget with alerts before launch, not after the first surprising invoice. Budgets in Google Cloud notify on spend, they don't cap it, so the alert lands after the money is gone. Smoke alarm, not fuse.

  • Ask whether anything in the design is still labelled preview. Preview is where the newest features live, and where they change or disappear on different rules.

  • Ask which region the data sits in and check every service in the design exists there. Google runs Canadian regions in Montreal and Toronto, and not every service reaches every region.

Common questions

No, and the mix-up is common. Workspace is Gmail, Docs, Drive and Meet, sold per person. Google Cloud is infrastructure, sold by use. Same company, same login, almost nothing else in common.

Not reliably. Rates for comparable machines sit close and the discount schemes differ, so what sets your bill is the design: how much data leaves the network, and how much keeps running when nobody's using it.

No. It's one way to run containers across many machines, and a substantial thing to operate. Cloud Run runs the same container with none of that, and set to scale to zero it stops charging while nobody uses it.

Same family, same billing account, different toolkit. It's aimed at getting a mobile or web app's backend working quickly. Its database works in its own way, which doesn't translate to an ordinary SQL one.

The data moves and the design doesn't. After an export, what remains is rebuilding whatever leaned on a service only Google sells. Equally true of the other two.

Related

Want to talk through your situation?

A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.