Talk given at Equal Experts internal conference (gEEk) and talks about the patters associated with DevEx and the need for better platform engineering experience if we are expected to build great application engineer experiences.

1. DevEx for Platform Engineers:
Introducing a FOSS Framework
for Building Platforms
Abby Bangser (she/her)
@a_bangser.bsky.social
@a_bangser

2. Today should be interactive,
let’s discuss the following topics
1. Clarify target audience for “DevEx”
2. Define DevEx patterns
3. Explore options for the builders/operators of DevEx

3. First of all, what is
Developer Experience
(DevEx)?

4. Version one:
General
developer
happiness
https://stackoverflow.blog/2022/03/17/new-data
-what-makes-developers-happy-at-work/

5. Version two:
Business
delivery efficiency https://cio.vmware.com/2022/11/trading-productivity-
for-value-how-it-leaders-are-modernizing-devex.html

6. Version three:
Reduced
cognitive load
Focused on reducing
intrinsic (task specific, e.g.
writing to a queue)
and
extraneous (environmental, e.g.
provisioning that queue)
https://www.slideshare.net/matthewskelton/what-is-platform-as-a-
product-clues-from-team-topologies-puppetize-2020-matthew-skelton
https://mcdreeamiemusings.com/blog/2019/10/15/the-good-the-bad-and-the-can-be-ugly-the-three-parts-of-cognitive-load

7. But who are these
“developers”?

8. Version one:
Greenfield app
developers
➔ Focuses on getting
started fast
➔ Difficult or costly to
scale

9. Version two:
New hires
➔ Simple and sensible
defaults
➔ Possibly detached from
reality of business goals
https://www.lob.com/blog/new-hire-to-first-commit-in-10-minutes

10. Version three:
Stream Aligned
Teams
➔ Business value driven
➔ Focused on day to
day experience
https://www.slideshare.net/matthewskelton/what-is-platform-as-a-product-clues-from-team-topologies-puppetize-2020-matthew-skelton

11. So in summary,
the focus on DevEx today seems to mean:
Improving the effectiveness
of DevOps practices on
mature/long-lived
applications by decreasing
the application developers
intrinsic and extraneous
cognitive load.

12. So in summary,
the focus on DevEx today seems to mean:
Improving the effectiveness
of DevOps practices on
mature/long-lived
applications by decreasing
the application developers
intrinsic and extraneous
cognitive load.
Which of course leads to:
➔ Faster time to business value
➔ Faster inception of applications
➔ More consistency (leading to fungibility
and easier onboarding)
➔ Developer happiness

13. So in summary,
the focus on DevEx today seems to mean:
Improving the effectiveness
of DevOps practices on
mature/long-lived
applications by decreasing
the application developers
intrinsic and extraneous
cognitive load.
Which of course leads to:
➔ Faster time to business value
➔ Faster inception of applications
➔ More consistency (leading to fungibility
and easier onboarding)
➔ Developer happiness

14. Common patterns that
help deliver DevEx

15. Centralise certain
configurations /
decisions
➔ Reusable modules that
expose some values
but not all

16. Provide on-demand
capabilities
“as-a-Service”
➔ Can be async
➔ Must be self serve
➔ Clear set of options

17. Design paved
road high level
offerings
➔ Reduces need to
understand underlying
implementation
➔ Can confuse ownership
model when debugging is
necessary

18. So in summary,
DevEx presents as a set of capabilities
Developers expect the ability to request services
when and where they need them, with a sense of
confidence that the services are easy and safe to
use, without needing to think about the underlying
implementation.

19. So in summary,
DevEx presents as a set of capabilities
Developers expect the ability to request services
when and where they need them, with a sense of
confidence that the services are easy and safe to
use, without needing to think about the underlying
implementation.

20. How do the creators of
these experiences build
and manage them?

21. ➔ High level of opinions
➔ Low control by operations
➔ Configurable but difficult to
customise / extend
➔ Not all of an organisation
can use the same solution
➔ Pricing model can affect
architectural design
Buy very narrow
solutions

22. ➔ High level of opinions
➔ Low control by operations
➔ Configurable but difficult to
customise / extend
➔ Not all of an organisation
can use the same solution
➔ Pricing can model affect
architectural design
Provide access to
very broad low
level options

23. Provide
templating
➔ Not user focused self
service
◆ Often requires learning new
languages and/or waiting for review
➔ Confuses ownership model
➔ Hard to manage sprawl
➔ Hard to update / upgrade

24. Build a custom
service
➔ A lot of upfront cost
➔ No great patterns / support
available
➔ Requires strong software
engineering design skills
➔ May encourage Not Invented
Here (NIH) syndrom

25. Build a custom
service
➔ A lot of upfront cost
➔ No great patterns / support
available
➔ Requires strong software
engineering design skills
➔ May encourage Not Invented
Here (NIH) syndrom

26. Dapr (Distributed APplication Runtime)
provides you with APIs that abstract away
the complexity of common challenges
developers encounter regularly when
building distributed applications.
These API building blocks can be
leveraged as the need arises - use one,
several or all to develop your application
faster and deliver your solution on time.
App
App
App
App

27. Provides:
● Easier application access to
underlying infrastructure
Still requires:
● A way to provision the
infrastructure that the
application is calling
App
App
App
App

28. youtube.com/watch?v=zfKwxL9KZ9I

29. Help organizations build their platforms
like the cloud vendors build theirs—with
control planes.
Crossplane is an open source, CNCF
project built on the foundation of
Kubernetes to orchestrate anything.
Encapsulate policies, permissions, and
other guardrails behind a custom API line
to enable your customers to self-service
without needing to become an
infrastructure expert.

30. Provides:
● A pattern for generating
consistent user facing APIs
● A pattern for creating paved
paths on lower level offerings
Still requires:
● Management across broad
infrastructure landscape
● Logic is either declarative
YAML or custom controller

31. Kratix is a framework used by
platform teams to build the
custom platforms tailored to
their organisation.
Platforms are powered by
Promises that define
operational capabilities
as-a-service.

32. Provides:
● Decoupling of scheduling
from deployment
● Pipeline as a first class
concern
Still requires:
● Reliance on strong building
blocks

33. So in summary,
Platforms are a pattern that support DevEx
Platforms needs to provide the business with ownership over the
DevEx experience including API design and configuring/exposing of
3rd party dependencies while managing organisational requirements
(FinOps/security).
While organisations can buy much of their platform, this layer of
interaction with the user is best suited to an in-house built system.
This solution needs to support modern and legacy processes.
Platform engineers tasked to build this are craving a better
experience which will, in turn, result in better application DevEx.

34. So in summary,
Platforms are a pattern that support DevEx
Platforms needs to provide the business with ownership over the
DevEx experience including API design and configuring/exposing of
3rd party dependencies while managing organisational requirements
(FinOps/security).
While organisations can buy much of their platform, this layer of
interaction with the user is best suited to an in-house built system.
This solution needs to support modern and legacy processes.
Platform engineers tasked to build this are craving a better
experience which will, in turn, result in better application DevEx.

35. Thank you!
kratix.io
abby@syntasso.io / abby@paintedwavelimited.com
@a_bangser / @a_bangser.bksy.social

36. A reference architecture with Kratix

37. Goals:
1. Highlight the current state of
building/operating DevEx
2. Highlight the patterns associated with
DevEx
a. Hidden / auto
b. On demand / as-a-Service
c. Paved road
3. Look at current mature options
a. Dapr
b. Crossplane