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 just an implementation detail. 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 completely hidden by the abstraction layer — and I’ll explain why that is 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 visible to developers.

Within the Security Hardening initiative, we introduced an Access as Code approach for managing AWS permissions. Each repository is assigned a dedicated IAM role with permissions aligned to the principle of least privilege. Role management is centralized in a single repository, where each service is defined using a single YAML file. All changes go through pull requests and approvals, while Terraform and Atlantis automatically create or update IAM roles. As a result, we achieved scalable, auditable, and secure access management without direct access to AWS for engineering teams.