Ingeniería reversible
Revirtiendo los efectos del tiempo
Vuestro anfitrion
Alex Fernández
Físico de carrera
Ingeniero de software de profesión
Vamos a ver
hoy
Reversibilidad e irreversibilidad
Desarrollo de software
Arquitectura de software
DevOps
Gestión y toma de decisiones
Primero, lo que
no vamos a ver
Ni computación reversible
Ni ingeniería inversa
Ni termodinámica
ni teoría de (la) información
No es ciencia dura sino ingeniería
Reversibilidad
E irreversibilidad
La entropía no es...
calor
energía
caos
desorden
irreversibilidad
incertidumbre
degradación
complejidad
Reversibilidad
¿Quieres saber lo que es la "entropía"?
¡A quién le importa, hablemos de reversibilidad!
Un sistema reversible:
- siempre tiene entropía mínima
- es el proceso más eficiente
- minimiza la complejidad
El proceso Reversible
Es el proceso más eficiente
Puede revertirse en el tiempo
sin usar energía extra
Funciona en ambas direcciones
Lleva al sistema a su estado inicial
sin efectos colaterales
Ejemplo: un péndulo perfecto
Siempre cerca del punto estable
Problemas de la reversibilidad termodinámica
El proceso debe ser infinitamente lento
No puede tener efectos colaterales:
¿cómo sabemos que ha ocurrido?
Ah, y ya puestos:
es imposible en el mundo real
Algunas Ideas sobre Reversibilidad
Eficiencia
Estabilidad
Predecibilidad
Lentitud
Irreversibilidad
Ineficiencia necesaria
El proceso irrreversible
No puede revertirse en el tiempo
Sólo funciona en una dirección
Es imposible llevar al sistema al estado inicial
Tiene pérdidas y disipación:
es ineficiente
El mundo es irreversible
¡Y es más divertido así!
Algunas Ideas sobre IrReversibilidad
Velocidad
Turbulencia
Caos
Complejidad
Desarrollo
Reversible
Ejemplo: aplicación de gestión
Operaciones básicas:
- Alta
- Baja
- Modificación
- Consulta
Alta ↔ Baja
Modificación
Consulta
Ejemplo: Probando una apl de gestión
- Crea una clave aleatoria
- Crea un registro
- Lee el registro
- Ahora modifica el registro
- Lee el registro otra vez
- Por fin borra el registro
- Verifica que el registro no se lee
Tests autocontenidos: dejan el sistema intacto
Pero con efectos colaterales (log, consola)
El otro proceso reversible
Puede revertirse en el tiempo
(al menos para nuestro sistema)
Puede funcionar en ambas direcciones
(con una fuente de energía)
Lleva al sistema de vuelta a su estado inicial
(con efectos colaterales)
Usa un proceso ineficiente
La máquina reversible
Trabaja en ciclos
Cada ciclo cuesta un poco de esfuerzo
Cada ciclo puede revertirse
a un coste pequeño
Los ciclos pequeños son mejores que los grandes
La escalera reversible
Analogía cutre
Ejemplo: control de Versiones
CVS guarda los cambios en un fichero de log
SVN guarda las revisiones como diffs
Git almacena la historia en deltas
Fácil volver al HEAD previo
Fácil revertir un commit previo
Fácil truncar la historia y resetear
¿Qué nos falta?
Volver a un punto arbitrario del pasado
¡fácilmente!
Snapshots automáticos
Cruces de ramas
Example: deshacer
Aplicación visual con comandos
Cada comando puede deshacerse
... y rehacerse
Mucho más fácil probar distintos cambios
El proceso de desarrollo
Pequeños ciclos de escribir-compilar-enlazar-correr
Ciclos más grandes de escribir-probar-depurar-corregir
Ciclos enormes de escribir-integrar-desplegar
Cuanto más pequeño el ciclo, más eficiente el proceso
¿Qué nos falta?
Reducir el ciclo: escribir-compilar-enlazar-correr
Reducir el ciclo: escribir-probar-depurar-corregir
Reducir el ciclo: escribir-integrar-desplegar
Graba y despliega sólo si compila y pasa pruebas
Arquitectura
Reversible
La API sin estado (Stateless)
Todas las peticiones son autocontenidas
El servidor no tiene contexto
El cliente mantiene su propio estado
Puede paralelizarse
El servidor sin estado
No guarda estado en memoria
(excepto datos cacheados)
Puede resetearse a voluntad
Toda la información se vuelca en sistemas externos
(y en ficheros de log)
Evolución de una API
Evita romper las APIs existentes
Porfa porfa plís
Mantén la compatibilidad hacia atrás
... ¡y hacia delante!
Avisa sobre funciones deprecadas
Sólo se pueden eliminar las funciones sin usuarios
Un pequeño desvío
¡Expulsa tu calor extra por el escape!
La información es entropía
La información no es “entropía negativa”
¡La entropía es lo mismo que la información!
Expulsa tu información sobrante por un “escape”
a un “reservorio”
Reservorios de información:
- bases de datos
- ficheros
Ejemplo: Arquitectura de dos capas
Reservorio de información en base de datos
(y en ficheros de log)
¿Qué falta?
Más capas de compatibilidad
Compatibilidad hacia delante y hacia atrás
Ejemplo: Migración de Python 2.x → 3.x
¡y migración 3.x → 2.x!
DevOps
y Reversibilidad
Entorno de Integración
Tras la integración, deberíamos volver al estado inicial
Debería ser un proceso repetible
Entorno ideal: creado ad hoc
y luego destruído (como Travis-CI)
nueva versión de la reversibilidad
El proceso reversible está siempre en equilibrio
Equilibrio de los tests
El sistema está estable cuando pasa todos los tests
Pruebas
No dejes que tu sistema se aleje del equilibrio
Es mucho más difícil volver al camino
Haz tu desarrollo en pasos pequeños
Pasa las suites de pruebas a menudo
y corrige los fallos antes de seguir
Snapshots
Snapshots de disco
Snapshots del sistema operativo
En la nube: snapshots en todas partes
Permiten un rollback inmediato a estados previos
¿Qué nos falta?
Snapshots diferenciales
Vuelve atraś una parte manteniendo el resto
Ejemplo: revertir el sistema operativo, mantener aplicaciones
Control de versiones para ficheros de configuración
Despliegue
Pon tu código en producción
Despliegue continuo
Pon tu código en producción
Despliega en incrementos pequeños
Rollbacks inmediatos
Rollbacks automáticos
¿Qué nos falta?
Hacer que sea fácil volver a un momento previo
¡y volver hacia delante de nuevo!
Los rollbacks automáticos deberían ser sencillos
y ubicuos
Reducir los ciclos de despliegue aún más
hasta tiempo real (en según qué entornos)
Despliegue oscuro
Ciclo de dos fases
Primero despliega el código inactivo
Luego activa la funcionalidad
Ambas partes son reversibles
GEstión
Reversible
Típica visión de la gerencia
Muchos pasos irreversibles
Las tareas cerradas no se pueden revisitar
Trello es cool (y reversible)
Las tareas se pueden reabrir sin dramas
Los esfuerzos heroicos
... son irreversibles por naturaleza
Un proceso repetible está más cerca de la reversibilidad
Versiones temporales (Timeboxed)
Las funcionalidades se liberan sólo cuando están listas
Las tareas pueden reabrirse si hace falta
¡y no es un drama!
Las funcionalidades pueden mejorarse
Las versiones están orientadas a la mejora
Proceso de liberación (release)
Las releases pequeñas son mejores que las grandes
Ejemplo: Linux 2.4.x -> 2.6.x: cambio grande y peludo
Linux 2.6.x -> 3.x: mejora continua
Evita las releases si puedes
¡Las “rolling releases” son la mejor opción!
Toma de decisiones
Así que la clave para evitar las grandes decisiones es evitar hacer cosas que no tienen remedio. No dejes que te arrinconen sin escapatoria posible. Una rata arrinconada puede ser peligrosa -- un manager arrinconado es patético.
¡Gracias!
