Onboarding a New Service onto a Multi-Cloud Platform

From an idea to production without lowering a 99.999% SLA

Design the platform and process that take one new microservice from a request to production on AWS, Azure and Google Cloud without lowering a 99.999% SLA: golden paths, tiers, dependency rules, readiness review and canaries.

Overview

A company runs dozens of microservices across AWS, Azure and Google Cloud, and promises 99.999% availability on its critical user journeys. That is about 26 seconds of failure a month. A team now wants to launch one more service. The interview question is not 'how do you deploy a container?' but 'how does the company let 40 teams a year do this safely, without a ticket queue, and without one new service quietly eating the whole error budget?'

The answer is a platform and a process. The platform is an internal developer platform: a portal and an API where a team asks for a new service and gets, a few hours later, a repository, a pipeline, cloud accounts inside a governed landing zone, a network that does not overlap anyone else's, a namespace in each cluster, an identity, secrets, DNS names, certificates, dashboards, alerts and cost tags, all created the same way from code.

The CNCF platforms white paper calls a template plus its documentation a golden path. The process is the set of gates the service passes on its way to real traffic: a criticality tier chosen at intake, an SLO and a dependency review, a production readiness review (PRR) with evidence, and a progressive launch that rolls itself back when the SLO starts to burn.

The tier is the hinge.

It decides how many clouds and regions the service runs in, its recovery targets, who carries the pager, how deep the review goes, and which services may call it synchronously. A tier-1 service on the checkout path gets the full treatment; an internal reporting tool gets a lighter path that still uses the same templates.

Scope it first

What does 99.999% apply to? — The critical user journeys (checkout, sign-in), measured end to end, not every service
How many clouds and regions does a critical service run in? — Tier 1: production in 2 clouds, 2 regions each; tier 2: one cloud, 2 regions; tier 3: one region
Who builds the platform, and who owns the service? — A platform team builds the golden path; the requesting team owns the service and its pager from day one
Is the service on the critical path? — Our example, a gift-card service, is called by checkout, so yes unless we design it out
How fast should onboarding be? — Request to a first staging deploy in one working day; to production when the review passes
What is already there? — Landing zones on all three clouds, shared clusters per region, a central observability stack

The interviewer listens for four things. Do you treat onboarding as a product with a self-service path rather than a checklist of tickets? Do you classify the service before you build it, and let the tier drive the deployment shape and the review? Can you show, with numbers, how one synchronous dependency lowers a five-nines journey? And do you gate production traffic on evidence (a failover test, a restored backup, a rollback that works), then launch progressively with automatic rollback?

Key concepts

Internal developer platform
Golden path
Software templates
Account and subscription vending
Landing zone
IP address management
Workload identity
Policy as code
Criticality tiers
Error budget
Production readiness review
Progressive delivery

Functional requirements

A team requests a new service through a portal or API with its name, owner, tier, data classification, dependencies and target clouds
The platform creates the repository from a template, the CI/CD pipeline, cloud accounts or subscriptions or projects, networks, namespaces, identities, secrets, DNS records, certificates, dashboards, alerts, budgets and cost tags
Every created resource passes the organization's policies, and a request that breaks one is refused with a reason
The service is registered in the catalog with its owner, lifecycle, tier, SLOs and dependencies
A readiness view shows every production readiness check, its status and its evidence; production traffic is blocked until the review is approved
Releases go out as canaries per region and cloud, and roll back automatically when the SLO burns
The owning team can hand the service to another team or deprecate it, and the platform cleans up what it created

Non-functional requirements

Safe: onboarding a service must never lower the availability of an existing tier-1 journey below 99.999% (our target)
Fast: request to a first staging deploy within one working day; no step waits on a human except the approvals the tier requires
Repeatable: every resource comes from versioned code, so two services of the same tier look the same on every cloud
Idempotent and resumable: a provisioning run that fails halfway can be run again and finishes without duplicates
Auditable: every request, approval, policy decision and exception is recorded with who and when
Isolated: one service's accounts, network, identity and quota cannot reach or exhaust another's

Interview questions

Walk me through what happens from the moment a team asks for a new service until it serves production traffic.
How do you stop a new service from lowering the 99.999% SLA?
What is a golden path, and what should one create?
Why one account, subscription or project per environment, and how do you avoid overlapping networks across three clouds?
Where do you enforce policy, and how do you roll out a new rule?
What goes into the production readiness review, and who signs it?
How do you launch it, and what does a canary actually tell you at five nines?
What happens after launch, and how does ownership move?