https://kubecon25.nicolai-ort.com/tags/platform/index.html Hugo en https://kubecon25.nicolai-ort.com/day0/03_whobuiltthis/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/03_whobuiltthis/index.html Sched Link The talk was kept interactive through live surveys. Baseline Research on underrepresented groups in platform engineering focus mostly on gender and seneority Problem: There is little data about the devide beween standard and non-standard users of platfoms Problems and changes In the past often the code was the documentation leading to the need of revse engineering Problem: This might work for some people (confident and open to do a deep dive into the code) but can leat to major onboarding problems -> Rise of documentation (platform stays the same but the interface for onboarding changes) Breaking point: Production incidents by human designs based on the wron assumption of humans always being very careful -> The process is the cause so we have to change the process and add guardrails Abstraction leakage: Our Pod is failing. Why? Resource error, but the real issue was rooted in the infrastructure (Problem with spot instances but only the platform team knows this, not the app team) -> The platform assumed knowlege about infrastructure Decisions are usually made by senior engineers but the alternative viewpoints (new hires, juniors, users without deep knowledge) who struggle are the ones that actually reveal blind spots Who is the platform built for The platform can not cale if it’s only built for the engineers who built it We have to invite engineers from different viewpoints to improve our platform Abstractions are ok bu they can’t hide important information Humans as a Platform Perspective shapes design -> Optimize for usability Broader participation reveals blind spots -> Improve dx wihout lowering standards Developer experience is an architectural concern -> Observability and usability must be Measuring success Time to first deployment Self-service success rate Help requests per workflow Workflow failure recovery time Takeaways Platform usabiility is a core engineering responsibility Designs needs to include different view points and cognitive needs Self service and clear documentation reduce friction Fast feedback loops enable continuus improvement Balance accessability with developer speed -> Inclusive desig should not hinder improvements but go hand in hand https://kubecon25.nicolai-ort.com/day0/09_hanover/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/09_hanover/index.html Sched Link Platform Scorecard Recruting producers Time to build a platform Why? Boss want’s that How? Who knows First: Gather rquirements Then: No one actually uses our platform -> The only users were the low value ones and other teams Why does no one like out platform? Requirements are constantly changing so if you take 6 months they need something else/additional -> The platform no longer serves it’s users Time to delivery is real important -> If you are no longer the bottleneck people actually like you Over time your clean catalog slowly grows to become a sprawl of garbage with specialized variations for everything Why did it fail Platforms are treated as a project with achivable end goals Building in a slio (accidentally) -> Requirements change and require lots of work and optimization You might think that you are your own customer but you are not -> There are many different perspectives involved (DEV, SRE, OPS,. Management, …) How can we prevent this fallacies? Hire a exdperiences platform product manager (if you can) Output over outcome -> Maturity model helps Focus on user values like speed, safety, efficiency, scalability Find your exempar team instead of trying to build for everone from zero -> Choose an experiment friendly team with high visibility and a good feedback culture Adopt tools and practives to make things easier GitOps over imperative pipelines Build shared platform services (undifferentated infra like registries, github runners and stuff like that) Ship observability as early as possible (opptinionated dashbaords and alerts from day 1) Make everything self-service Standardize as platform capabilities Bundle each capability as an api and associated workflow Expose the APIs thrugh a pluggable IDP Recruit producers (providers) they are experts and allow you to scale your capabilities Be the layer that facilitates exchange between producers and consumers TODO: Steal persona matrix from slides https://kubecon25.nicolai-ort.com/day0/10_sourcing-your-idp/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/10_sourcing-your-idp/index.html Slides Sched Link Homepage Dev Rel A talk by Lian and i can always recommend her talks. Background 55% of orgs have adopted but only 27% have integrated best practives -> They built technically impressive ghost towns We’re not good at explaining/thinking about platforms -> Viewing them as a whole house instead of the collection of bricks that make them up The deployment process evolved from scripts to services (shared scripts) to platforms (shared scripts with extra steps) Platform adoption is not a technical but an advocacy problem Idea: Treat the platform to as a shared project -> We need devrel (Dicover evaluate learn build scale) TODO: Steal lian’s evolution slide https://kubecon25.nicolai-ort.com/day0/12_extensible/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/12_extensible/index.html Sched Link Website/Homepage Baseline Complexityis unavoidable: May it be in platforms, physics or biology Complexity usually grows rappidly followed by a phase of making things better -> “Let’s make virtual machines easier but add 500x more of them” (the story of kubernetes) TODO: Steal chart from slides Mthods to the madness We want confluence (the mathematical one, not the atlassian one): If there are different paths that are semanticly the same it should not matter wich path we take As long as we achive the same goal the specifics should not matter that much Narrow Protocol: A narrow and slowly evolving protocol allows us to have diversification below and above the narrow point Examples: IP Adresses and DNS haven’t changed in a long time -> We can use this narrow thing to build monsters on top of Allow everything above and below your platform to change flexibly and evolve Vertical integration: When you’re getting integrated you become valuable (again the DNS example) -> Vertical integration always beats technological capabilities Picking the right protocol might be hard, but choosing a narrow and integrated one helps TODO: Steal confluence slide