Portals and Platforms, Two Ps in a Pod? How Good Interfaces Make for Good Operability

Platforms aren’t new, but intentional platform engineering is getting more widespread adoption. One area where organisations are investing heavily is the relationship between the “frontend” user interfaces that developers get value from (CLIs, portals, APIs) and the "backend" platform orchestration components that ops manage. What should you, as a platform engineer, expect from your investments on each side? Over time, maintaining a portal and your platform orchestration becomes an important cost. But don't fret! Your platform can (and should) manage this ongoing maintenance for you, allowing you to focus on what you care about: improving developer experience and extending platform capabilities. In this talk, Abby and Jorge will provide an overview of the challenges and solutions, and map this topic to the CNCF Platform Engineering Maturity Model. You will learn what you, as a platform engineer, should be demanding of your platform orchestration tooling and your portal.

Transcript

1. portals and platforms, two Ps in a Pod? How good interfaces make for good operability Abby Bangser (she/her) abby@syntasso.io linkedin.com/in/abbybangser @abangser.bsky.social Jorge Lainfiesta (he/him) jorge@rootly.com linkedin.com/in/jrlainfiesta/
2. abby bangser
3. jorge lainfiesta
4. It takes 4–6 weeks to start coding a new service the problem
5. 1. Set up a portal 2. Create a template 3. Profit the solution
6. you stand up Backstage
7. that was the easy part
8. I see, and is “golden path” in the room with us right now?
9. And most stakeholders even like it! finally, a template is born
10. but nobody is using it :(
11. adoption drive
12. adoption drive
13. Huge success, every new service in your org is created through your Scaffolder template! congrats!
14. OH NO!! A DEPENDENCY IN YOUR TEMPLATE IS NOW A HIGH-RISK LIABILITY !!
15. Upgrades are always necessary and you need to plan for them. But how?
16. Upgrades are always necessary and you need to plan for them. but how??
17. We need to build beyond creation. We need to have operability in mind.
18. While operability can often be thought of as BAU “Increasing service operability will improve reliability, reduce operational rework…” Steve Smith On Tech
19. Operability affects future growth too! “Increasing service operability will improve reliability, reduce operational rework, and increase feature speed…” Steve Smith On Tech
20. Operability affects the past, present, and future. We need to include all of these in the way we work.
21. Reliability of existing features Future growth Current value + future TOIL The past, present, and future of operability maintainability usability extensibility
22. maintainability "BAU" / "keep the lights on" Maintains existing customers & value Activities include: • Upgrades • Security patches • Bug fixes • Optimising performance • Stabilising/replacing underlying tools
23. maintainability The software is fine, but we need to bump the database patch version in the IaC asap and across the org. the challenge Tasks to complete: ➔ Identify who is vulnerable ➔ Stop any new vulnerabilities ➔ Fix any existing vulnerabilities
24. https://backstage.io/docs/overview/architecture-overview backstage’s architecture
25. maintainability ➔ Disable the Scaffolder template ➔ Check the Catalog ➔ Create a Scaffolder template to open a PR on an impacted repo to fix the vulnerabilities. ➔ Ask impacted teams to use it ASAP. ➔ Update the template and re-enable it the portal-only experience
26. Business APIs Infra APIs Backstage frontend Backstage backend CI API call API Service Business logic Technical logic Introducing the platform layer
27. Platforms enable three tier architecture Business APIs Infra APIs Backstage frontend Backstage backend CI API call API Service Business logic Technical logic
28. API: majorVersion: 16 For majorVersion 16, use 16.3 API design enables decoupled ownership Business APIs Infra APIs Backstage frontend Backstage backend CI API call API Service Business logic Technical logic Business APIs Infra APIs
29. maintainability ➔ Same as portal to identify and stop any new vulnerabilities ➔ Your fix will be behind the API and can be tested ➔ Once confident you also fully own the roll out without app dev involvement including canary and rollback procedures the platform-driven experience
30. usability How easily an end user can find, use, learn, or manage the software. Eases adoption and reduces cost to manage support. Activities such as: • User testing • User different user personas / analytics • Small "delight" features • Enabling customization / conventional extensions
31. High adoption means others want to provide services via the platform. In this case, the analytics team wants to enable metric collection via the platform and visualisations. Tasks to complete: ➔ Enable non-platform team to provide platform extension ➔ Push a change to existing applications ➔ Provide visualisation of the collected data usability the challenge
32. ➔ Provide a Scaffold template for adding metrics via a PR ➔ Ask users to run this scaffold/merge the PR ➔ Manage any codebases that have drifted manually ➔ Create a Backstage visualisation plugin in NodeJS the portal-only experience usability
33. ➔ Introduce an analytics tooling API that the service creation API can include ➔ Write their service in any language they choose but still benefit from the life-cycles managed by the platform ➔ Output visualisations in any tool of choice the platform-driven experience usability
34. extensibility Ability to add new features and/or new use cases “If your users haven’t built something that surprised you, you probably didn’t build a platform.” - Gregor Hohpe Activities such as: • New features that support a marketplace • New interaction modes • New workflows using existing features
35. extensibility the challenge The finance team wants to provide more cost control measures. But the platform team knows this is very likely to be updated! Tasks to complete: ➔ Enable the finance team to own/change their requirements ➔ Run these checks regularly
36. the portal-only experience extensibility ➔ Backstage cannot provide autonomy to the Finance team. ➔ Alternative: provide plugins for app devs to review their own costs: ◆ Cost Insights gives developers visibility over their Cloud costs per service ◆ Tech Insights / SoundCheck you can specify targets ➔ Finance requirements are documented ➔ Create a process for regular review of the costs
37. Come up with new requirements Ticket for platform team to build Provide UAT Get end user feedback Bottlenecks create long & costly feedback loops
38. Come up with new requirements Ticket for platform team to build Provide UAT Get end user feedback Update data source Platform features can enable all users
39. the platform-driven experience extensibility ➔ The platform creates extension that even the finance team can own ➔ For example, a platform service can implement KubeCost and calls to a finance owned spreadsheet for validation ➔ The platform by design regularly reconciles itself so the cost can be tracked automatically over time
40. Platforms enable fleet management Portals focus on user interactions APIs, Discoverability
41. in conclusion ➔ Portals and platforms are technical solutions ➔ Neither alone can support your business outcomes ➔ Focus on complete and operable solutions that deliver: ◆ Usability ◆ Extensibility ◆ Maintainability
42. question time ! Abby Bangser (she/her) abby@syntasso.io hachyderm.io/@abangser @abangser.bsky.social Jorge Lainfiesta (he/him) jorge@rootly.com .linkedin.com/in/jrlainfiesta/