https://kubecon25.nicolai-ort.com/tags/platformengineeringday/index.html Hugo en https://kubecon25.nicolai-ort.com/day0/01_opening/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/01_opening/index.html The usual welcome and thank you to our sponsors. And of course the anounceement of the lunch break and evening reception. This is the fifth edition of platform engineering day that originally started 2023 in Amsterdam. https://kubecon25.nicolai-ort.com/day0/02_tcg-update/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/02_tcg-update/index.html Website/Homepage Basics The TCG (no not trading card game) is a community focused on: Sharing knowledge and best practives Exploring Tools They have two meetings (one in EMEA one in APAC) rotating every week with two main formats: Hallway Track: Interactive discussion Community Track: Sessions Current Initiatives and Updates Whitepaper: Internationalisation + new simplfied language and version selection for change tracking Whitepaper is heading towards v2 Maturity Model: Simnplified language + examples and a self-assesment tool/framework Plans for v2: Usage&Helpfullness survey + Input from different viewpoints Roundtables / Interaction Community coffee every day at 7am Platform Lunchtime aka select tables for discussion Tue-Thu Both in the project pavilion on wednesday Lightning talks at the booth from 13:00 to 13:40 Closing sentence: “May your paths be golden” 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/04_vmware/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/04_vmware/index.html The usual “teaser” ment to get people to visit their stand and other talks What happens if A kernel update breaks the CNI and affect every pod by breaking An app mutates the system MTU breaking all other networking operations and even cluster management Baseline Platform engineers build abstractions every day Infra owns the hardware and hypervisor Platform own kubnernetes, gitops and so on Problem: Who owns the Node OS Node states ClusterAPI assumes immutable nodes by relacing them when updating the os, kubernetes or cri But we want mutability for: Simple config updates, Zertificate things So why immutable: Version alignment, drift detection https://kubecon25.nicolai-ort.com/day0/05_vcluster/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/05_vcluster/index.html Code/Demo Basicly a short advert for their vind project/tool. BAseline Current local setup: KIND, K3D or simmilar tools Problem: Getting things like GPUs to work, manual image loading, no built-in loadbalancers Result: There is still a gap between local and prod Their solution: vCluster in Docker (VIND) Features: Built-in LB, Sleep/wake, Pull-through Cache, Multi-Node Clusters, External Nodes (via VPN) USP: Platform UI https://kubecon25.nicolai-ort.com/day0/06_aiplatforms/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/06_aiplatforms/index.html A call to joint them at their booth and reading their whitepaper. BAseline 2024: LLMs 2025: Agents 2026: Our platform/infra can not keep up -> The number of def Mandate Drive AI-readyness initiatives Data-driven ai rollout Measure for impact instead of activity or speed Paved paths and guardrails AI infra optimizations Observations Whats good for humans is also good for llms (clear documentation, strucutred data, readable code, …) Metrics from out tools only measure that something is happening -> We need a framwork for DX and AI https://kubecon25.nicolai-ort.com/day0/07_scalingsatisfaction/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/07_scalingsatisfaction/index.html Sched Link Website/Homepage https://kubecon25.nicolai-ort.com/day0/08_staging/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/08_staging/index.html Slides Sched Link Code/Demo Website/Homepage Website/Homepage By me: That’s my talk - yay! 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 https://kubecon25.nicolai-ort.com/day0/13_gitops-paradox/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/13_gitops-paradox/index.html Sched Link Code Website/Homepage Baseline We all like files, humans like them, they are easy to use and AI can use them Git is a good version manager GitOps is cool and we want to keep it Problem: I want to do something and now i need to create a yaml file and open a pr -> High toil Question: Should git always be the primary entry path for changes Idea: Use kubernetes api as our api server, have an operator that handels creation of manifests in git + promotions and so on and the changes to the “real” clusters are always made via gitopös The paradox We shield people from the kubernetes api and force them to use git We build our own custom apis on top of the kubeapi anyways Solution: Why not go back to using the Kubernetes API (humans and robots can use it) Principles of the reverse gitops manifest API first (via Kubeapi) to reuse auth, crds, status, controllers and more Capture intent not implementation -> Not api-only (if you can do it bi-directional) with reversible&declarative resources GitOps applies -> Changes are always piped through gitops for reviews, history, rollback, promotions, … Implemantations examples Use KRO as the abstraction that captures the intention GitOps Reverser https://kubecon25.nicolai-ort.com/day0/14_finops/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/14_finops/index.html Sched Link A case study from expedia about finops. The Cost-Reliability disconnect Background: Modern Infrastructure is complex ans large (1000s of clusters, multi-region,…) with huge operational responsibilities (SLA, SLO, scalabiloity, …) Platform Team: REliability, Performance, Stability FinOps Team: Cloud Resources reduction, budget adherence, efficiency Problem: Conflicting goals and often organizationally seperated Blind cost optimzation can lead to unintentional stability/performance problems that can quickly spiral Blind stability optimizations quickly lead to large overhead/overprovisioning and huge costs Patterns Establish views & Baselines: Unserstand cost per cluster/workload and utilization patterns Revisit legacy: Old configs like static sizing, huge buffers, … Embrace rearchitecture without fear: Consolidation, instance optimization, infra rededisn should all be on the table Views & baselines General recommendations https://kubecon25.nicolai-ort.com/day0/11_goldenpath/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://kubecon25.nicolai-ort.com/day0/11_goldenpath/index.html Slides Sched Link A lot of people have talked about golden paths for platforms since KubeCon EU 2022 (including the speaker of this session). Most of these talks only tell you why you need this and about the value-add but not about the journey. Baseline Golden Path: A supported opinioated way to build and deploy software that makes the right wa the easiest way while not beina a mandate but a product and roducing decision fatique Intro analogy: The bikepaths are the golden path of amsterdam: Strongly oppinionated and self-service, safe by default and built progressivly -> Reduces cognitive load The golden path always related to the journey across the platform maturity model (our lord and savior of the day) How do we start (and continue) Phase 0: Chaos Every team has their own deployment script (or just kubectl apply -f) Same goal, 0 consistency, no standards Deploy latest, no limits, …. Phase 1: Standardize Unify existing scripts