kubecon24/public/day1/index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Day 1 on KubeCon24</title>
    <link>http://localhost:1313/day1/index.html</link>
    <description>Recent content in Day 1 on KubeCon24</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <atom:link href="http://localhost:1313/day1/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Opening Keynotes</title>
      <link>http://localhost:1313/day1/01_opening/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://localhost:1313/day1/01_opening/index.html</guid>
      <description>The first &amp;ldquo;event&amp;rdquo; of the day was - as always - the opening keynote. Today presented by Redhat and Syntasso.</description>
    </item>
    <item>
      <title>Sometimes lipstick is exactly what a pig needs</title>
      <link>http://localhost:1313/day1/02_sometimes_lipstick_is_what_a_pig_needs/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://localhost:1313/day1/02_sometimes_lipstick_is_what_a_pig_needs/index.html</guid>
      <description>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</description>
    </item>
    <item>
      <title>beyond platform thinking at ritchie brothers</title>
      <link>http://localhost:1313/day1/03_beyond_platform_thinking/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://localhost:1313/day1/03_beyond_platform_thinking/index.html</guid>
      <description>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 -&amp;gt; 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</description>
    </item>
    <item>
      <title>User friendly Developer Platforms</title>
      <link>http://localhost:1313/day1/04_user_friendsly_devplatform/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://localhost:1313/day1/04_user_friendsly_devplatform/index.html</guid>
      <description>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 -&amp;gt; Develop -&amp;gt; Build/Test/deploy (CI/CD) -&amp;gt; Run (Runtime/Cloud) -&amp;gt; Route (Ingress) What do we need User documentation Adoption &amp;amp; Patnership Platform as a Product Customer feedback </description>
    </item>
    <item>
      <title>Multi Tannancy - Micro Clusters</title>
      <link>http://localhost:1313/day1/05_multitennancy/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://localhost:1313/day1/05_multitennancy/index.html</guid>
      <description>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 -&amp;gt; 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, &amp;hellip;) Harmonized general Runtime (cloud agnostic): Codenamed Ethos -&amp;gt; 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&amp;rsquo;s Monitored using Prometheus Cluster Changes should be non-desruptive -&amp;gt; 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 </description>
    </item>
    <item>
      <title>Building contaienrs at scale using buildpacks</title>
      <link>http://localhost:1313/day1/06_lightning_talks/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://localhost:1313/day1/06_lightning_talks/index.html</guid>
      <description>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 -&amp;gt; Easy update How: Use the PAck CLI pack build &amp;lt;image&amp;gt; docker run &amp;lt;image&amp;gt; </description>
    </item>
  </channel>
</rss>