[KCD UK] When Platforms Meet Application Developers

What do application developers have to do with Kubernetes Community Days? What can we learn as platform engineers from our app development teams, and how can we use that knowledge to build better platforms?

Join us in this presentation to discover three strategies to make your platforms more developer-friendly on both sides:

First, we will start by discussing how application tech stacks and their ecosystem heavily influence the platform's interfaces, practices, and adoption rate. What considerations do we need to take into account?

Next, we acknowledge platform engineers can learn more than just user needs from their app developers. Next, we will delve into the kind of architectural patterns that developers are already using and how they can be applied to our platforms.

And finally, in KCD fashion, we will, of course, look at how Kubernetes fits into this picture even while hiding it's dependency can be a key way to reduce application developer cognitive load. In particular, offline developer inner-loops for Kubernetes deployed applications can be a crucial part of our platform strategy.

Developers live on both sides of the platform, and they can and should invest in learning from each other to elevate the developer experience across their organization.

Transcript

1. When Platforms Meet Application Developers Abby Bangser - Syntasso Mauricio “Salaboy” Salatino - Diagrid
2. CNCF TAG APP Delivery • Platforms WG https://tag-app-delivery.cncf.io/wgs/platforms/ • App Dev WG https://tag-app-delivery.cncf.io/wgs/app-development/ • Blog Posts https://www.diagrid.io/blog/when-platform-teams-meet-developers
3. Platform Engineering Track KubeCon NA 2023 and EU 2024
4. 1) Observability / Networking / Security 2) CD (GitOps) 3) Provisioning infrastructure 4) Portals for service discovery and scaffolding
5. But does this match app developer (user) needs?
6. Imagine that you work for financial organization …
9. We can provide KinD to run their two services together and make their local environment more effective! Platform engineer to the rescue!
10. Namespace: Accounts Deployment: Monitoring Accounts Deployment: Accounts Notification $ kind create cluster accounts $ kubectl apply -f deploys.yaml The new user experience
11. Except is this really solving the app dev challenges? Or are we just providing solutions from the platform engineering playbook?
12. As platform engineers we often jump to these solutions because they are easier to find and easier to manage. Being completely honest…
13. 1. Problem discovery to understand the what 2. Software delivery practices to improve how maintainable and extensible the solution is To meet our users where they are, we need to develop two skills:
14. So Mauricio, what DO you need??
15. User need: inner-loop support
16. Oh, and k8s makes that so much worse
17. First category of user pains we have discovered • Onboarding new team members • Debugging on personal computer (with remote environments) • One wrong version can cause a lot of issues
18. Unreproducible and complex local environments
19. Tools that can help: unreproducible and complex local environments https://github.com/devcontainers
20. Key learning Even local environments can have a contract between app developers and platform
21. User need: outer-loop support
22. A second category of user pains • Pushing changes can be queued and take hours to pass through pipelines • Even local changes require containerising and running k8s • Tests behave differently locally and on CI
23. Slow feedback loops
24. Tools that can help: Slow feedback loops GitHub Actions Local Runners Comes with Go, Python, Node SDKs + Run anywhere YAML definitions
25. Key learning Modular contracts provides more than just composability, they also provide flexibility of environment
26. User need: Help to collaborate with other teams
27. Shared concenrns across teams/services
28. The third category of user pains • Who and how are services made resilient? Or observable? • Who defines data structures? What is required/recommended/bespoke? • Do libraries exist? Are they allowed? How can a new library be identified or created?
29. Lack of standardised conventions and practices
30. Tools that can help: Lack of standardised conventions and practices
31. Key learning Contracts make explicit what users can and should focus on, and APIs hide the implementation details.
32. To meet our users where they are, we need two skills/activities: 1. Problem discovery to understand the what 2. Software delivery practices to improve how maintainable and extensible the solution is
33. To meet our users where they are, we need two skills/activities: 1. Problem discovery to understand the what 2. Software delivery practices to improve how maintainable and extensible the solution is
34. They would be even more powerful if they were managed across an organisation. All of these tools exist, but many are implemented as isolated solutions.
35. Current platform engineering beliefs needs to be examined • “Build for the 80%” • “Enable through templates” • “Platforms provide only central services” • “Kubernetes is your platform”
36. • “Build for the 80%” • “Enable through templates” • “Platforms provide only central services” • “Kubernetes is your platform” ◦ How do you still enable the 20% to be compliant and efficient? ◦ Who manages upgrades, updates, and running software? ◦ sure, but what about high value “inner-loop” tooling e.g. local environments? ◦ Few orgs are 100% k8s, how do you support non-k8s services & experience? How does that feel from the app developer side?
37. Is it acceptable to reduce our scope in this way? More importantly, how do we make our scope clear?
38. API contracts clarify scope and ownership • A contract explicitly defines input options and return values • Contract structure begins to implicitly set an ownership model • APIs are a complete contract by decoupling implementation
39. Contracts help to alleviate app developer (user) pain • Most tools will integrate with APIs and contracts • Clear boundaries and single responsibility enables composability • APIs reduce cognitive load by also removing the operational load
40. APIs unleash both sides. With a clear API contract, platforms can be built with software engineering principles.
41. Top software principles that apply to platforms 1. Choose architectures intentionally ◦ Think about rate of change, coupling, and resiliency requirements 2. Deliver small, fast, and safe changes ◦ Build trust through CI/CD testing and rollout/rollback plans ◦ Even “offline” apps can have CD, look at mobile/desktop app patterns 3. Build in cross functional requirements ◦ User experience including onboarding, maintenance onus, and overall cognitive load ◦ Speed to market to capture opportunity and reduce risk
42. Takeaways • Product discovery for platforms is important, at least talk to app devs! • Platforms need to support local development experiences • Build platforms as APIs, not templates
43. Applying common application developer practices can supercharge platform engineering outcomes and better server app developer users
44. Thank you! Abby Bangser - Syntasso Mauricio “Salaboy” Salatino - Diagrid