Nicolai Ort
46b06c66fd
All checks were successful
Build latest image / build-container (push) Successful in 49s
89 lines
2.5 KiB
Markdown
89 lines
2.5 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 %}} -->
|
|
<!-- {{% button href="https://docs.google.com/presentation/d/1nEK0CVC_yQgIDqwsdh-PRihB6dc9RyT-" style="tip" icon="person-chalkboard" %}}Slides{{% /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 |