linter run

content/day1/02_sometimes_lipstick_is_what_a_pig_needs.md

@@ -27,7 +27,7 @@ The main topic of this talk is: What interface do we choose for what capability.
 
 * Autonomy: external dependency (low) <->  self-service (high)
   * low: Ticket system -> But sometimes good for getting an expert
-  * high: Portal -> Nice, but somethimes we just need a 
+  * high: Portal -> Nice, but somethimes we just need a human contact
 * Contextual distance: stay in the same tool (low) <-> switch tools (high)
   * low: IDE plugin -> High potential friction if stuff goes wrong/complex (context switch needed)
   * high: Wiki or ticketing system

content/day1/03_beyond_platform_thinking.md

@@ -68,4 +68,4 @@ Presented by the implementers at Thoughtworks (TW).
 ## Q&A
 
 * Your teams are pretty autonomus -> What to do with more classic teams: Over a multi-year jurney every team settles on the ownership and selfservice approach
-* How to teams get access to stages: They just get temselves a stage namespace, attach to ingress and have fun (admission handles the rest)
+* How to teams get access to stages: They just get temselves a stage namespace, attach to ingress and have fun (admission handles the rest)

content/day1/04_user_friendsly_devplatform.md

@@ -9,16 +9,14 @@ tags:
 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
+* Customer feedback

content/day1/05_multitennancy.md

@@ -34,7 +34,7 @@ Part of the Multitannancy Con presented by Adobe
 
 * 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 
+* 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
@@ -42,4 +42,4 @@ Part of the Multitannancy Con presented by Adobe
 
 ## Conclusion
 
-* There is a balance between cost, customization, setup and security between single-tenant und multi-tenant
+* There is a balance between cost, customization, setup and security between single-tenant und multi-tenant

content/day1/09_serverless.md

@@ -39,4 +39,4 @@ weight: 9
 * Resulting needs
   * Cluster aaS (using crossplane - in this case using aws)
   * DBaaS (using crossplane - again usig pq on aws)
-  * App aaS
+  * App aaS

content/day1/10_lessons_learned_from_building_a_db_operator.md

@@ -31,4 +31,4 @@ Another talk as part of the Data On Kubernetes Day.
 ## Pitfalls
 
 * Storage: Agnostic, Topology aware, configureable and resizeable (can't be done with statefulset)
-* Networking: Cluster-internal (Pod to Pod/Service), External (Split horizon over multicluster)
+* Networking: Cluster-internal (Pod to Pod/Service), External (Split horizon over multicluster)