Slide 1

Slide 1 text

The Future of Platforms: The Invisible Glue Between Backstage and Terraform Daniel Bryant Product Marketing Abby Bangser Principal Engineer

Slide 2

Slide 2 text

● Top-down, application developer-focused ○ “The Backstage service catalog is fantastic, but the support for day 2 ops… not so much” ● Bottom-up, operations/infrastructure-focused ○ “The Terraform workflow is fantastic, but infrastructure abstractions leak through to developers (HCL, K8s, etc)” ● Middle-out, platform engineering-focused ○ X-as-a-service, process automation, fleet management ○ “Platform as a product” approach Tl;dr: How do you build a platform?

Slide 3

Slide 3 text

Introductions Abby Bangser Principal Engineer @ Syntasso Daniel Bryant, Product Marketing @ Syntasso

Slide 4

Slide 4 text

The “what” of platforms 🏗

Slide 5

Slide 5 text

“Platform engineering improves developer experience and productivity by providing self-service capabilities with automated infrastructure operations. It is trending because of its promise to optimise the developer experience and accelerate product teams’ delivery of customer value.” https://www.gartner.com/en/articles/what-is-platform-engineering Gartner: What is platform engineering?

Slide 6

Slide 6 text

“Platform engineering improves developer experience and productivity by providing self-service capabilities with automated infrastructure operations . It is trending because of its promise to optimise the developer experience and accelerate product teams’ delivery of customer value.” https://www.gartner.com/en/articles/what-is-platform-engineering Gartner: What is platform engineering?

Slide 7

Slide 7 text

gartner.com/en/newsroom/press-releases/2023-11-28-gartner-hype-cycle-shows-ai-practices-and-platform-engineering-will-reach-mainstream-adoption-in-software-engineering-in-two-to-five-years Platform engineering expectations

Slide 8

Slide 8 text

Platform challenges

Slide 9

Slide 9 text

The “why” of platforms 🤔

Slide 10

Slide 10 text

Why build a platform? “The thing to keep in mind about Backstage is that its purpose is to improve developer onboarding time [...] it lets you more easily encode best practice and the best and fastest way to do things. Organisations adopt Kubernetes without understanding that if you're not building a custom PaaS for your organisation, you're wasting your time.” reddit.com/r/devops/comments/10guddj/backstageio_common_issues_and_pitfalls/#t1_j59lbs3-comment-rtjson-content

Slide 11

Slide 11 text

Why build a platform? “Operations were just drowning . We spent too much time on repetitive requests from developers that asked stuff in Slack or Jira Tickets. [...] We first trained people around Terraform and Helm but they just didn't want to deal with that and they ended up poking senior developers to fix things instead [...] This basically created a shadow operations problem on top.” reddit.com/r/devops/comments/stuep4/weve_spent_months_building_this_platform_devs/

Slide 12

Slide 12 text

● Go faster: Platform teams need to provide “everything as a service” to help rapidly and sustainably deliver value to end-users ● Decrease risk: Teams need to automate manual processes in reusable components ● Increase efficiency: You need to manage and scale your digital platform and resources as a fleet What are the goals of your platform?

Slide 13

Slide 13 text

The “how” of platforms 󰠼󰲪󰠹

Slide 14

Slide 14 text

“Backstage is my platform. Developers go here to spin up a new application, deploy it, and view metrics” ✅ Fantastic developer experience (and service catalog) ✅ Highly customisable ❌ Often a direct relationship with underlying infrastructure code ❌ Not easy to use a different interface when needed ❌ Day 2 aspects of the portal and plugins can be challenging Top down, app developer-focused rollout

Slide 15

Slide 15 text

Git Repo: tiger/checkout .gitlab-ci.yml src/ pom.xml README.md Git Repo: tiger/checkout .gitlab-ci.yml src/ pom.xml README.md Git Repo: tiger/checkout .gitlab-ci.yml src/ pom.xml README.md Git Repo: tiger/checkout .gitlab-ci.yml src/ pom.xml README.md Git Repo: tiger/checkout .gitlab-ci.yml src/ pom.xml README.md …67 repos… 2020 2018 Git Repo: tiger/checkout .gitlab-ci.yml src/ pom.xml README.md Git Repo: tiger/checkout .gitlab-ci.yml src/ pom.xml README.md Git Repo: tiger/checkout .gitlab-ci.yml src/ pom.xml README.md …12 repos… 2016 $ sb create new service \ --name "checkout" \ --language "java" \ --team "tiger" Our ServiceBuilder wasn't a "service manager"

Slide 16

Slide 16 text

“Terraform is my platform. I can orchestrate all of my infrastructure via HCL and cron jobs, and the GitOps pipelines automatically deploy applications” ✅ Everything-as-code ✅ Highly automatable ❌ Infrastructure abstractions leak outwards towards developers ❌ At scale, the diversity of tech can become challenging to orchestrate Bottom up, operations-focused rollout

Slide 17

Slide 17 text

● Terraform module with conventions meant PR reviews were necessary ● Business requirements were managed out of band ● Transition from Terraform to Controllers for Kubernetes required training HCL self service was overly optimistic

Slide 18

Slide 18 text

The missing middle? 🏗

Slide 19

Slide 19 text

https://thenewstack.io/crossplane-what-most-people-get-wrong-and-how-to-get-it-right/ https://platformengineering.org/platform-tooling https://cnoe.io/ https://www.kratix.io/

Slide 20

Slide 20 text

syntasso.io/post/platform-engineering-orchestrating-applications-platforms-and-infrastructure

Slide 21

Slide 21 text

syntasso.io/post/platform-engineering-orchestrating-applications-platforms-and-infrastructure

Slide 22

Slide 22 text

Making it happen 💪

Slide 23

Slide 23 text

Tech "stacks" are emerging ● The “BACK” stack : Backstage, Argo, Crossplane, Kyverno ● CNOE Framework : Cloud Native Operation Excellence ● Kubefirst ● DIY: All the other CNCF tech ++ ● … More opinionated Less opinionated Platform builders need to elevate above Infra as Code

Slide 24

Slide 24 text

Business requirements change, user expectations expand, APIs are at the core of sustainable platforms ● Open Application Model (OAM) / Score ● Kratix and Promises ● KubeBuilder ● Crossplane ● Massdriver ● … More user focused More implementation focused Platform extensibility and usability demands APIs

Slide 25

Slide 25 text

The tech can be overwhelming

Slide 26

Slide 26 text

Build it, and they will come Build it, and they will come Solve problems, and they will come ⚾

Slide 27

Slide 27 text

thoughtworks.com/en-gb/insights/looking-glass/platforms-as-products Don't forget product focus

Slide 28

Slide 28 text

Don't forget product focus thoughtworks.com/en-gb/insights/looking-glass/platforms-as-products

Slide 29

Slide 29 text

Wrapping up 🎉

Slide 30

Slide 30 text

● 🏗 Build your platform intentionally ○ APIs, abstrations, and automation are key ○ Middle-out, platform engineering-focused ○ Watch out for the missing middle: “platform orchestrators” ● 👀 Watch for warning signs ○ Struggling with scaling day 2 operations with your portal? ○ Infrastructure abstractions leaking to developers? ● 🎯 Focus on “platform as a product” Conclusion

Slide 31

Slide 31 text

syntasso.io/post/platform-engineering-orchestrating-applications-platfo rms-and-infrastructure docs.kratix.io/main/quick-start speakerdeck.com/syntasso Thank you!