Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[KCD UK] When Platforms Meet Application Develo...

Syntasso
October 24, 2024

[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.

Syntasso

October 24, 2024
Tweet

More Decks by Syntasso

Other Decks in Technology

Transcript

  1. 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
  2. 1) Observability / Networking / Security 2) CD (GitOps) 3)

    Provisioning infrastructure 4) Portals for service discovery and scaffolding
  3. We can provide KinD to run their two services together

    and make their local environment more effective! Platform engineer to the rescue!
  4. Namespace: Accounts Deployment: Monitoring Accounts Deployment: Accounts Notification $ kind

    create cluster accounts $ kubectl apply -f deploys.yaml The new user experience
  5. Except is this really solving the app dev challenges? Or

    are we just providing solutions from the platform engineering playbook?
  6. As platform engineers we often jump to these solutions because

    they are easier to find and easier to manage. Being completely honest…
  7. 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:
  8. 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
  9. 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
  10. Tools that can help: Slow feedback loops GitHub Actions Local

    Runners Comes with Go, Python, Node SDKs + Run anywhere YAML definitions
  11. 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?
  12. Key learning Contracts make explicit what users can and should

    focus on, and APIs hide the implementation details.
  13. 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
  14. 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
  15. 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.
  16. Current platform engineering beliefs needs to be examined • “Build

    for the 80%” • “Enable through templates” • “Platforms provide only central services” • “Kubernetes is your platform”
  17. • “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?
  18. Is it acceptable to reduce our scope in this way?

    More importantly, how do we make our scope clear?
  19. 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
  20. 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
  21. APIs unleash both sides. With a clear API contract, platforms

    can be built with software engineering principles.
  22. 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
  23. 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