docs(day0): Added abstractions

content/day0/10_abstractions.md

@@ -0,0 +1,88 @@
+---
+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,9 +9,11 @@ This year I spent most of my time at the platform engineering day.
 
 ## Talk recommendations
 
-- [So you want to hire for platform engineering](../06_hire-engineers)
+- How to design a good hireing process: [So you want to hire for platform engineering](../06_hire-engineers)
-- [The past, the present and the future of platform engineering](../07_past-present-future)
+- Evolution of Platforms and Platform Engineering: [The past, the present and the future of platform engineering](../07_past-present-future)
-- [Product thinking for cloud native engineers](../08_product-thinking)
+- How to design a good product: [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