Which Google Cloud services does your organisation actually need?

Google offers hundreds of Google Cloud services. A data platform runs on roughly six of them. The difficulty is therefore not finding services, but deciding which ones earn a place and how they hand work to each other.

What matters is the jobs a platform has to do, the services that do those jobs, and the way they connect.

Why is the service catalogue the wrong place to start?

Google’s service catalogue tells you what cloud services exist. It does not tell you what you need. Teams that start there end up with a list of services that are switched on and nobody owns.

The pattern is familiar. A platform grows by addition. Every addition brings cost, configuration and something extra to secure, and nothing is ever switched off again.

For completeness: Google Cloud is Google's set of services for storing, processing and analysing data, paid for on the basis of use.

The four jobs a data platform has to do

Google groups its products into eight categories. From your side of the table there are four jobs.

• Getting data in: Pulling data out of source systems, either as a stream or as a scheduled load.
• Keeping data in one place: One store that every report and model works from.
• Preparing data so it is trusted: Cleaning, modelling and documenting, so numbers hold up in a management meeting.
• Putting data to use: Reports, forecasts, models or data pushed back into other systems.

Governance is not a fifth job. Access, ownership and quality are decided inside each of the four, because deciding them at the end means unpicking work that is already done.

The number of services you need follows from how many of these jobs you actually do today. An organisation that reports on its data needs considerably less than one that activates it in campaigns or customer journeys.

Which services do those jobs?

Data rarely arrives on its own. For events that need to be available immediately, Pub/Sub receives the messages and passes them on. Dataflow does the moving and reshaping, both for those streams and for batches that run overnight. In retail we see what those streaming pipelines prevent, from ghost inventory to prices that lag behind the shelf.

Raw files need somewhere to land before anyone touches them, which is what Cloud Storage is for. From there the data is loaded into BigQuery, where it is stored and where the analysis happens.

Once several teams work from the same store, the question becomes who owns which dataset and whether a field means what people assume. Dataplex holds that catalogue, the ownership and the quality rules.

At the far end, Looker turns the modelled data into reports and holds the definitions behind them, so revenue means the same thing in every dashboard. Vertex AI is where models are trained and where generative AI is applied, for example to forecast customer value or the chance of a purchase.

Not every AI question needs a model of your own. Applying an existing Google model to a concrete task, such as reading invoices, delivers a result in weeks and needs no model work at all.

How the services work together in one flow

End to end, the chain runs like this. Source systems deliver either through Pub/Sub for events or through a scheduled batch load. Dataflow moves and transforms, with Cloud Storage as the landing area for raw files. Everything arrives in BigQuery.

From BigQuery the data leaves through Looker for reporting or through Vertex AI for models, and the access rules apply across the whole chain rather than at one point in it. Our work with Sijthoff Media for example shows BigQuery and Looker running as one chain in practice.

A list of services never tells you where this breaks. Three failures account for most of it:

• A schema change in a source system that nobody flagged, which stops a load or silently changes a number.
• A transformation layer with no clear owner, so nobody dares to change a rule that everyone depends on.
• A semantic model in Looker that drifts away from the definitions the business uses, after which two dashboards disagree.

Three starting points, and what each one needs

Most organisations start from one of three positions. The order matters: the reporting route is a prerequisite for the other two, because a forecast or a real-time flow built on unreliable data produces unreliable output faster.

Where do the costs actually come from?

The bill grows less from the number of services than from the way they are configured. BigQuery is charged for storage and for queries separately, which are two different levers: storing a large history is cheap, scanning it repeatedly is not. Our article on BigQuery pricing works through both.

Fewer, well configured services beat a longer list. Teams that run a usage review almost always find services that were switched on for a pilot and left running afterwards.

The foundation and access rules that come first

Two services come before the rest. The tool IAM controls who reaches which datasets and which services, down to the level of a single table. The Security Command Center gives one view of vulnerabilities and misconfigurations across the environment, instead of a check per project.

Both services are set up inside the landing zone: the projects, the network rules and the access policies, with cost controls set at the same time. These are decided before the first service goes live, because retrofitting them later means rebuilding what is already in production.

How do we put this together?

As a Google Cloud Premier Partner, Crystalloids assembles the services you choose into one governed data platform and keeps it running as a managed service. That status rests on audited specialisations and expertises in data and analytics, awarded by Google on the basis of delivered projects.

A useful exercise before any of this is this: write down the three business goals for the coming year and note next to each one which services contribute to it. Any service that ends up next to none of the three goals is one to leave switched off. Send us those three goals and you get back a shortlist of the services your platform needs first, and the ones you are paying for now without a goal behind them.