![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-lukas-928199-1024x678.jpg\")
<\/figure>\n\nDieses Buch hat uns geholfen, Risiken zu vermeiden, die Unternehmen viel Geld in Form von Ausfallzeiten und Reputation kosten. Achtzig Prozent der Lebenszykluskosten eines Produkts fallen in der Produktion an. <\/p>\n\n
DAS BUCH ERKL\u00c4RT IN 60 SEKUNDEN<\/strong><\/p>\n\n Die aktualisierte Version von Release it! Design and Deploy Production-Ready Software befasst sich mit der Produktion moderner Systeme – gro\u00dfer, komplexer und stark virtualisierter Systeme. Sie erhalten einen Einblick in das Chaos-Engineering, die Disziplin der Implementierung von Zero-Downtime-Updates und Continuous Delivery sowie die Robustheit von Cloud-nativer Software. Analysieren Sie Ans\u00e4tze zur Architektur, zum Design und zur Erstellung von Software-prim\u00e4r verteilten Systemen. <\/p>\n\n DIE DREI BESTEN ZITATE<\/strong><\/p>\n\n BUCHZUSAMMENFASSUNGEN UND NOTIZEN<\/strong><\/p>\n\n Kapitel eins: Stabilit\u00e4t schaffen<\/strong><\/p>\n\n Wenn Ihre Software oder Datenbank abst\u00fcrzt, wechseln Sie das Fenster und versuchen Sie etwas Neues. Ein Techniker vor Ort kann Ihnen bei der Umsetzung der \u00c4nderung helfen. Wenn Sie die Datenbank wechseln, versuchen Sie, zu einem besseren Service Provider zu wechseln. Sie k\u00f6nnen damit beginnen, Ihre Informationen und Daten von der alten Datenbank 1 in die neue Datenbank zwei zu verschieben und dann Datenbank 1 zu aktualisieren. Nachdem Sie die aktualisierte Datenbank \u00fcberpr\u00fcft haben, verschieben Sie Ihre Informationen und Daten in Datenbank 1. <\/p>\n\n Schlechte Stabilit\u00e4t verursacht hohe tats\u00e4chliche Kosten. Der scheinbare Preis ist ein Verlust an Einnahmen. Gute Stabilit\u00e4t kostet nicht so viel. Bei der Erstellung der Architektur, des Designs und der Implementierung kleinerer Systeme haben viele Entscheidungspunkte eine gro\u00dfe Hebelwirkung auf die Stabilit\u00e4t des Systems. Eine hochstabile Software kostet in der Regel genauso viel wie eine instabile. Um \u00fcber Stabilit\u00e4t zu sprechen, m\u00fcssen Sie sich \u00fcber Transaktionen im Klaren sein. Eine Transaktion ist eine abstrakte Arbeitseinheit, die vom System verarbeitet wird. Eine Transaktion erstreckt sich \u00fcber viele Seiten und umfasst in der Regel externe Integrationen wie die \u00dcberpr\u00fcfung von Kreditkarten. Transaktionen sind der Grund f\u00fcr die Existenz eines Systems. Ein System kann eine bestimmte Art von Transaktion verarbeiten und sie vollst\u00e4ndig dediziert machen. <\/p>\n\n Die gr\u00f6\u00dften Unsicherheitsfaktoren f\u00fcr die Lebensdauer Ihres Systems sind Daten- und Speicherlecks. Beide Gefahren k\u00f6nnen Ihr System w\u00e4hrend der Produktion zerst\u00f6ren und werden beim Testen selten erkannt. Testen macht Probleme sichtbar, damit Sie sie beheben k\u00f6nnen. Die Probleme, die auftreten, wenn Ihre Software fertig ist, sind diejenigen, die Sie nicht getestet haben. Daher werden diese Abst\u00fcrze auftreten, wenn Sie nicht auf Out-of-Memory-Fehler in der Anwendung testen. <\/p>\n\n \n Lieblingszitat des Kapitels: „Entwerfen Sie mit Skepsis, und Sie werden Widerstandsf\u00e4higkeit erreichen.<\/em>\n<\/strong>.“<\/p>\n\n Kapitel zwei: Design f\u00fcr die Produktion<\/strong><\/p>\n\n Operationen leiten Sie dazu an, \u00dcberlegungen zur Produktion anzustellen, indem Sie die physischen Grundlagen des Systems untersuchen: die Maschinen und Kabel, auf denen alles ruht. L\u00f6sen Sie einige Probleme in Bezug auf Netzwerke, Hostnamen und IP-Adressen. Jeder Einsatz hat seine eigenen Probleme, die beim Softwaredesign ber\u00fccksichtigt werden m\u00fcssen. <\/p>\n\n Die Vernetzung im Rechenzentrum und in der Cloud erfordert mehr als das \u00d6ffnen einer Steckdose. Diese Netzwerke ben\u00f6tigen in der Regel mehr Redundanz und Sicherheit als Desktop-Netzwerke. Wenn Sie eine oder zwei Virtualisierungsschichten hinzuf\u00fcgen, verhalten sich Anwendungen und Dienste anders als in den sicheren Grenzen der IDE. Sie erfordern umfangreiche Arbeiten, um sich in dieser Umgebung korrekt zu verhalten. <\/p>\n\n Eine Instanz ist eine Installation auf einem einzelnen Rechner (virtuell oder physisch) aus einem Load-Balanced-Array derselben ausf\u00fchrbaren Datei. Einzelne Instanzen sorgen f\u00fcr Transparenz, handhaben die Konfiguration richtig, \u00fcbernehmen die Kontrolle und verwalten Verbindungen. Jeder Rechner ben\u00f6tigt den richtigen Code, die richtige Konfiguration und die richtigen Netzwerkverbindungen. Entwickler achten in der Regel auf das Verhalten ihres Codes. Deshalb verf\u00fcgen sie \u00fcber gro\u00dfartige Tools zum Erstellen, Unterbringen und Bereitstellen von Code. Entwickler sollten in der Lage sein, ein System zu erstellen, Tests durchzuf\u00fchren und zumindest einen Teil des Systems lokal zu implementieren. <\/p>\n\n Verbindungsebenen umfassen alle Mechanismen, die eine Reihe von Instanzen zu einem zusammenh\u00e4ngenden System verbinden, einschlie\u00dflich Verkehrsmanagement, Erkennung und Lastausgleich. Durch die Verbindungsschichten kann eine hohe Verf\u00fcgbarkeit erreicht werden. \u00dcberlegen Sie, welche L\u00f6sung f\u00fcr Ihr Unternehmen die richtige ist, wenn Sie den Stack zu Interconnect, Control Pane und Operations hinaufgehen. Nur wenige Techniken zur Erkennung und Innovation von Diensten sind in der Regel auf zus\u00e4tzliche Software angewiesen. Ein umfangreiches Team mit Tausenden von winzigen Diensten schneidet bei der Verwendung von Consul oder anderen dynamischen Diensten gut ab. Auch die Kosten f\u00fcr den Betrieb von Consul machen sich schnell bezahlt. F\u00fcr kleine Teams ist DNS die ideale Wahl in einer sich langsam ver\u00e4ndernden Infrastruktur. Das w\u00fcrde engagierte physische Maschinen und dedizierte, langlebige virtuelle Maschinen voraussetzen. IP-Adressen bleiben in der Regel stabil, so dass DNS praktisch ist. <\/p>\n\n Lieblingszitat des Kapitels: „Lastausgleich, Routing, Lastverteilung und Service-Erkennung sind einige der wichtigsten Punkte, die beim Aufbau von Schichten zu ber\u00fccksichtigen sind.“<\/em><\/strong><\/p>\n\n Kapitel 3: Liefern Sie Ihr System<\/strong><\/p>\n\n Sie sollten nicht nur eine oder einige wenige Verteilungen f\u00fcr die Produktion planen, sondern mehrere. Nachdem Sie Ihre Software geschrieben, komprimiert und zur Bereitstellung an den Betrieb geschickt haben, f\u00fcgen Sie Versionshinweise zu jeder neuen Konfigurationsoption hinzu, die der Betrieb einstellen soll. Der Betrieb wird eine „geplante Ausfallzeit“ f\u00fcr die Ausf\u00fchrung der Version festlegen. In den meisten F\u00e4llen entwerfen Sie den Zustand des Systems nach einer Freigabe. Das Problem dabei ist, dass dies voraussetzt, dass das gesamte System in einem Quantensprung ver\u00e4ndert werden kann. <\/p>\n\n Code ist eine eindeutige Verbindlichkeit zwischen dem Zeitpunkt, an dem Sie den Code im Repository ausf\u00fchren, und dem Zeitpunkt, an dem er in der Produktion l\u00e4uft. Nicht bereitgestellter Code ist in der Regel Inventar. Er enth\u00e4lt unentdeckte Fehler und verursacht Ausfallzeiten in der Produktion. Es k\u00f6nnte sich um eine ideale Implementierung einer Funktion handeln, die niemand will. Die kontinuierliche Bereitstellung minimiert die Verz\u00f6gerung zwischen der Ausf\u00fchrung und der Produktion von Code und die Haftung f\u00fcr nicht bereitgestellten Code. <\/p>\n\n Datenbanken sind der Hauptgrund f\u00fcr „geplante Ausfallzeiten“, meist Schema\u00e4nderungen bei relationalen Datenbanken. Anstatt rohe SQL-Skripte gegen eine Admin-CLI zu implementieren, k\u00f6nnen Sie Ihre Schemaversion programmgesteuert vorw\u00e4rts rollen. Ein Migrations-Framework wie Liquibase kann Sie bei der Implementierung von \u00c4nderungen am Schema unterst\u00fctzen. Es macht diese \u00c4nderungen jedoch nicht automatisch vorw\u00e4rts- und abw\u00e4rtskompatibel. <\/p>\n\n Achten Sie beim Hinzuf\u00fcgen von Funktionen zu Ihrer Anwendung darauf, dass Sie keine Anwendungen konsumieren. Verschiedene Nutzer Ihres Dienstes haben andere Ziele und Bed\u00fcrfnisse. Jede konsumierende Anwendung hat ihr eigenes Entwicklungsteam, das nach ihrem Zeitplan arbeitet. Sie k\u00f6nnen die Verbraucher nicht dazu zwingen, sich an Ihren Ver\u00f6ffentlichungszeitplan anzupassen. Um kompatible API-\u00c4nderungen vorzunehmen, sollten Sie \u00fcberlegen, was eine inkompatible \u00c4nderung ausmacht. <\/p>\n\n Lieblingszitat des Kapitels: „Gleichzeitig hatte ich ein tiefes Gef\u00fchl des Verlustes: all die Zeit in der Einsatzarmee. All das vergeudete Potenzial. Die verschwendete Menschlichkeit! Menschen zu benutzen, als w\u00e4ren sie Bots. Das Leben, die Familien, die Schlafgewohnheiten zu zerst\u00f6ren… das war alles eine solche Verschwendung.“<\/em><\/strong><\/p>\n\n Kapitel Vier: L\u00f6sen Sie systemische Probleme<\/strong><\/p>\n\n Lasttests sind in der Regel ein unkomplizierter Prozess. Sie legen einen Testplan fest, erstellen einige Skripte, konfigurieren die Lastgeneratoren und den Testdispatcher und starten einen Testlauf \u00fcber die Nacht. Nachdem der Test abgeschlossen ist, analysieren Sie die w\u00e4hrend des Tests gesammelten Daten. Pr\u00fcfen Sie die Ergebnisse, nehmen Sie Konfigurations\u00e4nderungen vor und planen Sie den n\u00e4chsten Testlauf. Lasttests sind sowohl eine Kunst als auch eine Wissenschaft. Es ist unvorstellbar, den realen Datenverkehr in der Produktion nachzubilden. Nutzen Sie daher die Analyse des Datenverkehrs und Ihre Intuition, um eine m\u00f6glichst realistische Simulation zu erreichen. <\/p>\n\n Der Wandel ist garantiert, aber das \u00dcberleben nicht. Bei der agilen Entwicklung wird der Wandel als Reaktion auf die gesch\u00e4ftlichen Bedingungen begr\u00fc\u00dft. Allerdings zeigt der Pfeil wahrscheinlich in die andere Richtung. Softwarever\u00e4nderungen k\u00f6nnen neue Produkte und M\u00e4rkte hervorbringen. Er kann Raum f\u00fcr neue Allianzen und neuen Wettbewerb schaffen und die Fl\u00e4che zwischen Unternehmen, die fr\u00fcher in verschiedenen Branchen t\u00e4tig waren, vergr\u00f6\u00dfern. Nicht jede Software muss t\u00e4glich ge\u00e4ndert werden. Manche Software hat kein Potenzial f\u00fcr schnelle \u00c4nderungen und Anpassungen. In einigen Branchen m\u00fcssen Software\u00e4nderungen durch teure und zeitaufw\u00e4ndige Zertifizierungen erfolgen. Sie haben hohe Transaktionskosten, wenn Sie Astronauten mit einem Schraubenzieher und einem Spanabzieher ins All schicken wollen. <\/p>\n\n Ihr Unternehmen muss einen Entscheidungszyklus durchlaufen, um eine Ver\u00e4nderung zu implementieren. Jemand muss erkennen, dass es einen Bedarf gibt, ein anderer muss entscheiden, dass die Funktion perfekt zu diesem Bedarf passt und es sich lohnt, sie umzusetzen. Dann muss jemand handeln und die Funktion entwerfen und sie auf den Markt bringen – und schlie\u00dflich muss jemand sehen, ob die \u00c4nderung die erwartete Wirkung hat. In kleinen Unternehmen kann dieser Prozess zwei bis drei Personen betreffen. Die Kommunikation ist ziemlich schnell. <\/p>\n\n Chaos Engineering befasst sich mit verteilten Systemen, in der Regel mit gro\u00dfen Systemen. Staging- oder QA-Umgebungen sind nicht ideal f\u00fcr das Verhalten von Produktionssystemen in gro\u00dfem Ma\u00dfstab. Unterschiedliche Verh\u00e4ltnisse von Instanzen f\u00fchren zu qualitativ unterschiedlichem Ausgabeverhalten, was auch f\u00fcr den Verkehr gilt. \u00dcberlastete Netzwerke verhalten sich qualitativ anders als nicht \u00fcberlastete Netzwerke. <\/p>\n\n Lieblingszitat des Kapitels: „Die meisten Tester, die ich kenne, sind so pervers, dass, wenn Sie ihnen den „gl\u00fccklichen Weg“ durch die Anwendung sagen, dies das Letzte ist, was sie tun werden. So sollte es auch bei Lasttests sein.“ <\/em><\/strong><\/p>\n\n WIE DIESES BUCH SOFTWAREENTWICKLERN HELFEN KANN<\/strong><\/p>\n\n „Release It!“ von Michael T. Nygard ist ein praktischer Leitfaden, der Softwareentwicklern hilft, produktionsreife Software zu entwerfen, zu entwickeln und einzusetzen. Das Buch enth\u00e4lt Beispiele und Fallstudien aus der Praxis, die h\u00e4ufige Fallstricke aufzeigen und L\u00f6sungen anbieten, um diese zu vermeiden. Das Buch bietet Tipps und Techniken, um Probleme vor der Bereitstellung zu erkennen und zu beheben, einschlie\u00dflich der Verwaltung von Abh\u00e4ngigkeiten, Tests und \u00dcberwachung. Es behandelt Themen wie Leistungsoptimierung, Skalierbarkeit, Fehlertoleranz, \u00dcberwachung und Protokollierung und konzentriert sich auf die Entwicklung von Software, die den harten Anforderungen der Produktion standhalten kann. Wenn Sie die Richtlinien des Buches befolgen, k\u00f6nnen Softwareentwickler zuverl\u00e4ssige und widerstandsf\u00e4hige Systeme erstellen, die den Anforderungen ihrer Benutzer und Kunden gerecht werden. Insgesamt ist dieses Buch eine unverzichtbare Ressource f\u00fcr Entwickler, die die Qualit\u00e4t und Leistung ihrer Software in der Produktionsumgebung verbessern m\u00f6chten. <\/p>\n","protected":false},"excerpt":{"rendered":" Ein einfacher, schlampig ausgef\u00fchrter Softwarefehler kann ein Unternehmen viel Geld kosten, aber das l\u00e4sst sich mit einfachen \u00c4nderungen an Architektur und Design vermeiden. Diese neue Ausgabe von ‚Release It‘ wurde im Januar 2018 ver\u00f6ffentlicht. Sie veranschaulicht, wie Sie Systeme entwerfen, die l\u00e4nger mit begrenzten Ausf\u00e4llen arbeiten und die Kontrolle wiedererlangen, wenn etwas schief geht. Dieses […]<\/p>\n","protected":false},"author":1,"featured_media":17673,"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":[83],"tags":[],"writer":[],"class_list":["post-19819","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-buchclub"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19819","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/comments?post=19819"}],"version-history":[{"count":3,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19819\/revisions"}],"predecessor-version":[{"id":20027,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19819\/revisions\/20027"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/media\/17673"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/media?parent=19819"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/categories?post=19819"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/tags?post=19819"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/writer?post=19819"}],"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