In an ever-so-fast technological world, Technical Debt can be a project breaker. But it doesn’t have to be a fatality. What if the solution was not to run, but instead go steadily towards a well-known goal? In this talk, I will show how Standards & Loose Coupling can help limit technical debt.

1. DevopsDays Medellín 2022
Julio 30 al 31, 2022
The Tortoise and the Hare
Open Source, Standards & Technical Debt
Raphaël Pinson | @raphink
Solutions Architect, Isovalent

2. Who am I
Raphaël Pinson
Solutions Architect @ Isovalent

3. The Tortoise & the Hare
Coupling & Immutability
Betting on the right Horse
Technical Debt
Haste vs Speed
Standards & Stability
Open Source, Standards & Technical Debt
Debt Dilution & Delegation

4. Technical Debt
Hard to monitor
Time to pay
- Evolves slowly from many small decisions
- Can go unnoticed for a long time
You might only realize debt when it’s time to pay
Technical decisions imply a hidden cost that will have to be
paid in the future in order to catch up with state-of-the-art
technology.

5. Time to pay!

6. Standards
Lagging behind standards
My wheel is better than yours
Not Invented Here Syndrome
Keeping systems in place abiding to old standards

7. Open Source & Standards
Follow vs Influence
Avoid NIH by setting industry standards
When faced with a need:
- already existing?
- valid?
- implement
Most people have the same needs
New standard ⇒ public
- Stay ahead of the curve
- Set the new standard!

8. Coupling
Hard coupling / Monolith
Loose coupling / Microservices
- Monolithic systems are strongly coupled and hard to update.
- Their technical debt is also strongly coupled.
- Loose API between components
- Decorrelation of dependencies
- Distributes technical debt
Image:
Wikimedia
Commons
—
LuK
USA
LLC
/
Michael
Poehler
—
CC
BY
3.0

9. Immutability
Immutability encourages loose coupling
- No evolution of state (full replacement)
- Requires frequent changes
- Distributes technical debt (horizontally or vertically)
- VMs vs Containers vs Functions
Mutable systems
- State evolves with time
- Divergence vs Convergence vs Congruence

10. Public Cloud
Delegation of Technical Debt
One way to reduce debt
(at least its ownership)
⚠ Strong dependency on
Cloud APIs/features
Image:
Unsplash
—
Billy
Huynh
- local optimum
- global debt

11. Team Topologies
Conway’s Law
Code debt/ownership
Debt Dilution
Plan systems architecture, adapt teams
Ensure responsibility of debt management
and reduction
Distribute debt and associated mental
load between teams
Image:
XKCD

12. More Haste, less Speed

13. The Three Ways of DevOps
Flow / Systems Thinking
Amplify Feedback Loops
Culture of Continual Experimentation
& Learning
Decoupling software architecture from infrastructure lowers
risks of technical debt.
Involving Ops in architecture (+ feedback) helps lower coupling.
Definitely a tortoise approach to a race.

14. Betting on the right Horse

15. The right time to adopt
Image:
Craig
Chelius
—
CC
BY
3.0

16. Stability & Loose Coupling
Image:
Wikimedia
Commons
—
Emw
—
CC
BY-SA
3.0
Stability
- Standard interface
- Few changes in time
Loose Coupling
- Partial upgrades
- Delegation of Tech debt
- Configuration changes

17. eBPF
Highly efficient sandboxed virtual machine in the kernel,
making it more programmable at native execution speed.
Stability
eBPF is based on the OS (mainly Linux) kernel interface
Loose Coupling
eBPF can enhance application without specific instrumentation:
- observability
- security
- network
- tracing & profiling

18. eBPF Projects

19. Cilium & Friends
Cilium
- performance gains
(no need for iptables, bypass TCP/IP)
- simpler architecture
(e.g. no sidecar proxy for Service Mesh)
Tetragon
- observe & export kernel events
- act on events (e.g. SIGKILL)
Hubble
- fine-grained network observability
- exports to SIEM
- support for OpenTelemetry

20. eBPF resources
eCHO
eBPF YouTube podcast:
https://www.youtube.com/channel/UCJFUxkVQTBJh3LD1wYB
WvuQ
eBPF & Cilium Slack
http://slack.cilium.io/
eCHO News
Bi-weekly eBPF newsletter:
https://cilium.io/newsletter/

21. It’s not the speed
that matters,
it’s the direction.

22. Thank you!