http://localhost:1313/day1/index.html Recent content in Day 1 on KubeCon24 Hugo -- gohugo.io en-us http://localhost:1313/day1/01_opening/index.html Mon, 01 Jan 0001 00:00:00 +0000 http://localhost:1313/day1/01_opening/index.html The first “event” of the day was - as always - the opening keynote. Today presented by Redhat and Syntasso. http://localhost:1313/day1/02_sometimes_lipstick_is_what_a_pig_needs/index.html Mon, 01 Jan 0001 00:00:00 +0000 http://localhost:1313/day1/02_sometimes_lipstick_is_what_a_pig_needs/index.html By VMware (of all people) - kinda funny that they chose this title with the wole Broadcom fun. The main topic of this talk is: What interface do we choose for what capability. Personas Experts: Kubernetes, DB Engee Users: Employees that just want to do stuff Platform Engeneers: Connect Users to Services by Experts Goal Create Interfaces Interface: Connect Users to Services Problem: Many diferent types of Interfaces (SaaS, GUI, CLI) with different capabilities Dimensions These are the dimensions of interface design proposed in the talk http://localhost:1313/day1/03_beyond_platform_thinking/index.html Mon, 01 Jan 0001 00:00:00 +0000 http://localhost:1313/day1/03_beyond_platform_thinking/index.html The story of how Thoughtworks buit YY at Ritchie Bros (RB). Presented by the implementers at Thoughtworks (TW). Backgroud RB is a auctioneer in the field of heavy machinery Problem: They are old(ish) and own a bunch of other companies -> Duplicate Solutions Goals Get rid of duplicates Scale without the need of more personel Platform creation principles Platform is a product Building is a exercise in software eng. not operations Reduce dev friction Platform overview Platform provides selfservices Teams manage everything inside their namespace themselfes Multiple global locations that can be opted-in and -out Principles and Solutions Compliance at source of change Developers own their pipelines http://localhost:1313/day1/04_user_friendsly_devplatform/index.html Mon, 01 Jan 0001 00:00:00 +0000 http://localhost:1313/day1/04_user_friendsly_devplatform/index.html This talk was by a New York Times software developer. No real value Baseline How do we build composable components Workflow of a new service: Create/Onboard -> Develop -> Build/Test/deploy (CI/CD) -> Run (Runtime/Cloud) -> Route (Ingress) What do we need User documentation Adoption & Patnership Platform as a Product Customer feedback http://localhost:1313/day1/05_multitennancy/index.html Mon, 01 Jan 0001 00:00:00 +0000 http://localhost:1313/day1/05_multitennancy/index.html Part of the Multitannancy Con presented by Adobe Challenges Spin up Edge Infra globally fast Implementation First try - Single Tenant Cluster Azure in Base - AWS on the edge Single Tenant Clusters (Simpler Governance) Responsibility is Shared between App and Platform (Monitoring, Ingress, etc) Problem: Huge manual investment and overprovisioning Result: Access Control to tenant Namespaces and Capacity Planning -> Pretty much a multi tenant cluster with one tenant per cluster Second Try - Microcluster One Cluster per Service Third Try - Multitennancy Use a bunch of components deployed by platform Team (Ingress, CD/CD, Monitoring, …) Harmonized general Runtime (cloud agnostic): Codenamed Ethos -> OVer 300 Clusters Both shared clusters (shared by namespace) and dedicated clusters Cluster config is a basic json with name, capacity, teams Capacity Managment get’s Monitored using Prometheus Cluster Changes should be non-desruptive -> K8S-Shredder Cost efficiency: Use good PDBs and livelyness/readyness Probes alongside ressource requests and limits Conclusion There is a balance between cost, customization, setup and security between single-tenant und multi-tenant http://localhost:1313/day1/06_lightning_talks/index.html Mon, 01 Jan 0001 00:00:00 +0000 http://localhost:1313/day1/06_lightning_talks/index.html A Project lightning talk by heroku and the cncf buildpacks. How and why buildpacks? What: A simple way to build reproducible contaienr images Why: Scale, Reuse, Rebase Rebase: Buildpacks are structured as layers Dependencies, app builds and the runtime are seperated -> Easy update How: Use the PAck CLI pack build <image> docker run <image>