Platform Engineering Across Clouds: Multi-Cloud with a Single Manifest [ukr]

Every new cloud provider a company adopts usually means another set of Terraform configurations, another deployment guide, and yet another way of doing things. Costs start growing faster than the number of providers.

Platform engineering helps break this dependency: the golden path becomes the interface, while the specific cloud becomes the implementation. A developer describes what they need — a service and a production database — and the platform decides how that should be provisioned in a hyperscaler versus a local cloud provider.

In the live demo, a developer creates a new service through a self-service portal. One template, one Kubernetes manifest — and the application is deployed to two clouds at the same time. The same PostgreSQL request becomes a managed database service in one cloud and an operator-managed database running in Kubernetes in another.

We’ll also look at the limits of this approach: IAM, storage, and backups are not hidden by the abstraction layer, and I’ll explain why that’s actually a good thing.

After the talk, you’ll understand how the “request → composition” pattern works for databases across different clouds, how to start building your first golden path without creating your own PaaS, and which differences between cloud providers should remain explicitly visible to developers.