Platform Engineering & Internal Developer Platforms on GCP

I help engineering teams design and build internal platforms that standardize how applications are built, deployed, and operated on Google Cloud. The goal is to reduce platform friction for developers — so they spend their time building product rather than navigating infrastructure — while improving security, reliability, and consistency across every team and environment. I’m Amit Malhotra, a Principal GCP Architect based in Toronto with 20+ years in IT and 6+ years hands-on with GKE, Terraform, and DevSecOps. I’ve built internal developer platforms for enterprises and SaaS teams across Canada and the USA, and I work directly with your engineering team — no account layer, no hand-offs.

Platform engineering on GCP is one of the highest-leverage investments a growing engineering organisation can make — and one of the easiest to get wrong. Every engagement I run is guided by the SCALE Framework, which ensures the platform we build has Security by Design, Automation with Terraform, and Elastic Scalability built into the foundation — not retrofitted later.

What Platform Engineering Means in Practice

What Platform Engineering Means in Practice

Most engineering teams reach an inflection point where the way they’ve been working stops scaling. I’m typically brought in when:

Every squad deploys differently — inconsistent pipelines, different Terraform patterns, different GCP project structures, and no shared understanding of how the platform works
CI/CD pipelines are fragile and team-specific — each team maintaining their own GitHub Actions workflows with no shared libraries, no security gates, and inconsistent deployment behaviour across environments
Infrastructure is manual or copy-pasted between projects — GCP resources provisioned by hand or cloned from previous projects, with configuration drift accumulating silently until something breaks in production
Security controls are bolted on late — IAM permissions granted broadly because they were needed quickly, secrets stored in environment variables, and compliance requirements treated as a pre-audit scramble rather than a platform property
Developers spend more time fighting the platform than building product — waiting for environment provisioning, debugging infrastructure differences between environments, and escalating to a single platform expert who becomes a bottleneck

Platform engineering exists to solve exactly this — and a well-designed Internal Developer Platform on GCP eliminates these problems structurally rather than through process and discipline.

What I Typically Work On

The Platform Engineering Work I Do

GKE and Cloud Run Platform Design: I design the container platform that your engineering teams deploy to — GKE cluster architecture, node pool strategy, namespace isolation per team, shared ingress and DNS, and Cloud Run for stateless workloads that don’t need Kubernetes. The platform is designed so teams can deploy without understanding the underlying infrastructure.
Standardized CI/CD with GitHub Actions or Cloud Build: I design and implement shared CI/CD pipeline libraries — reusable GitHub Actions workflows or Cloud Build pipelines that give every team a consistent, secure deployment process without each team building their own. Build once, deploy many, with environment-specific approvals and zero long-lived credentials.
Terraform Platform Foundation: I build the Terraform module library and workspace structure that underpins the entire platform — standardized modules for GKE clusters, Cloud Run services, IAM bindings, networking, and shared services, so teams can provision new environments and services through a single consistent IaC pattern.
Golden Paths for Application Teams: I define and document the opinionated deployment patterns — the ‘golden paths’ — that make the right way to deploy also the easiest way. Application teams follow the path, the platform handles security, observability, and scaling automatically, and deviations require explicit justification rather than being the default.
Multi-Tenant Cluster Design: I design multi-tenant GKE architectures — shared clusters with per-team namespace isolation, or separate clusters for platform vs. application workloads depending on security and operational requirements — with centralised identity through Workload Identity Federation and network policies enforcing tenant boundaries.
Shared Platform Services: I design and implement the shared services layer — centralised ingress with Cloud Load Balancing, DNS management, Secret Manager integration, shared observability stack, and centralised audit logging — so every team gets these capabilities without building them independently.

Internal Developer Platforms (IDP)

What a Well-Designed IDP on GCP Looks Like

An Internal Developer Platform isn’t a product you buy — it’s the set of platform capabilities, automation, and standards that let your engineering teams self-serve everything they need to build, deploy, and operate software. A well-designed IDP on GCP typically includes:

A standardized runtime — GKE for containerized workloads and Cloud Run for stateless services, with deployment patterns and resource limits defined by the platform rather than each team
A consistent deployment model — shared CI/CD pipelines with security scanning, image signing, environment-specific promotion gates, and zero-touch production deployments for compliant changes
Predefined Terraform modules — a library of approved, tested GCP infrastructure modules that teams use to provision resources without writing Terraform from scratch or deviating from the organisation’s patterns
Security guardrails by default — Policy-as-Code enforcement, Workload Identity Federation replacing static credentials, and least-privilege IAM built into every module
Self-service environment provisioning — developers can spin up isolated environments on demand through the platform, without raising infrastructure tickets or waiting for a platform engineer
Platform documentation and runbooks — every golden path documented so teams can follow it independently, with clear guidance on when to deviate and how to request platform changes. Linked to the SRE / Observability service for the operational layer.

The outcome: developers focus on product. The platform handles the rest.

Platform Architecture Patterns

The GCP Platform Patterns I Design Around

The platforms I design typically follow one or more of these proven GCP architecture patterns — chosen based on your team size, security requirements, and operational maturity:

Shared GKE Cluster with Per-Team Namespaces: A single GKE regional cluster with namespace-per-team isolation, network policies enforcing inter-namespace boundaries, resource quotas per namespace, and Workload Identity per service account. Cost-efficient for smaller organisations with strong security requirements.
Separate Platform and Application Clusters: Dedicated GKE clusters for platform services (ingress, observability, secrets) and application workloads — providing strong blast-radius isolation, independent upgrade cycles, and clear separation between platform engineering and application team concerns.
GitOps-Style Deployment Workflows: Declarative, Git-driven deployments using tools like ArgoCD or Flux — all environment state stored in Git, changes deployed automatically when merged, and rollback as simple as reverting a commit. The platform enforces that nothing reaches production without going through Git.
Centralised Identity with Workload Identity Federation: No static service account keys anywhere in the platform — every workload authenticates to GCP APIs through Workload Identity Federation, with short-lived tokens scoped to the minimum required permissions. Eliminates the credential management overhead that scales linearly with team size.
Environment Isolation with Separate GCP Projects: Dev, Staging, and Production environments in separate GCP projects within a shared VPC or hub-and-spoke network — providing billing isolation, IAM boundary, and blast-radius containment, while the Terraform module library ensures consistent provisioning across all environments.
Policy-as-Code for Security and Compliance: Organisation-level GCP constraints and OPA/Gatekeeper admission controllers enforcing security baselines automatically — so no workload can be deployed without meeting the platform’s security requirements, regardless of which team deployed it.

CI/CD & Automation

Automation Is the Platform — Not an Afterthought

A significant part of platform engineering is CI/CD design and implementation. The DevSecOps pipelines I build for platform engineering clients typically include:

Shared Pipeline Libraries: Reusable GitHub Actions workflows or Cloud Build configs — maintained by the platform team, consumed by application teams — so every team gets a secure, tested deployment process without building their own pipeline infrastructure
Build Once, Deploy Many: Container images built and signed once in CI, promoted through environments using image digest references rather than rebuilt per environment — ensuring what was tested in Staging is exactly what runs in Production
Artifact Reuse and Image Signing: Artifact Registry as the centralised image store, with Binary Authorization policy enforcement ensuring only signed, approved images can be deployed to GKE — eliminating the risk of unreviewed images reaching production
Environment-Specific Promotion Gates: Automated promotion from Dev to Staging to Production with required approval gates, automated test execution, and deployment validation — so production deployments require explicit sign-off but don’t require manual steps
Secure Secret Handling: Secret Manager integration in every pipeline — no secrets in environment variables, no credentials in CI configuration, and automated secret rotation so long-lived credentials stop being a risk vector
No Long-Lived Service Account Keys: Workload Identity Federation for all GCP API calls from CI/CD — GitHub Actions, Cloud Build, and GitLab CI all authenticate to GCP through short-lived federated tokens, eliminating the key management problem entirely

Who This Is For

Is Platform Engineering the Right Investment Right Now?

Platform engineering delivers the highest return when the organisation has reached a scale where inconsistency and manual processes are genuinely slowing engineering teams down. This is typically a good fit when:

Your engineering org is scaling beyond a single product team — multiple squads deploying to the same GCP environment with no shared standards or platform foundation
You have multiple engineering squads and each is maintaining their own infrastructure — Terraform, CI/CD, and GCP project configurations that are all slightly different and nobody fully understands
You’re adopting Kubernetes and GKE seriously — not just running one service, but planning to migrate multiple workloads and needing an operational platform model that scales with that commitment
You’re building a product that will be deployed by or for other teams — an internal platform, a multi-tenant SaaS product, or a regulated environment where consistency and auditability are non-negotiable
Your senior engineers are spending time on infrastructure instead of product — the classic signal that platform investment will pay for itself quickly. See the Enterprise Platform Modernization page for more context.

Platform engineering is not the right investment if you have a single small application, no CI/CD in place yet, or are at a stage where the priority is shipping a first version rather than scaling an existing one. In those cases, the

GCP Architecture & Modernization service is a better starting point.

LET’S TALK

Ready to Build an Internal Developer Platform Your Engineering Teams Will Actually Use?

Platform engineering done well is invisible to developers — everything they need is available, automated, and secure, and they never have to think about the infrastructure underneath. I start every platform engineering engagement with a free 30-minute conversation about your current setup, your team structure, and what the platform needs to enable. Amit Malhotra, Principal GCP Architect — based in Toronto, working with engineering teams across Canada and the USA.

Let’s Talk

Speak Directly With Amit Malhotra

Email

amit@buoyantcloudtech.com

Operating From

Based in Toronto (EST), working with engineering teams across Canada & USA

Ready to Architect Your Future on Google Cloud?

Speak directly with me — a Principal Cloud Architect — about your GCP architecture, security, platform engineering, or MLOps goals. I typically respond within one business day.

Get In Touch

Trusted Technical Advisor

Amit works as a true architecture partner, not just a consultant. He focuses on making the right decisions early and designing systems that remain maintainable as they scale. His guidance helped us avoid costly redesigns and establish a solid cloud foundation from the start.

Architecture leadership

Amit helped us redesign our Google Cloud architecture to support rapid growth without increasing operational complexity. His ability to simplify difficult architectural decisions and design scalable platform foundations had an immediate impact on our engineering velocity and system reliability.

Platform engineering & DevSecOps

We engaged Amit to build a secure and scalable platform on Google Cloud with Terraform, Cloud Run, Kong API gateway and automated CI/CD. He brought deep hands-on expertise and designed everything with long-term operability in mind. Our deployment process is now significantly more reliable and secure.