kubecon25/content/day0/10_abstractions.md

75 lines
1.8 KiB
Markdown

---
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?