2.8 KiB
2.8 KiB
title, weight, tags
| title | weight | tags | ||
|---|---|---|---|---|
| What going cloud native taught us about developer experience | 7 |
|
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
- Start of jurney: Usually a transition towards the cloud with some kubernetes and deployment templates and less legacy stuff
- Result:
- Implementation: Gigantic base manifests with maybe sume overlay abstraction (kustomize or helm)
- Expectation: Works in all environments
- 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
- 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