The Paved Road: Building an Internal Developer Platform on Google Cloud
For years, the promise of DevOps was that developers would own their software from commit to production. In practice, many teams landed somewhere else: engineers who wanted to launch a service still filed tickets for a cluster, a database, a certificate, a network rule and a set of credentials, then waited days or weeks for each one. Every team reinvented its own pipelines, and the cognitive load moved onto developers rather than away from them.
Platform engineering is the response to that friction. Instead of expecting every engineer to become an infrastructure expert, a small platform team builds and operates an internal developer platform (IDP): a curated, opinionated layer of self-service capabilities the rest of the organisation consumes. The guiding metaphor is the paved road. You’re free to go off-road when you have a genuine reason, but the paved road is fast, well-lit and safe, so most teams choose it most of the time. That choice, made willingly and repeatedly, is what turns scattered best practices into consistent outcomes.
What a paved road actually looks like
An internal developer platform isn’t a single product you install. It’s a set of capabilities that work together to remove decisions and delays from the everyday path to production.
Golden-path templates. A developer starting a new service selects a template and gets a working, opinionated starting point: a service scaffold, a pipeline, health checks, logging and sensible defaults already wired in. The blank page disappears, and so do dozens of small, inconsistent decisions.
Self-service, not ticket-service. Provisioning an environment, a database or a message queue happens through a portal or a command, governed by policy rather than by a human approver in the loop. The platform encodes what’s allowed, so approval is built in.
One identity through single sign-on. Developers authenticate once, and that identity flows through the tools, environments and cloud resources they’re entitled to. Access is tied to roles and groups, which makes both onboarding and offboarding fast and auditable.
Declarative desired state, reconciled automatically. Teams describe the state they want in version-controlled configuration, and the platform continuously reconciles the running system toward that state. The desired state is the source of truth, changes are reviewed like any other change, and drift is corrected without manual intervention.
Quality gates. Automated checks for tests, code quality, vulnerabilities and policy compliance run on every change. Progression to production is earned by passing gates, not by informal sign-off.
Zero-code observability. Logs, metrics and traces are collected by default, so a new service is observable the moment it runs, with no manual instrumentation required first.
Security by default. Least-privilege access, managed secrets, encrypted data and hardened baselines are part of the template, not an afterthought bolted on before launch. Doing the secure thing is also the easy thing.
The point of these capabilities isn’t control for its own sake. It’s to let a developer go from an idea to a running, observable, secure service in production without stopping to file a request or make a decision someone else has already made well.
The developer experience, from idea to production
Consider the difference in practice. Without a platform, launching a new service means requesting compute, negotiating network access, standing up a database, wiring credentials, building a pipeline and adding monitoring — each step often owned by a different team. With an internal developer platform, the same developer chooses a golden-path template, commits code, and the platform takes over: it builds and tests the artifact, runs it through quality and security gates, provisions the declared dependencies, deploys to the target environment, and turns on observability. The developer reviews a merge request and watches the change flow to production.
The experience is fast because the slow parts are automated, and safe because the guardrails are always on. Crucially, it’s self-service without being a free-for-all. The platform team decides what good looks like once, encodes it into templates and policy, and every team inherits it. When standards change, they change in one place and propagate outward. This is how platform engineering delivers speed and governance at once, rather than trading one for the other.
How Wohlig builds internal developer platforms on Google Cloud
Wohlig maps each capability to a managed Google Cloud service, so the platform team spends its time on developer experience rather than on undifferentiated operations.
Managed Kubernetes provides the runtime for containerised workloads, with autoscaling, hardened defaults and a consistent target for every golden-path template.
Managed databases and managed secrets give teams production-grade data stores and a secure home for credentials, provisioned declaratively and accessed through identity rather than through shared passwords.
CI/CD turns every change into a repeatable, gated journey from commit to deploy, so releases are routine rather than events.
GitOps-style continuous delivery treats version-controlled declarative desired state as the single source of truth. The platform continuously reconciles the live environment toward that state, which makes deployments reviewable, repeatable and easy to roll back.
Single sign-on and least-privilege access unify identity across the platform, and built-in observability makes every workload measurable from its first deployment.
We start by understanding how your teams work today, where the friction and the ticket queues live, and what your compliance and security requirements demand. From there we design the golden paths, encode your standards into templates and policy, and build the platform incrementally — proving value on a first set of services before scaling across the organisation. The result is a paved road that reflects your context rather than a generic blueprint.
If your engineers are still waiting on infrastructure tickets, and your leaders are still choosing between speed and governance, an internal developer platform can give you both. Talk to Wohlig about designing and building a paved road that helps your teams ship faster and more safely on Google Cloud.