When Platforms Meet Application Developers Abby Bangser - Syntasso Mauricio “Salaboy” Salatino - Diagrid

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

Platform Engineering Track KubeCon NA 2023 and EU 2024

1) Observability / Networking / Security 2) CD (GitOps) 3) Provisioning infrastructure 4) Portals for service discovery and scaffolding

But does this match app developer (user) needs?

Imagine that you work for financial organization …

No content

No content

We can provide KinD to run their two services together and make their local environment more effective! Platform engineer to the rescue!

Namespace: Accounts Deployment: Monitoring Accounts Deployment: Accounts Notification $ kind create cluster accounts $ kubectl apply -f deploys.yaml The new user experience

Except is this really solving the app dev challenges? Or are we just providing solutions from the platform engineering playbook?

As platform engineers we often jump to these solutions because they are easier to find and easier to manage. Being completely honest…

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:

So Mauricio, what DO you need??

User need: inner-loop support

Oh, and k8s makes that so much worse

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

Unreproducible and complex local environments

Tools that can help: unreproducible and complex local environments https://github.com/devcontainers

Key learning Even local environments can have a contract between app developers and platform

User need: outer-loop support

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

Slow feedback loops

Tools that can help: Slow feedback loops GitHub Actions Local Runners Comes with Go, Python, Node SDKs + Run anywhere YAML definitions

Key learning Modular contracts provides more than just composability, they also provide flexibility of environment

User need: Help to collaborate with other teams

Shared concenrns across teams/services

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?

Lack of standardised conventions and practices

Tools that can help: Lack of standardised conventions and practices

Key learning Contracts make explicit what users can and should focus on, and APIs hide the implementation details.

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

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

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.

Current platform engineering beliefs needs to be examined ● “Build for the 80%” ● “Enable through templates” ● “Platforms provide only central services” ● “Kubernetes is your platform”

● “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?

Is it acceptable to reduce our scope in this way? More importantly, how do we make our scope clear?

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

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

APIs unleash both sides. With a clear API contract, platforms can be built with software engineering principles.

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

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

Applying common application developer practices can supercharge platform engineering outcomes and better server app developer users

Thank you! Abby Bangser - Syntasso Mauricio “Salaboy” Salatino - Diagrid