Client
LiveRamp
Industry
Data collaboration, marketing technology
Technologies
Google Cloud
Shared VPC
VPC peering
VPN
GKE
IAM

LiveRamp is a data collaboration company. Its platform lets brands, publishers and their partners connect and use customer data for marketing and measurement, which puts data security and access control at the centre of everything it runs.
When a company like this adopts a new cloud, the first decisions about networks, projects and permissions are the ones that are hardest to undo. Getting the foundation right before the first production workload arrives is cheaper than restructuring around it later.
Project
LiveRamp was adopting Google Cloud for the first time and had clear requirements for the foundation: accessible to engineering teams spread across geographies, able to scale, secure by default, and manageable by a central platform group.
SEYA's engagement was that foundation. We reviewed LiveRamp's existing architecture and cloud plans, proposed a target design aligned with Google Cloud practices, then built the shared networking, GKE layout, organization structure and IAM model that followed, along with an operational observability platform.
Deliverables:
A target Google Cloud architecture, based on a review of LiveRamp's existing design and its constraints
GCP networking: a common-services VPC, transit VPCs, production and non-production host VPCs, VPN connectivity and VPC peering
GKE clusters with control planes separated from worker nodes inside a shared VPC
A Google Cloud organization structure with split production and non-production environments
Granular IAM for geographically dispersed teams, including custom roles for Google-managed services and application stacks
An operational observability platform on Google Cloud
The Challenge
A first cloud foundation is a one-time chance to decide how networks are segmented, how environments are separated, and who can do what. Teams that skip this step end up with projects created ad hoc, flat networks, and IAM bindings nobody can explain, and the cost of fixing that grows with every workload deployed on top.
LiveRamp had engineering teams in several geographies who all needed access to the new platform, and workloads that would run on Kubernetes from the start. The foundation had to meet four requirements at once: accessibility for those teams, scalability for the workloads, security appropriate to customer data, and manageability for the group that would operate it.
Our Expertise
SEYA reviewed the existing architecture with LiveRamp's team and identified where that design would constrain the move to Google Cloud. From there we proposed a target architecture aligned with Google Cloud's recommended practices for organizations, networking and identity.
The design was agreed with LiveRamp before the build, so the networking, GKE and IAM work that followed implemented a plan the client's architects had already reviewed.
Our Solution
SEYA implemented a networking design built around a common-services VPC for centrally run services, transit VPCs for routing between environments, and separate production and non-production host VPCs. VPN provides connectivity into the estate and VPC peering links the networks that need to talk to each other.
GKE control planes were separated from worker nodes within a shared VPC, so cluster management traffic and application traffic are isolated and the platform team controls the network each cluster lands in.
SEYA defined the Google Cloud organization structure with split environments, and an IAM model granular enough for teams in different geographies to work independently without broad permissions. Custom roles were created for Google-managed services and for LiveRamp's application stacks, so access follows the job rather than a default role. An operational observability platform on Google Cloud completed the foundation.
Value Delivered
For a CTO or platform lead, the value of a foundation like this is in the questions it answers permanently. Shared services have one home. Production and non-production are different places with different permissions. Any new project inherits the network and identity model instead of inventing one.
Separating GKE control planes from worker nodes in a shared VPC gives the platform group control over where clusters attach and how their traffic flows, while application teams keep ownership of what runs inside them.
Granular IAM with custom roles means an engineer in one region can be given exactly the access their role needs on a Google-managed service or an application stack, and that grant can be reviewed and revoked without affecting anyone else.
The Result
LiveRamp has finer control of its cross-project Google Cloud infrastructure, with shared services centralized in one VPC and production kept separate from non-production at the organization, network and IAM level.
Geographically dispersed teams work on the platform under role-specific permissions, and an operational observability platform gives the group running the foundation a view of what is happening across it.
Illustrative: production and non-production have their own host VPCs, and in each the GKE control plane sits apart from the worker nodes; the common-services VPC is shared by both.
Illustrative: environment separation and access control are set at the organization level, so new projects inherit them rather than defining their own.
Illustrative: the target design is agreed before anything is built, and operation (shared services, control, observability) is planned as part of the foundation.
Starting on Google Cloud, or about to add your second region or team?
SEYA can review your current architecture and design a landing zone your platform team can grow into. Contact us at hello@seyagroup.io.
Contact us
Send an enquiry about a cloud, platform, data, or reliability engagement. Marketing email is a separate choice on the form.