Un simple fallo de software por descuido puede costar mucho dinero a una organización, pero eso puede evitarse con sencillos cambios en la arquitectura y el diseño. Esta nueva edición de «Libérelo» se publicó en enero de 2018. Ilustra cómo diseñar sistemas que funcionen durante más tiempo con fallos limitados y recuperar el control cuando las cosas van mal. Este libro es una guía imprescindible para la ingeniería de sistemas de producción.
¿CÓMO NOS HA AYUDADO ESTE LIBRO?
Este libro nos ayudó a evitar riesgos que cuestan mucho dinero a las empresas en tiempo de inactividad y reputación. El 80% del coste del ciclo de vida del producto está en la producción.
EL LIBRO EXPLICADO EN MENOS DE 60 SEGUNDOS
La versión actualizada de ¡Libérelo! Design and Deploy Production-Ready Software aborda la producción de sistemas modernos: sistemas grandes, complejos y fuertemente virtualizados. Incluye información sobre la ingeniería del caos, la disciplina de implementar actualizaciones sin tiempo de inactividad y la entrega continua, y cómo hacer que el software nativo de la nube sea robusto. Analiza los enfoques para la arquitectura, el diseño y la creación de sistemas distribuidos principalmente de software.
LAS TRES MEJORES CITAS
- «El diseño de software tal y como se enseña hoy en día es terriblemente incompleto. Sólo habla de lo que los sistemas deberían hacer. No aborda lo contrario: lo que los sistemas no deberían hacer. No deberían bloquearse, colgarse, perder datos, violar la privacidad, perder dinero, destruir su empresa o matar a sus clientes».
- «La mayoría de los probadores que he conocido son lo suficientemente perversos como para que si les dices que «el camino feliz» a través de la aplicación, eso es lo último que harán. Debería ocurrir lo mismo con las pruebas de carga».
- «Diseñe con escepticismo y logrará resiliencia».
RESÚMENES Y NOTAS DE LIBROS
Capítulo uno: Crear estabilidad
Cuando su software o base de datos se bloquee, cambie la ventana y pruebe algo nuevo. Puede conseguir que un ingeniero local le ayude a aplicar el cambio. Si cambia la base de datos, intente cambiar a un proveedor de servicios mejor. Puede empezar trasladando su información y datos de la antigua base de datos 1 a la nueva base de datos dos y, a continuación, actualizar la base de datos 1. Después de verificar la base de datos actualizada, traslade su información y datos a la base de datos 1.
Una mala estabilidad conlleva unos costes reales elevados. El precio aparente es una pérdida de ingresos. Una buena estabilidad no cuesta tanto. Cuando se construye la arquitectura, el diseño y la implementación menor del sistema, muchos puntos de decisión tienen gran influencia sobre la estabilidad del sistema. Un software muy estable suele costar lo mismo de implementar que uno inestable. Para hablar de estabilidad, hay que conocer las transacciones. Una transacción es una unidad abstracta de trabajo procesada por el sistema. Una transacción abarca muchas páginas y suele implicar integraciones externas como la verificación de tarjetas de crédito. Las transacciones son la razón de ser de un sistema. Un sistema puede procesar un tipo de transacción y dedicarse por completo a ella.
Las principales incertidumbres para la duración de su sistema son las fugas de datos y de memoria. Ambos peligros pueden acabar con su sistema durante la producción y rara vez se detectan durante las pruebas. Las pruebas visualizan los problemas para que pueda solucionarlos. Los problemas que surgen cuando su software está terminado son los que usted no probó. Por lo tanto, esos fallos se producirán cuando no pruebe los errores de falta de memoria en la aplicación.
Cita favorita del capítulo: «Diseñe con escepticismo y logrará resiliencia .»
Capítulo 2: Diseño para la producción
Las operaciones le llevan a diseñar teniendo en cuenta la producción examinando los fundamentos físicos del sistema: las máquinas y los cables sobre los que descansa todo. Resuelva algunas cuestiones relativas a las redes, los nombres de host y las direcciones IP. Cada despliegue tiene su propio conjunto de preocupaciones que los diseños de software deben tener en cuenta.
- Operaciones-Seguridad, capacidad, estado, comunicación, disponibilidad
- Plano de control-Despliegue, detección de anomalías, características, supervisión del sistema
- Interconexión-Routing, failover, gestión del tráfico, equilibrio de carga
- Instancias-Servicios, componentes, procesos, supervisión de instancias
- Fundación-Hardware, máquinas virtuales, red física, direcciones IP
La creación de redes en el centro de datos y en la nube requiere algo más que abrir un enchufe. Estas redes suelen absorber más redundancia y seguridad que las redes de escritorio. Cuando se añaden una o dos capas de virtualización, las aplicaciones y los servicios se comportan de forma más distinta a como lo hacen en los confines seguros del IDE. Requerirán un trabajo exhaustivo para comportarse con precisión en este entorno.
Una instancia es una instalación en una sola máquina (virtual o física) de un conjunto de carga equilibrada del mismo ejecutable. Las instancias individuales proporcionan transparencia, manejan la configuración correctamente, aceptan el control y gestionan las conexiones. Cada máquina requiere el código, la configuración y los enlaces de red correctos. Los desarrolladores suelen prestar atención al comportamiento de su código. Por eso disponen de grandes herramientas para construir, alojar y desplegar el código. Los desarrolladores deben ser capaces de construir un sistema, ejecutar pruebas e implementar al menos una parte del sistema localmente.
Las capas de interconexión abarcan todos los mecanismos que combinan un grupo de instancias en un sistema cohesionado, incluyendo la gestión del tráfico, el descubrimiento y el equilibrio de la carga. Es a través de las capas de interconexión como se puede crear una alta disponibilidad. Considere la solución adecuada para su organización cuando suba por la pila hacia la interconexión, el panel de control y las operaciones. Pocas técnicas de descubrimiento e innovación de servicios suelen depender de piezas de software suplementarias. Un equipo extenso con miles de servicios diminutos rinde bien cuando utiliza Consul o cualquier otro servicio dinámico. Además, el coste de funcionamiento de Consul se amortiza rápidamente. Para los equipos pequeños, la opción ideal en una infraestructura de cambio lento es DNS. Eso implicaría máquinas físicas comprometidas y máquinas virtuales dedicadas de larga duración. Las direcciones IP suelen permanecer estables para que el DNS sea conveniente.
Cita favorita del capítulo: «El equilibrio de la carga, el enrutamiento, el reparto de la carga y el descubrimiento de servicios son algunas de las cuestiones clave que hay que tener en cuenta al construir capas».
Capítulo 3: Entregue su sistema
No debe planificar sólo uno o unos pocos despliegues en las producciones, sino varios. Después de escribir, comprimir y enviar su software para el despliegue a las operaciones, añada notas de lanzamiento sobre cada nueva opción de configuración que deban establecer. Operaciones establecerá un cierto «tiempo de inactividad planificado» para ejecutar la liberación. La mayoría de las veces, se diseña el estado del sistema después de una liberación. El problema es que eso supone que todo el sistema puede cambiarse en algún salto cuántico instantáneo.
El código es un claro pasivo entre el momento en que se ejecuta el código en el repositorio y el momento en que se ejecuta en producción. El código no desplegado suele ser inventario. Tiene fallos no revelados y causa tiempos de inactividad en producción. Podría ser la implementación ideal de una característica que nadie quiere. El despliegue continuo minimiza el retraso entre la ejecución y la producción del código y la responsabilidad del código no desplegado.
Las bases de datos son el principal motivo de los «tiempos de inactividad planificados», sobre todo los cambios de esquema en las bases de datos relacionales. En lugar de implementar secuencias de comandos SQL sin procesar contra una CLI de administración, puede tener un control programático para hacer avanzar la versión de su esquema. Un marco de migración como Liquibase puede ayudarle a implementar cambios en el esquema. Sin embargo, no hace automáticamente que esos cambios sean compatibles hacia adelante y hacia atrás.
Cuando añada funciones a su aplicación, tenga cuidado de no consumir aplicaciones. Los distintos consumidores de su servicio tienen otros objetivos y necesidades. Cada aplicación consumidora tiene su equipo de desarrollo que funciona según su calendario. No puede obligar a los consumidores a ajustarse a su calendario de lanzamientos. Para realizar cambios compatibles en la API, tenga en cuenta qué hace que un cambio sea incompatible.
Cita favorita del capítulo: «Al mismo tiempo, tenía una profunda sensación de pérdida: todo ese tiempo en el ejército de despliegue. Todo ese potencial desperdiciado. La humanidad desperdiciada. Utilizando a las personas como si fueran robots. Perturbando vidas, familias, patrones de sueño… todo era un desperdicio».
Capítulo 4: Resolver problemas sistémicos
Las pruebas de carga suelen ser un proceso sin intervención. Especifique un plan de pruebas, genere algunos scripts, configure los generadores de carga y el despachador de pruebas, y ponga en marcha una prueba a lo largo de la noche. Una vez realizada la prueba, analice los datos recogidos durante la misma. Examine los resultados, realice cambios en la configuración y programe la siguiente ejecución de la prueba. Las pruebas de carga son tanto un arte como una ciencia. Es inimaginable replicar el tráfico real de producción, así que utilice el análisis del tráfico y la intuición para conseguir una simulación lo más cercana posible a la realidad.
El cambio está garantizado, pero la supervivencia no. El desarrollo ágil acepta el cambio como reacción a las condiciones empresariales. Sin embargo, es probable que la flecha apunte en la otra dirección. El cambio de software puede generar nuevos productos y mercados. Puede crear espacio para nuevas alianzas y nueva competencia, haciendo que la superficie entre negocios que solían estar en industrias diferentes. No todos los programas informáticos necesitan cambiar a diario. Algunas piezas de software no tienen potencial para el cambio y la adaptación rápidos. En algunas industrias, el cambio de software pasa por una certificación costosa y que requiere mucho tiempo. Si quiere enviar astronautas al espacio con un destornillador y un extractor de virutas, los costes de transacción son elevados.
Su empresa tiene que pasar por un ciclo de decisión para implantar un cambio. Alguien tiene que intuir que existe una necesidad, otro decidir que se ajustará perfectamente a esa necesidad y que merece la pena implementarlo. Después, alguien tiene que actuar y diseñar la función y ponerla en el mercado; por último, alguien tiene que ver si el cambio tiene el efecto esperado. En las pequeñas empresas, el proceso puede implicar a dos o tres personas. La comunicación es bastante rápida.
La ingeniería del caos se ocupa de sistemas distribuidos, normalmente sistemas a gran escala. Los entornos de puesta en escena o de control de calidad no son ideales para el comportamiento a gran escala de los sistemas de producción. Diferentes proporciones de instancias provocan comportamientos de salida cualitativamente diferentes, lo que también ocurre con el tráfico. Las redes congestionadas se comportan de forma cualitativamente diferente a las no congestionadas.
Cita favorita del capítulo: «La mayoría de los probadores que he conocido son lo suficientemente perversos como para que si les dices que «el camino feliz» a través de la aplicación, eso es lo último que harán. Debería ocurrir lo mismo con las pruebas de carga».
CÓMO PUEDE AYUDAR ESTE LIBRO A LOS DESARROLLADORES DE SOFTWARE
«¡Libérelo!», de Michael T. Nygard, es una guía práctica que ayuda a los desarrolladores de software a diseñar, desarrollar e implantar software listo para la producción. El libro proporciona ejemplos del mundo real y estudios de casos, destacando los escollos más comunes y ofreciendo soluciones para evitarlos. El libro ofrece consejos y técnicas para identificar y solucionar problemas antes de la implantación, como la gestión de dependencias, las pruebas y la supervisión. Abarca temas como la optimización del rendimiento, la escalabilidad, la tolerancia a fallos, la supervisión y el registro, centrándose en la creación de software que pueda sobrevivir a los rigores de la producción. Siguiendo las directrices del libro, los desarrolladores de software pueden crear sistemas fiables y resistentes que satisfagan las demandas de sus usuarios y clientes. En general, este libro es un recurso esencial para los desarrolladores que buscan mejorar la calidad y el rendimiento de su software en el entorno de producción.
