content/day0/10_abstractions.md

@@ -1,88 +0,0 @@
----
-title: "Platform abstractions: Asset or liability"
-weight: 10
-tags:
- - platform
- - cloudnativecon
----
-
-<!-- {{% button href="https://youtu.be/rkteV6Mzjfs" style="warning" icon="video" %}}Watch talk on YouTube{{% /button %}} -->
-
-Fair warning: Food analogies incoming
-
-## Baseline
-
-### What do abstractions achive
-
-- Structure through simplification
-- Complexity made simple
-- Hiden Details, visible value
-
-### Dilemma
-
-1. Platform team creates abstraction
-2. Abstraction works for 10 Teams
-3. Other team requests extension
-4. Question: How do we deal with this
-
-### Possible Solutions
-
-- Add Config Options: Increases complexity of abstraction
-- Make One-off exceptions: Breaks standardization, introduces inconsistency
-- Require conformity: Hinders innovation, creates enemies
-- Allow bypassing: Creates shadow it, risking security and resource control
-
-=> Debt trap: The cost of maintaining a stable platform rises and rises
-
-## The debt cycle
-
-### The abstraction cycle
-
-1. Simplify
-2. Adobt
-3. New Requirements
-4. Add complexity
-5. Repeat
-
-TODO: Steal image
-
-### Warning signs
-
-- Rizing customization requests
-- Workarounds
-- Shadow IT
-
-### Impact
-
-- Each new feature becomes harder to implement
-- Teams lose trust in the platform capabilities
-- Platform evolutions slows down
-- New tech is difficult to incorporate
-
-## Abstraction elacity
-
-> The abstraction should stretch a bit to accommodate change without brakuing
-
-- Adaptability: Ease of handling new requirements
-- Transparency: Understand what your user wants and why
-- Extension PAtterns: Document ways to customize the platform behavior
-- Migration Paths: Ease of moving away from the platform abstraction
-
-### Elasticity
-
-- Can teams access lower level controls (when needed) while staying with the abstraction
-- Do users understand what happens underneath (when needed)
-- Are ther documented extension/customization points?
-
-## Patterns to break the debt trap
-
-- Layered abstraction patterns: start with low-level abstractions that get abstracted on higher levels to allow users to choose the right abstraction level for themselves without having to configure everything themselfes
-- Expert-ap: Additional api parameters that are not needed but can be set
-- Policy based guard rails: Change the guardrails based on the environment (e.g. deep access in dev, not in prod)
-
-## The end goal
-
-- Increase adoption
-- Eliminate shadow IT
-- Improved satisfaction
-- Reduced overhead

content/day0/_index.md

@@ -9,11 +9,9 @@ This year I spent most of my time at the platform engineering day.
 
 ## Talk recommendations
 
-- How to design a good hireing process: [So you want to hire for platform engineering](../06_hire-engineers)
+- [So you want to hire for platform engineering](../06_hire-engineers)
-- Evolution of Platforms and Platform Engineering: [The past, the present and the future of platform engineering](../07_past-present-future)
+- [The past, the present and the future of platform engineering](../07_past-present-future)
-- How to design a good product: [Product thinking for cloud native engineers](../08_product-thinking)
+- [Product thinking for cloud native engineers](../08_product-thinking)
-- Staging with gitops: [A million ways to promote changes between environments](../09_promotions)
-- How to handle abstractions and new requriements: [Platform abstractions: Asset or liability](../10_abstractions)
 
 ## Other stuff I learned or people i talk to