Reversible Engineering

Reverting Time for Fun and Profit

Your Host Today

Alex Fernández

Physicist by education

Software engineer by trade

@pinchito, alexfernandez, alejandrofer

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

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

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.

Linus Torvalds

Thanks!

https://slid.es/alexfernandez/reversible-engineering

All pictures from Wikimedia Foundation

published under CC license

¿Questions?