Reversible Engineering
Reverting Time for Fun and Profit
Your Host Today
Alex Fernández
Physicist by education
Software engineer by trade
Ground to Cover
Reversibility and Irreversibility
Software Development
Software Architecture
DevOps
Decision Making
First, What Not to Expect
Not reversible computing
Not reverse engineering
Not thermodynamics
nor information theory
Not hard-core science
Reversibility
and Irreversibility
Entropy is not...
heat
energy
chaos
disorder
irreversibility
uncertainty
degradation
complexity
Reversibility
Want to know what "entropy" is?
Who cares, just worry about reversibility!
A reversible system:
- always has minimum entropy
- has the most efficient process
- minimizes complexity
The Reversible Process
Is the most efficient process
Can be reversed in time
using no extra energy
Can work in either direction
Takes the system back to its initial state
with no side effects
Example: a Perfect Pendulum
Always near the stable point
Problems of Thermodynamic Reversibility
The process must be infinitely slow
Cannot have side effects:
no way to know it has happened
Oh and by the way:
it is impossible in the real world
Some Ideas about Reversibility
Efficiency
Stability
Predictability
Slowness
Irreversibility
Is inefficient (but necessary)
The
other Reversible
Process
Can be reversed in time
(at least for our system)
Can work in either direction
Takes the system back to its initial state
with some side effects
Uses an efficient process
Example: Management Application
CRUD:
- Create
- Read
- Update
- Delete
Create ↔ Delete
Update
Read
Example: Testing a CRUD App
- First create a random key
- Create a record
- Read the record
- Then modify the record
- Read the record again
- Finally delete the record
- Verify that the record is deleted
Self-contained test: leaves the system intact
But the tests have side effects
The World is Irreversible
Deal with it
Some Ideas about IrReversibility
Speed
Turbulence
Chaos
Complexity
Reversible
Development
The Reversible Machine
Works in cycles
Each cycle costs some effort
Each cycle can be reversed
at a small cost
Small cycles are better than big cycles
An Analogy
Example: Version Control
CVS stores changes in a log file
SVN stores revisions as diffs
Git stores history in deltas
Easy to go back to any previous HEAD
Easy to revert a previous commit
Easy to truncate history and reset
Example: Undo
GUI application with commands
Each command can be undone
... and redone
Much easier to try out changes
The Development Process
Small cycles of write-compile-link-run
Bigger cycles of write-test-debug-fix
Large cycles of write-integrate-deploy
The smaller the cycle, the most efficient the process
Reversible
Architecture
The Stateless API
Every request is self-contained
No context is stored in the server
The client maintains the state of the client
Can be parallelized
The Stateless Server
Does not hold any state in memory
(except for cached data)
Can be reset at will
All information is dumped on external systems
(and in log files)
A Small Detour
Pile your heat onto an exhaust!
Information is Entropy
Information is not “negative entropy”
Entropy is the same as information!
Pile your information onto an “exhaust”
Information exhausts:
- databases
- files
Two Tier Architecture
Information exhaust in database
(and in log files)
API Evolution
Avoid breaking existing APIs
Please don't
Keep backwards compatibility
... and forwards compatibility!
Warn about deprecated functions
OK to remove if there are no users
What is missing
More compatibility shims
Forwards-backwards compatibility
Example: Python 2.x → 3.x migration
and 3.x → 2.x migration!
Reversible
Operations
Another view of reversibility
The reversible process is always at equilibrium
Testing Equilibrium
System is stable when it passes the tests
Testing
Don't let your system stray from equilibrium
It is much harder to get it back on track
Do your development in small steps
Pass your test suites often
Integration Environment
After integration should go back to its initial state
Should be repeatable
Ideal environment: created ad hoc
and then destroyed
like Travis-CI
Snapshots
Disk snapshots
OS snapshots
Cloud: ubiquitous snapshots
Allow immediate rollbacks to previous states
What is missing
Differential snapshots
Roll back one feature while keeping another
E.g.: rollback OS, keep applications
Version control for configuration files
Continuous Deployment
Put your code in production
Deploy in small increments
Immediate rollbacks
Automatic rollbacks
What Is Missing
Make it easier to go to a previous time
and then to go forward again!
Automatic rollbacks should be easier
and ubiquitous
Dark Deployment
Cycle is made of two parts
First deploy inactive code
Then activate feature
Both parts are reversible
Reversible
Management
Heroic efforts
... are irreversible by nature
A repeatable process can approach reversibility
Typical Management View
Lots of irreversible steps
Closed tasks are not revisited
Timeboxed Releases
Features are released only when ready
Tasks can be reopened if needed
and it is not a failure!
Features can be perfected
Releases focus on improvements
Release Process
Small releases better than big changes
E.g.: Linux 2.4.x -> 2.6.x: big ugly change
Linux 2.6.x -> 3.x: continuous improvement
Avoid releases if at all possible
Rolling releases are the best!
Making Decisions
Thus the key to avoiding big decisions becomes to just avoiding to do things that can’t be undone. Don’t get ushered into a corner from which you cannot escape. A cornered rat may be dangerous - a cornered manager is just pitiful.
Thanks!
https://slid.es/alexfernandez/reversible-engineering
All pictures from Wikimedia Foundation
published under CC license