Кожна нова хмара в компанії зазвичай означає ще один набір Terraform, ще одну інструкцію з деплою і ще один спосіб зробити все по-своєму. Витрати ростуть швидше, ніж кількість провайдерів. Platform engineering дозволяє розірвати цю залежність: golden path стає інтерфейсом, а конкретна хмара — реалізацією. Розробник описує, що йому потрібно — сервіс і production-база даних — а платформа сама вирішує, як це виглядає у гіперскейлері, а як у локального провайдера. У живому демо розробник створює новий сервіс через портал самообслуговування. Один шаблон, один Kubernetes-маніфест — і застосунок розгортається у двох хмарах одночасно. Однакова заявка на PostgreSQL в одній хмарі стає керованим сервісом бази даних, в іншій — базою під управлінням оператора в Kubernetes. Окремо — про межі підходу: IAM, сторедж і бекапи абстракція не приховує, і я покажу, чому це нормально. Після доповіді ви знатимете, як влаштований патерн «заявка → композиція» для баз даних у різних хмарах, з чого почати свій перший golden path без побудови власного PaaS, і які відмінності між хмарами варто показувати розробникам явно.

У межах ініціативи Security Hardening ми впровадили підхід Access as Code для керування доступами в AWS. Для кожного репозиторію створюється окрема IAM-роль з permissions відповідно до принципу Least Privilege. Управління ролями винесене в централізований репозиторій, де кожен сервіс описується одним YAML-файлом. Усі зміни проходять через Pull Requests та approvals, а за допомогою Terraform і Atlantis ролі автоматично створюються або оновлюються. У результаті ми отримали масштабоване, аудитоване та безпечне керування доступами без прямого доступу команд до AWS.