Quick questions: I have the feeling that there are a lot of resources around to talk about what’s Platform Engineering is, but not so much about a concrete example of what that means to turn an existing workflow into a Platform Engineering mindset workflow. First question: do you have the same feeling? Second question: Would you be interested in an article explaining how company X turns a ticket-based provisioning stack into a self-service one with a Platform Engineering mindset? 👀

Question 1. Sometimes. But we may have different definitions of workflow. Do you have an example of a workflow that you sense can/should be "platformized?" (patent pending 🙂 )

maybe this helps: https://github.com/awslabs/app-development-for-backstage-io-on-aws https://www.youtube.com/playlist?list=PLhr1KZpdzukemoBUAPNUMCgGk88pdURJB

Q1: Yes, I have the same feeling. To me, platform engineering is an emerging trend that is going to go hand-in-hand in the future supporting DevOps within an organization to speed-up go to market of your services. Q2: Yes, very much interested.

@Ron Cuirle an idea would be to take a traditional DevOps tech stack (E.g. Kubernetes + ArgoCD ) and turn it into a “Platform Engineering” mindset stack. How to make developers use this stack with the appropriate developer experience. It’s just an example but we can apply this one to multiple examples.

Our approach at Shipt has been a singular developer interface (UI and CLI). Similar to Backstage. Everything is exposed through it - even if they're just links to other systems. Devs follow along from git commit to running in prod. They don't have to take action in between. The primary way to establish a platform mindset is to treat the platform like a product. Microsoft Office isn't really a product; it's a suite. People experience "Office" whether they're using Word or Excel.