---
title: What going cloud native taught us about developer experience
weight: 7
tags:
 - devex
 - dx
---

<!-- {{% 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 %}} -->

## History/Base on-prem

- Monolith
- High autonomy regarding releases into prod (auto gen)
- Comfort features -> It just works™

## Goals

- Microservices
- Accelerated processes
- Better dev experiences

## The road

### Expectations

- Expected new work for developers: CI/CD, GitOps, Monitoring, Security, Resilience, Connect to other services
- New for developers: Kubernetes with a bunch of surrounding tech

### Journey

1. Start of jurney: Usually a transition towards the cloud with some kubernetes and deployment templates and less legacy stuff
2. Result:
    - Implementation: Gigantic base manifests with maybe sume overlay abstraction (kustomize or helm)
    - Expectation: Works in all environments
3. Considerations:
    - Developers will change config (its only a question of when and not if)
    - The migration from an env file to kubernetes compliant yaml can be a hard one
4. Iteration: The developer friendly config is our new goal

### The developer friendly config

> e.g. in a helm values file

- Easy to understand and configure
- Think about the dev experience (sane defaults)
- Allow templating
- Provide documentation

## Developer centric approach to cloud native

> There are not many technical problems in cloud native, most are experience related

### Remember

- Your users won't react the way you expect them to
- The plattform sould serve the need of your users, not the other way around
- Users will come to you, if you build a nice environment for them

### What do your users need

- Every service is like it's own area -> What connections does it need to the outside and how do i ensure it's health
- Reduced cognitive load: Avoid developers being occupied with foundational work instead of delivering value
- The new env needs to be as nice or nicer than the old env

### How to help them

- Bootstrapping: Define blueprints (including dependency services line databases) and automate stuff with defined goals (my service should be deployed 5 mins after bootstrapping)
- Tooling: Backstage (yay)
- Establish training programms and communities

## Wrap up

- Interfaces are important
- Ensure roads to your service are well maintained and documented
- Build standards and contracts to ensure that others can rely on your service
- Build a example project that is not too big, but tackels real-world challenges
- Remember that developers are used to the old way of working which has a bunch of creature comforts