![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-lukas-928199-1024x678.jpg\")
<\/figure>\n\nEste libro nos ayud\u00f3 a evitar riesgos que cuestan mucho dinero a las empresas en tiempo de inactividad y reputaci\u00f3n. El 80% del coste del ciclo de vida del producto est\u00e1 en la producci\u00f3n. <\/p>\n\n
EL LIBRO EXPLICADO EN MENOS DE 60 SEGUNDOS<\/strong><\/p>\n\n La versi\u00f3n actualizada de \u00a1Lib\u00e9relo! Design and Deploy Production-Ready Software aborda la producci\u00f3n de sistemas modernos: sistemas grandes, complejos y fuertemente virtualizados. Incluye informaci\u00f3n sobre la ingenier\u00eda del caos, la disciplina de implementar actualizaciones sin tiempo de inactividad y la entrega continua, y c\u00f3mo hacer que el software nativo de la nube sea robusto. Analiza los enfoques para la arquitectura, el dise\u00f1o y la creaci\u00f3n de sistemas distribuidos principalmente de software. <\/p>\n\n LAS TRES MEJORES CITAS<\/strong><\/p>\n\n RES\u00daMENES Y NOTAS DE LIBROS<\/strong><\/p>\n\n Cap\u00edtulo uno: Crear estabilidad<\/strong><\/p>\n\n 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\u00f3n y datos de la antigua base de datos 1 a la nueva base de datos dos y, a continuaci\u00f3n, actualizar la base de datos 1. Despu\u00e9s de verificar la base de datos actualizada, traslade su informaci\u00f3n y datos a la base de datos 1. <\/p>\n\n Una mala estabilidad conlleva unos costes reales elevados. El precio aparente es una p\u00e9rdida de ingresos. Una buena estabilidad no cuesta tanto. Cuando se construye la arquitectura, el dise\u00f1o y la implementaci\u00f3n menor del sistema, muchos puntos de decisi\u00f3n 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\u00f3n es una unidad abstracta de trabajo procesada por el sistema. Una transacci\u00f3n abarca muchas p\u00e1ginas y suele implicar integraciones externas como la verificaci\u00f3n de tarjetas de cr\u00e9dito. Las transacciones son la raz\u00f3n de ser de un sistema. Un sistema puede procesar un tipo de transacci\u00f3n y dedicarse por completo a ella. <\/p>\n\n Las principales incertidumbres para la duraci\u00f3n de su sistema son las fugas de datos y de memoria. Ambos peligros pueden acabar con su sistema durante la producci\u00f3n 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\u00e1 terminado son los que usted no prob\u00f3. Por lo tanto, esos fallos se producir\u00e1n cuando no pruebe los errores de falta de memoria en la aplicaci\u00f3n. <\/p>\n\n \n Cita favorita del cap\u00edtulo: \u00abDise\u00f1e con escepticismo y lograr\u00e1 resiliencia<\/em>\n<\/strong>.\u00bb<\/p>\n\n Cap\u00edtulo 2: Dise\u00f1o para la producci\u00f3n<\/strong><\/p>\n\n Las operaciones le llevan a dise\u00f1ar teniendo en cuenta la producci\u00f3n examinando los fundamentos f\u00edsicos del sistema: las m\u00e1quinas 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\u00f1os de software deben tener en cuenta. <\/p>\n\n La creaci\u00f3n de redes en el centro de datos y en la nube requiere algo m\u00e1s que abrir un enchufe. Estas redes suelen absorber m\u00e1s redundancia y seguridad que las redes de escritorio. Cuando se a\u00f1aden una o dos capas de virtualizaci\u00f3n, las aplicaciones y los servicios se comportan de forma m\u00e1s distinta a como lo hacen en los confines seguros del IDE. Requerir\u00e1n un trabajo exhaustivo para comportarse con precisi\u00f3n en este entorno. <\/p>\n\n Una instancia es una instalaci\u00f3n en una sola m\u00e1quina (virtual o f\u00edsica) de un conjunto de carga equilibrada del mismo ejecutable. Las instancias individuales proporcionan transparencia, manejan la configuraci\u00f3n correctamente, aceptan el control y gestionan las conexiones. Cada m\u00e1quina requiere el c\u00f3digo, la configuraci\u00f3n y los enlaces de red correctos. Los desarrolladores suelen prestar atenci\u00f3n al comportamiento de su c\u00f3digo. Por eso disponen de grandes herramientas para construir, alojar y desplegar el c\u00f3digo. Los desarrolladores deben ser capaces de construir un sistema, ejecutar pruebas e implementar al menos una parte del sistema localmente. <\/p>\n\n Las capas de interconexi\u00f3n abarcan todos los mecanismos que combinan un grupo de instancias en un sistema cohesionado, incluyendo la gesti\u00f3n del tr\u00e1fico, el descubrimiento y el equilibrio de la carga. Es a trav\u00e9s de las capas de interconexi\u00f3n como se puede crear una alta disponibilidad. Considere la soluci\u00f3n adecuada para su organizaci\u00f3n cuando suba por la pila hacia la interconexi\u00f3n, el panel de control y las operaciones. Pocas t\u00e9cnicas de descubrimiento e innovaci\u00f3n 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\u00e1mico. Adem\u00e1s, el coste de funcionamiento de Consul se amortiza r\u00e1pidamente. Para los equipos peque\u00f1os, la opci\u00f3n ideal en una infraestructura de cambio lento es DNS. Eso implicar\u00eda m\u00e1quinas f\u00edsicas comprometidas y m\u00e1quinas virtuales dedicadas de larga duraci\u00f3n. Las direcciones IP suelen permanecer estables para que el DNS sea conveniente. <\/p>\n\n Cita favorita del cap\u00edtulo: \u00abEl 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\u00bb.<\/em><\/strong><\/p>\n\n Cap\u00edtulo 3: Entregue su sistema<\/strong><\/p>\n\n No debe planificar s\u00f3lo uno o unos pocos despliegues en las producciones, sino varios. Despu\u00e9s de escribir, comprimir y enviar su software para el despliegue a las operaciones, a\u00f1ada notas de lanzamiento sobre cada nueva opci\u00f3n de configuraci\u00f3n que deban establecer. Operaciones establecer\u00e1 un cierto \u00abtiempo de inactividad planificado\u00bb para ejecutar la liberaci\u00f3n. La mayor\u00eda de las veces, se dise\u00f1a el estado del sistema despu\u00e9s de una liberaci\u00f3n. El problema es que eso supone que todo el sistema puede cambiarse en alg\u00fan salto cu\u00e1ntico instant\u00e1neo. <\/p>\n\n El c\u00f3digo es un claro pasivo entre el momento en que se ejecuta el c\u00f3digo en el repositorio y el momento en que se ejecuta en producci\u00f3n. El c\u00f3digo no desplegado suele ser inventario. Tiene fallos no revelados y causa tiempos de inactividad en producci\u00f3n. Podr\u00eda ser la implementaci\u00f3n ideal de una caracter\u00edstica que nadie quiere. El despliegue continuo minimiza el retraso entre la ejecuci\u00f3n y la producci\u00f3n del c\u00f3digo y la responsabilidad del c\u00f3digo no desplegado. <\/p>\n\n Las bases de datos son el principal motivo de los \u00abtiempos de inactividad planificados\u00bb, 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\u00f3n, puede tener un control program\u00e1tico para hacer avanzar la versi\u00f3n de su esquema. Un marco de migraci\u00f3n como Liquibase puede ayudarle a implementar cambios en el esquema. Sin embargo, no hace autom\u00e1ticamente que esos cambios sean compatibles hacia adelante y hacia atr\u00e1s. <\/p>\n\n Cuando a\u00f1ada funciones a su aplicaci\u00f3n, tenga cuidado de no consumir aplicaciones. Los distintos consumidores de su servicio tienen otros objetivos y necesidades. Cada aplicaci\u00f3n consumidora tiene su equipo de desarrollo que funciona seg\u00fan 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\u00e9 hace que un cambio sea incompatible. <\/p>\n\n Cita favorita del cap\u00edtulo: \u00abAl mismo tiempo, ten\u00eda una profunda sensaci\u00f3n de p\u00e9rdida: todo ese tiempo en el ej\u00e9rcito de despliegue. Todo ese potencial desperdiciado. La humanidad desperdiciada. Utilizando a las personas como si fueran robots. Perturbando vidas, familias, patrones de sue\u00f1o… todo era un desperdicio\u00bb.<\/em><\/strong><\/p>\n\n Cap\u00edtulo 4: Resolver problemas sist\u00e9micos<\/strong><\/p>\n\n Las pruebas de carga suelen ser un proceso sin intervenci\u00f3n. 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\u00f3n y programe la siguiente ejecuci\u00f3n de la prueba. Las pruebas de carga son tanto un arte como una ciencia. Es inimaginable replicar el tr\u00e1fico real de producci\u00f3n, as\u00ed que utilice el an\u00e1lisis del tr\u00e1fico y la intuici\u00f3n para conseguir una simulaci\u00f3n lo m\u00e1s cercana posible a la realidad. <\/p>\n\n El cambio est\u00e1 garantizado, pero la supervivencia no. El desarrollo \u00e1gil acepta el cambio como reacci\u00f3n a las condiciones empresariales. Sin embargo, es probable que la flecha apunte en la otra direcci\u00f3n. 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\u00edan estar en industrias diferentes. No todos los programas inform\u00e1ticos necesitan cambiar a diario. Algunas piezas de software no tienen potencial para el cambio y la adaptaci\u00f3n r\u00e1pidos. En algunas industrias, el cambio de software pasa por una certificaci\u00f3n costosa y que requiere mucho tiempo. Si quiere enviar astronautas al espacio con un destornillador y un extractor de virutas, los costes de transacci\u00f3n son elevados. <\/p>\n\n Su empresa tiene que pasar por un ciclo de decisi\u00f3n para implantar un cambio. Alguien tiene que intuir que existe una necesidad, otro decidir que se ajustar\u00e1 perfectamente a esa necesidad y que merece la pena implementarlo. Despu\u00e9s, alguien tiene que actuar y dise\u00f1ar la funci\u00f3n y ponerla en el mercado; por \u00faltimo, alguien tiene que ver si el cambio tiene el efecto esperado. En las peque\u00f1as empresas, el proceso puede implicar a dos o tres personas. La comunicaci\u00f3n es bastante r\u00e1pida. <\/p>\n\n La ingenier\u00eda 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\u00f3n. Diferentes proporciones de instancias provocan comportamientos de salida cualitativamente diferentes, lo que tambi\u00e9n ocurre con el tr\u00e1fico. Las redes congestionadas se comportan de forma cualitativamente diferente a las no congestionadas. <\/p>\n\n Cita favorita del cap\u00edtulo: \u00abLa mayor\u00eda de los probadores que he conocido son lo suficientemente perversos como para que si les dices que \u00abel camino feliz\u00bb a trav\u00e9s de la aplicaci\u00f3n, eso es lo \u00faltimo que har\u00e1n. Deber\u00eda ocurrir lo mismo con las pruebas de carga\u00bb. <\/em><\/strong><\/p>\n\n C\u00d3MO PUEDE AYUDAR ESTE LIBRO A LOS DESARROLLADORES DE SOFTWARE<\/strong><\/p>\n\n \u00ab\u00a1Lib\u00e9relo!\u00bb, de Michael T. Nygard, es una gu\u00eda pr\u00e1ctica que ayuda a los desarrolladores de software a dise\u00f1ar, desarrollar e implantar software listo para la producci\u00f3n. El libro proporciona ejemplos del mundo real y estudios de casos, destacando los escollos m\u00e1s comunes y ofreciendo soluciones para evitarlos. El libro ofrece consejos y t\u00e9cnicas para identificar y solucionar problemas antes de la implantaci\u00f3n, como la gesti\u00f3n de dependencias, las pruebas y la supervisi\u00f3n. Abarca temas como la optimizaci\u00f3n del rendimiento, la escalabilidad, la tolerancia a fallos, la supervisi\u00f3n y el registro, centr\u00e1ndose en la creaci\u00f3n de software que pueda sobrevivir a los rigores de la producci\u00f3n. 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\u00f3n. <\/p>\n","protected":false},"excerpt":{"rendered":" Un simple fallo de software por descuido puede costar mucho dinero a una organizaci\u00f3n, pero eso puede evitarse con sencillos cambios en la arquitectura y el dise\u00f1o. Esta nueva edici\u00f3n de \u00abLib\u00e9relo\u00bb se public\u00f3 en enero de 2018. Ilustra c\u00f3mo dise\u00f1ar sistemas que funcionen durante m\u00e1s tiempo con fallos limitados y recuperar el control cuando […]<\/p>\n","protected":false},"author":1,"featured_media":17674,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"_jet_sm_ready_style":"","_jet_sm_style":"","_jet_sm_controls_values":"","_jet_sm_fonts_collection":"","_jet_sm_fonts_links":"","footnotes":""},"categories":[101],"tags":[],"writer":[],"class_list":["post-19814","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-club-del-libro"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19814","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/comments?post=19814"}],"version-history":[{"count":3,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19814\/revisions"}],"predecessor-version":[{"id":20023,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19814\/revisions\/20023"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media\/17674"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media?parent=19814"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/categories?post=19814"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/tags?post=19814"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/writer?post=19814"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-fauxels-3182780-1024x683.jpg\")
<\/figure>\n\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-pixabay-459304-1024x683.jpg\")
<\/figure>\n\n\n