The document discusses the importance of focusing on internal developer platforms and APIs to enhance user experience rather than just relying on developer portals. It emphasizes that tools and code alone do not create an effective API and advocates for a shift towards a product-oriented approach, integrating user needs and extensibility. Key takeaways include the need for an API-driven development process and the recognition that platforms should evolve like software to improve efficiency and reduce complexity.

1. Flipping the script: how to
take the first step towards
internal developer platforms
Abby Bangser (she/her)
@a_bangser.bsky.social
@a_bangser

2. Behind every great
piece of software,
there is a great API
@a_bangser

3. If APIs are so key,
why is everyone in
platform engineering talking
about developer portals
@a_bangser

4. Hang on now, don’t go labeling that the hot take
To be clear,
Portals are great.
You very well might benefit from a portal.
A portal alone can not improve your platform
@a_bangser

5. Portals can provide a lot of benefits
@a_bangser

6. Business logic shouldn’t live in the UI
➔ Business customisation
◆ E.g. baseline encryption on your databases
➔ Deployment scheduling
◆ E.g. resilience across regions / cloud providers
➔ On demand infrastructure creation
◆ E.g. automated creation of test environments
@a_bangser

7. And anyways, do all users want the same interface?
>_
@a_bangser

8. Portals are just another UI.
Focus on delivering a high
quality platform API to
support your UIs
@a_bangser

9. Application
Programing
Interface (API)
A software interface that allows
many consumer applications to
interact and exchange data with
a single provider application
@a_bangser

10. Application
Programing
Interface (API)
Interface
A contract on what a
service can provide based
on given input options
Versioning
Allowing maintainers a
way to evolve, and do so
in expected ways
Experience
Shape of API data can
impact use cases and
experiences
@a_bangser

11. But Abby.
This is boring.
I already provide all those
things using _________ code.
(Terraform Modules / Ansible playbooks / Helm charts / AWS CloudFormation templates)

12. Code can look like an API Interface
A contract on what a
service can provide based
on given input options
Versioning
Allowing maintainers a
way to evolve, and do so
in expected ways
Experience
Shape of API data can
impact use cases and
experiences
https://blog.gruntwork.io/how-to-create-reusable-infrastructure-with-terraform-modules-25526d65f73d
@a_bangser

13. Code is NOT an API
The difference is in the
“Shared Responsibility Model”

14. @a_bangser
An example shared
responsibility model

15. ➔ Level of business customisation
➔ Ease of adding new capabilities
➔ Speed of access to resources
➔ An extensible API
Current tools drag us into false dilemmas
@a_bangser

16. Shift your focus.
From tech to product.
Platforms provide an experience.
@a_bangser

17. ➔ Customised to the needs of the organisation
➔ Abstractions as high level business offerings
➔ An on demand, self service offering through different clients
➔ Widely used, consistent, and extensible tooling
Focus on the intentions, not the implementations
@a_bangser

18. Introduce a platform API as-a-Product
➔ Consumer (user) benefits:
◆ Catalog of offerings
◆ On demand offerings
(even if not instant)
◆ One or more interfaces
➔ Provider (creator) benefits:
◆ Separates implementation from
behaviour
◆ Can be evolutionary
◆ Manageable business logic
@a_bangser

19. Shift your focus.
From tech to product.
Platforms provide an experience.
@a_bangser

20. Start with the experience using
API Driven Development
@a_bangser

21. Exposed variables
➔ Time To Live (TTL)
➔ Branch to deploy
➔ Update strategy
Test environment-as-a-Service
Platform defaults
➔ Size of database
➔ Region
➔ …
@a_bangser

22. API driven development
doesn’t mean you have
to start with code 👀
@a_bangser

23. JIRA demo
@a_bangser
https://drive.google.com/file/d/1yD5O4xjDjMHeKWy7UDtnCEVEALHpumfU/view?usp=sharing

24. Define your on demand API
@a_bangser

25. Platforms actually have a complex domain
@a_bangser

26. Kratix Promise
@a_bangser

27. And then compose paved paths
@a_bangser

28. Kratix provides the ability
to create a simple API
With the building blocks
to handle complexities as
you grow
@a_bangser

29. ➔ Platforms should be treated like any other software
➔ Communication starts manual but can become automated
➔ APIs enable extensibility and evolution
➔ Toil can make it seem impossible to make improvements
Key takeaways
@a_bangser

30. While an evolution
may be more practical,
by using the right (OSS) tools
you can achieve a revolution
@a_bangser

31. Thank you
Abby Bangser
abby@syntasso.io • @a_bangser • @a_bangser.bsky.social
@a_bangser

32. ● https://kratix.io
● https://www.syntasso.io/post/the-12-platform-challenges-recap
● https://tomgeraghty.co.uk/index.php/platform-as-a-product
● https://martinfowler.com/articles/talk-about-platforms.html
● https://teamtopologies.com/videos-slides/what-is-platform-as-a-product-clues-from-team-topologies
● https://sre.google/sre-book/eliminating-toil/
● https://www.slideshare.net/ddegrandis/time-theft-how-hidden-unplanned-work-commit-the-perfect-crime
-78706707
● https://swagger.io/resources/articles/adopting-an-api-first-approach/
● https://thenewstack.io/platform-engineers-developers-are-your-customers/
Additional reading
@a_bangser