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

{{% button href="https://youtu.be/M5X5NCzlzIA" style="warning" icon="video" %}}Watch talk on YouTube{{% /button %}}
{{% button href="https://static.sched.com/hosted_files/colocatedeventseu2025/52/atul-talk-platform-engineering-kubecon-london-2025_final.pdf" 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

![Abstraction cycle illustration](../_img/abstraction-cycle.png)

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