docs(day2): added kcp talk

content/day2/05_kcp.md

@@ -0,0 +1,104 @@
+---
+title: Building a Platform Engineering API Layer with KCP
+weight: 5
+tags:
+ - kcp
+ - platform
+---
+
+<!-- {{% button href="https://youtu.be/rkteV6Mzjfs" style="warning" icon="video" %}}Watch talk on YouTube{{% /button %}} -->
+<!-- {{% button href="https://docs.google.com/presentation/d/1nEK0CVC_yQgIDqwsdh-PRihB6dc9RyT-" style="tip" icon="person-chalkboard" %}}Slides{{% /button %}} -->
+
+## Baseline
+
+- Platform is automated and self service
+- We always have a bunch of consumers and service providers that get connected via an internal db plattform
+
+```mermaid
+graph TD
+    subgraph Consume
+        A
+        B
+    end
+    subgraph Provider
+        Cert
+        DB
+    end
+    IDP
+    A-->|discover available services|IDP
+    A-->|order db|IDP
+    IDP-->|Notify|DB
+    DB-->|fulfill|A
+```
+
+## Why KubeAPI
+
+- We have it all: Groups, Versions, Optionally Namespaced, ...
+- It is extendable via CRDs
+- Challenges: CRDs are Cluster Scoped -> Everyone shares them across Namespaces
+- Idea: Everyone get's their own cluster
+- Problem: Spinning up clusters is slow and resource intensive
+- Idea: "Lightweight clusters" aka Hosted Control Plane
+- Problem: Now we have to share CRDs Across Clusters
+
+## WTF is KCP?
+
+- Idea: What if we had seperate control planes but with a shared datastore
+- Goal: Horitontally scalable control plane for extenable APIs
+- You don't need Kubernetes to run KCP (it's a standalone binary)
+- It does not spin up a real api server but a workspace wit a low memory footprint
+- It does not implement all of the container related stuff (Pod, Deployment, ...)
+
+### Access and setup
+
+```mermaid
+graph LR
+User-->|Create APIServer Team A|KCP
+KCP-->|Kubeconfig|User
+subgraph KCP
+    APIA(Workspace Team A)
+    APIB(Workspace Team B)
+    Datastore
+end
+
+User-->|Kubectl get ns|APIA
+APIA-->|Return NS for Workspace A|User
+```
+
+### Internal Organization
+
+- Workspaces are organized in a tree
+- Possibility of nested fun: `/clusters/root:org-a:team-a`
+- Sub-Workspaces can't access ressources from the root workspace
+
+```mermaid
+graph TD
+Root
+Root-->OrgA
+Root-->OrgB
+OrgA-->TeamA
+```
+
+### Sharing
+
+- KCP owns all Workspaces -> It can share stuff across clusters
+- To share: APIExport (Can Share multiple CRDs in one Package)
+- To use: APIBinding (Just reference the Exported API By Path to Workspace and name)
+
+### Order fulfillment
+
+- Classic Kubernetes: Controller -> But they are isolated, aren't they?
+- Virtual Workspace: Provite a computed view of parts of a workspace -> Basicly a URL that you provide to the controller that can be used to watch objects accross workspaces
+- Part of KCPs magic -> You don't create it, but it get's managed for each APIExport
+
+## Notes from the demo
+
+- Spin up locally is near instant
+- Switching to the namespace can be achived with a simple api command or 
+
+## But why do we even need a universal API layer
+
+- Service Providers should not be responsible to make things discoverable, the plattform should
+- The internal pülatform can be bought, customized or diyed but the api layer does not change -> Interchangeable backend switching
+- Kubernetes is already widespread and makes it easy to use different projects
+- Backed by the CNCF, flat learning curve

content/day2/_index.md

@@ -10,4 +10,5 @@ We also had some "normal" work tasks resulting in less talks visited and more "n
 
 ## Reccomended talks
 
-- Good speaker [Many Cooks, One Platform: Balancing Ownership and Contribution for the Perfect Broth](./04_many-cooks)
+- Good speaker: [Many Cooks, One Platform: Balancing Ownership and Contribution for the Perfect Broth](./04_many-cooks)
+- Good intro to kcp: [Building a Platform Engineering API Layer with KCP](05_kcp)