docs(day0): Added talks
This commit is contained in:
parent
d90d5b8eab
commit
c09bf8f637
75
content/day0/10_abstractions.md
Normal file
75
content/day0/10_abstractions.md
Normal file
@ -0,0 +1,75 @@
|
||||
---
|
||||
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?
|
@ -12,6 +12,7 @@ This year I spent most of my time at the platform engineering day.
|
||||
- [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)
|
||||
- [Product thinking for cloud native engineers](../08_product-thinking)
|
||||
- [A million ways to promote changes between environments](../09_promotions)
|
||||
|
||||
## Other stuff I learned or people i talk to
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user