Google Cloud engineering
Google Cloud conversations usually start with data rather than servers. Event data that outgrew the product database. An unpredicted bill from BigQuery, Google's warehouse. A model that has to run beside data which is not allowed to leave your project.
01Capabilities
Four reasons to be here rather than somewhere else
We reach for Google Cloud when the reason to be in a cloud is the data or the model rather than the servers. The work runs as cloud migration and cloud infrastructure engineering. Four shapes account for most of it, and the decision table below matters more than any of them.
- Analytics
Warehouses where a query answers a question
Event and transaction data landed, partitioned and modelled so a query reads what it needs instead of scanning years of history. Shipment and telematics events in logistics, order and clickstream data in e-commerce. The pipelines feeding it are data engineering work.
- Models
Training and serving beside the data
Training, endpoints and evaluation inside your own project, so the data a model reaches never crosses a boundary your security review has not already approved. Which model to pick is a separate question, covered on Gemini. This is where it runs and what it is allowed to see.
- Containers
Managed clusters, and whether you want one
Google's Kubernetes heritage is real rather than marketing: the project came out of Google and its managed service was the first, with node management now removable entirely. Whether you should be on a cluster at all is the argument on Kubernetes, and the answer is often a serverless container runtime instead.
- Moves
Migrations in, and the cost of ever leaving
Moving workloads onto Google Cloud, or moving only the data platform while the rest of the estate stays put. The hard parts are the usual ones: the data cutover, the rollback path, and the transfer cost that becomes visible on the day you leave. Delivered under an ISO 27001:2022 certified information-security management system.
02Fit
Where the provider comparison stops mattering
Two structural advantages survive any pricing change: a warehouse that separates storage from compute with no cluster to size, and Kubernetes, which Google originated. Outside those two the honest answer is frequently a different provider, and by month three most teams find the daily work is governed by their own layout decisions rather than by the logo. We hold no reseller incentive in any direction.
| Your situation | What we recommend |
|---|---|
| Event volumes, a team fluent in SQL, and query load that is spiky and hard to predict | Use Google CloudBigQuery is the strongest reason to be here. Nothing to provision, and cost tracks the bytes a query reads, which is a design variable you control. |
| A Microsoft estate: .NET services, Active Directory, SQL Server, an agreement already signed | Different pageOur Azure page. Identity integration and licensing decide the total cost here, and no warehouse argument outweighs them. |
| A wide spread of workloads, unusual service requirements, a team already fluent in one cloud | Usually AWSOur AWS page. Breadth of managed services is a genuine advantage, and retraining a team is a cost people forget to count. |
| You want the warehouse, and nothing else about the estate is actually broken | Do not move it allRun the data platform here alongside what you have, and price the cross-cloud transfer before committing. A deliberate split is an architecture, not indecision. |
| The managed Kubernetes service is the whole reason this provider is on the list | Ask the prior questionWhether you need a cluster at all comes first, and it is the argument on Kubernetes. Plenty of these platforms are two services and a scheduler. |
| Choosing a warehouse, with BigQuery up against Snowflake | Compare on portabilitySee Snowflake. If you intend to stay multi-cloud its independence is worth paying for; if you are already here, BigQuery usually wins the total bill. |
Scope
What we own here is the cost profile and the boundaries. Table layout first, because the bytes a query reads is a billing decision wearing a schema costume. Then the project and access layout. Whether the data a model can reach matches what your security review approved. The transfer cost of ever leaving. Whether your team can operate the result after we hand over. We work under an ISO 27001:2022 certified information-security management system. unicrew has been building cloud platforms since 2012, with 100+ senior in-house engineers across six countries. Where the honest recommendation is another provider, you get that instead of a migration plan.
A cloud feature comparison stops mattering in about month three, and you operate the thing for a decade. What matters after that is whether your team can debug it at midnight, whether your identity model survives contact with the second product you build, and whether anyone can tell you what a service costs. Those three questions have almost nothing to do with which provider you picked.
Oleksandr TrofimovChief Technology Officer, unicrew03Delivery
Data decisions before server decisions
The sequence differs from a generic cloud migration, because here the reason to be on the platform is usually the data, and the data decisions are the expensive ones to change later.
- Start from the questions the data has to answerWhich decisions depend on which numbers, and where that data lands today. Loading everything into the warehouse first and modelling it later leaves you with a full history and an unresolved argument about definitions.
- Lay out projects, access and billing before anything runsThe project boundary is the useful unit of both isolation and cost attribution here, and retrofitting it across running workloads is thankless. Folders, one project per environment, and labels that make the bill readable to someone who was not there.
- Partition, then set a cost targetOn-demand pricing charges for the bytes a query reads, so an unpartitioned table is a cost defect rather than a performance one. We set a target per workload and alert on it, then check whether reserved capacity beats on-demand at your real query pattern.
- Move one workload at a time, prove it, then tuneA rehearsed rollback for each move, parity verified against real traffic, and optimisation only afterwards. Tuning during a migration makes it impossible to say which change caused a regression. Each move goes through the same QA and test automation practice we use on our own builds.
04Stack
The providers and pieces around it
The alternatives this is weighed against, and what runs on top. Each has its own page if that is the decision you are actually making.
05Questions
Asked while a provider is still undecided
Answered the way we would answer them live. Ask yours on the call and the answer will be specific to your estate.
Yes, and on platform work it is often sensible because your people hold the operational context. What we will not do is supply engineers and leave the architecture and the bill unowned, which here is a real risk: the expensive mistakes are table and access decisions that look free on the day they are made. An architect outside the delivery team reviews the design. Capacity is managed teams; an outcome is cloud migration.
Both are good warehouses and the choice is rarely about SQL features. Already on Google Cloud, BigQuery usually wins the total bill: no second vendor, no cross-cloud transfer, one identity model. Expecting to stay multi-cloud, Snowflake independence is worth paying for. The difference that changes daily engineering is the meter. BigQuery charges for bytes read, so cost lands on whoever designed the table.
Storage is cheap. Queries are cheap only if the tables were designed. On-demand pricing charges for the bytes a query reads, so selecting every column across an unpartitioned table holding years of events is the classic surprise invoice. The second is a dashboard refreshing every five minutes for nobody. Partitioning, clustering and reading fewer columns are the levers, and we set a measurable target before changing anything.
Often just the data platform, and we will say so. If the warehouse or the model tooling is the reason you are looking, that is a data decision and the applications do not have to move with it. Two costs decide the shape: cross-cloud transfer, which grows with volume, and running two identity models, which is an ongoing tax rather than a one-off line item.
A scoping call with an engineer rather than a salesperson. For an existing estate we ask for read access to the project and the billing export first, because an hour inside the query and cost breakdown is worth several in discussion. You get back a written read on what belongs here, what does not, and what we would do first. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work where the scope is still moving. Fixed price is outcome based and quoted per project, offered once the first read is done, because a fixed number on an estate nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Weighing up a provider you may only half need?
Send the workloads, the data volumes and what your team already runs. You get an engineer's read on whether the warehouse or the cluster service is a real reason to be here, and where another provider would serve you better.