niggl/kubecon25
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
kubecon25/content/day0/10_abstractions.md
Nicolai Ort 46b06c66fd
All checks were successful
Build latest image / build-container (push) Successful in 49s
Details
docs: Added slides button to all pages
2025-04-02 13:21:27 +02:00

2.5 KiB
Raw Blame History

title, weight, tags
title weight tags
Platform abstractions: Asset or liability 10
platform
cloudnativecon

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