RESILIENT SOFTWARE DESIGN - pentasys.de · am besten mit „A distributed system is one in which the failure of a computer you didn‘t even know existed can render your own computer

RESILIENT SOFTWARE DESIGNAre you ready to release the Chaos Monkey?

Digitalisierung und agile Methoden führen als treibende Faktoren dazu, dass sich die Art und Weise, wie wir Software entwickeln, gerade entscheidend verändert. Resilient Software Design ist ein Prinzip, um die Entwicklung von robusten verteilten Systemen auf Basis von Microservices und Cloud-Technologien zu unter-stützen. Doch wobei handelt es sich bei Resilient Software De-sign genau? Warum brauchen wir es? Wie macht es die Software robuster? Wie wird die Wirksamkeit der Maßnahmen getestet?

blickpunkteDaniel Fistrić – Resilient Software Design

1. DIGITALISIERUNG, AGILITÄT UND MICROSERVICES

Vor der Definition von Resilient Software Design, der Beschreibung der Elemente und erster Erfahrungen ist es wichtig zu verstehen, in welchem Bereich es anzu-siedeln ist.

11Agile

Methoden

22Skalierung& Führung

33ConitinousDelivery &

DevOPs

66ManagedEvolution

55Agile

Architektur

44Software-

skills

GanzheitlicheAgilität

Als Ausgangspunkt kann hierbei die Digitalisierung und Trans-formation zur Agilität dienen. Der Transformationsprozess lässt sich in sechs Bausteine gliedern (vgl. Abbildung 1, siehe [1]), wofür für Resilient Software Design der Baustein Softwareskills und der Baustein Agile Architektur von entscheidender Bedeutung sind.

Digitalisierung bedeutet, dass viele Unternehmen nur dann im Wettbewerb bestehen können, wenn sie die Möglichkeiten neuer Technologien nutzen und ihre Geschäftsmodelle und Organisa- tionsstrukturen daran anpassen.

Heutige Entwicklungs-, Qualitätssicherungs- und Releasepro-zesse sind häufig zu langsam und aufwändig, um schnell auf neue und sich ändernde fachliche Anforderungen zu reagieren. Die damit einhergehende Komplexität ist teilweise enorm. Um dieser Probleme Herr zu werden besteht nach Abwägung der Vor- und Nachteile die Möglichkeit, eine agile Microservice Architektur als Ausweg zu nutzen, die zu den agilen Architekturen aus Baustein Fünf zählt.

Im Zusammenhang mit einer solchen Architektur ist Resilient Software Design ein entscheidender Faktor, da sich die Komplexi-tät von der Entwicklung hin zum Betrieb und dem Zusammenspiel von Microservices verschiebt.

Doch worum genau handelt es sich bei Resilient Software Design?

Abbildung 1 - Die sechs Bausteine der ganzheitlichen Agilität vgl. [1]

2. DEFINITION

Die schlechte Nachricht vorweg, es existiert keine allgemein gültige Definition von Resilient Software Design in der Literatur. Bei Resilient Software Design han-delt es sich um ein Mindset, welches bereits beim Design und der Entwicklung von Software berücksichtigt werden sollte und sich damit in Baustein Vier und Fünf der ganzheitlichen Agilität eingliedern lässt. Die Maxime dieser Denkweise lässt sich am besten mit „Everything fails all the time“ [2] beschreiben.

In verteilten Systemen sind Ausfälle keine Ausnahmesituation, sondern ein nahezu normaler Zustand. Deshalb lassen sie sich am besten mit „A distributed system is one in which the failure of a computer you didn‘t even know existed can render your own computer unusable.“ [3] beschreiben. So verringert sich die Ge-samtverfügbarkeit eines Systems mit einer steigenden Zahl von Microservices, da diese separate Komponenten darstellen, die miteinander über ein Netzwerk kommunizieren müssen. Latenz-zeiten, Ausfälle von einzelnen Microservices, Cloud Diensten und

Datenbanken sowie weitere Risiken stellen ein ernst zu nehmen-des Problem dar. Resilient Software Design geht deshalb davon aus, dass Fehlerzustände in verteilten Systemen normal sind. Sie können immer auftreten, so dass ein Betrieb im partiellen Fehlerzustand in Ordnung ist. Es gilt deshalb, die Robustheit von Software gegenüber Fehlern zu erhöhen.

2blickpunkteDaniel Fistrić – Resilient Software Design

Bei der Robustheit von Software handelt es sich um ein Qualitäts-merkmal, welches in der Vergangenheit durch die Entwicklung von „fail-safe“- oder „failure-resistant“-Systemen erreicht werden sollte. „Fail-safe“-Systeme werden im Allgemeinen so entwickelt, dass sie sich im Fehlerfall abschalten. Sie versuchen die Datenkon-sistenz zu wahren und keinen weiteren Schaden anzurichten – sie versagen gutmütig. „Failure-resistant“-Systeme behandeln Fehler als Ausnahmezustand. Sie versuchen, trotz dieser oder invalider Daten, einen vollen weiteren Betrieb zu gewährleisten, indem Sie die Fehler korrigieren oder versuchen, die Fehler nicht auftreten zu lassen. Dazu gehört beispielweise die Validierung und Filterung ungültiger Eingabedaten.

Durch den Wechsel zu Microservice- und Cloud Architekturen gelten diese Prinzipien für sich alleine betrachtet als überholt, weshalb bei Resilient Software Design der Grundsatz „Do not try to avoid failures. Embrace them.“ [4] gilt. Warum dieser Grundsatz so wichtig ist, lässt sich am besten an einem Beispiel aus der Praxis nachvollziehen.

Abbildung 2 - Ein Beispiel aus der Praxis: Ad-Service im Portal Kontext

Browser

get page

send html content

request Ad-Teaser (Java-Script)

load targeting-speci�c data

return targeting-speci�c data

calculate whichad to show based ontargeting-speci�c data

get Ad-Teaser

return Ad-Teaser

return Ad-Teaser

Add response to DOM (Java-Script)

Portal Ad-Service Database Content-Service

Browser Portal Ad-Service Database Content-Service


Bei der Entwicklung des Ad-Service stand jedoch nicht nur die Performance im Vordergrund. Das Entwicklungsteam der Penta-sys hat eine solche Situation bereits bei der Entwicklung bedacht und die Software nach dem Prinzip des Resilient Software Design entwickelt und einen Circuit Breaker eingesetzt. Der Ausfall blieb deshalb durch die Endkunden unbemerkt.

Circuit Breaker arbeiten nach dem gleichen Prinzip. Der Circuit Breaker wird im Aufrufer implementiert und überwacht die Aufrufe eines anderen Dienstes. Falls ein konfigurierbarer Schwellwert für ein Kriterium überschritten wird, öffnet sich der Circuit Breaker und es werden keine Aufrufe mehr getätigt. Ein Circuit Breaker erfüllt also nicht den gleichen Zweck wie ein primitiver Retry-Me-chanismus, da der Circuit Breaker weitere Aufrufe unterbinden will und damit einen Fail-Fast-Ansatz verfolgt. Zugleich kann er das aufzurufende System vor weiterer Last schützen. Er ist damit bestens dazu geeignet, Kettenreaktionen zu vermeiden. Mögliche Kriterien für das Auslösen des Circuit Breakers sind z.B. Timeouts, die Anzahl fehlerhafter Aufrufe oder die Antwortzeiten.

Eine clevere Implementierung verfolgt nicht nur den Ansatz, den „Schaltkreis“ zu öffnen, sondern auch, ihn automatisch wieder zu schließen, um damit Aufrufe weiter zu leiten, sobald ein Zustand erreicht ist, der davon ausgehen lässt, dass alles in Ordnung ist. Dazu kann der Circuit Breaker einzelne Aufrufe durchlassen und das Ergebnis auswerten, oder nur für eine bestimmte Zeit ge-öffnet sein. Eine weitere Möglichkeit ist, sich einen geeigneten Standardwert zurück geben zu lassen.

4. CIRCUIT BREAKER

Circuit Breaker sind eines der populärsten Mittel, um mehr Resilience zu errei-chen und wurden erstmals durch Michael Nygard in seinem Werk „Release it!“ [5] in Form des Circuit Breaker Patterns beschrieben. Jede Elektroinstallation verfügt über Sicherungen, die im Falle eines Kurzschlusses dafür sorgen, dass kein Brand und damit keine weiteren Schäden entstehen. Die Sicherung erreicht dies, indem sie den Zustand des Stromkreises überwacht und bei gefährlichen Warnzeichen den Stromfluss unterbricht.

3. EIN BEISPIEL AUS DER PRAXIS

Ein Unternehmen betreibt ein großes Kundenportal, welches verschiedene Systeme anspricht, um seinen Endkunden Dienste in Bezug auf die Produkte des Unternehmens zur Verfügung zu stellen. Dabei handelt es sich unter anderem um die Möglichkeit, neue Verträge abzuschließen oder bestehende zu bearbeiten. Zu den Systemen gehören sowohl ältere Legacy Systeme, als auch neu entwickelte Microservices. Einer dieser Microservices ist für das Ausliefern von personenbe-zogener Werbung verantwortlich. Dazu wertet der Ad-Service verschiedene Da-ten aus, um dem Endkunden im Portal Werbung für Produkte des Unternehmens anzuzeigen, die für ihn mit hoher Wahrscheinlichkeit interessant sind.

Vor einigen Wochen trat bei diesem Ad-Service bei der Ausliefe-rung der Werbung ein Problem auf. Durch einen Programmierfehler im Portal wurde der Ad-Service über zehn Mal so häufig aufgerufen wie dies unter Schwerlastzeiten der Fall ist. Da der Service auf möglichst kurze Antwortzeiten und eine hohe Stabilität ausgelegt ist, konnte er die Last handhaben. Dies führte jedoch zu einem an-deren Problem. Der Ad-Service nutzt einen Content Service, um Codefragmente und Banner zu beziehen, welche er an das Portal weiterleitet. Die verstärkten Zugriffe auf den Content Service ließen ihn mit verlängerten Antwortzeiten reagieren. Da circa 60% der sichtbaren Flächen auf der Startseite des Portals durch personalisierte Werbung belegt sind, ist leicht ersichtlich, was ein Gesamtausfalls des Ad-Service bedeutet – eine fast vollständig weiße Startseite mit entsprechender Wirkung auf den Kunden.


5. LESSONS LEARNED

Der Einsatz von Hystrix verursachte bei der Entwicklung keine nennenswerten Mehrkosten oder Aufwände, doch bewahrte er das Unternehmen vor einem et-waigen Imageschaden und verringerte finanzielle Einbußen durch ausbleibende Vertragsabschlüsse. Auch konnten sich die unterschiedlichen Teams durch die gewonnene Zeit auf die Suche nach der Ursache des Ausfalls konzentrieren, statt Zeit mit der Eindämmung der Symptome zu verbrauchen.

Es bleibt anzumerken, dass ein solcher Ausfall nicht nur durch einen Programmierfehler verursacht werden kann. Ursache für ei-nen unerwarteten Lastanstieg können ebenso eine Werbeaktion, ausgefallene Hardwarekomponenten oder viele weitere Gründe sein. Im Grunde sollten solchen Sicherungsmaßnahmen Teil der fachlichen Anforderungen sein. Fehlerzustände, die in verteilten Systemen auftreten können, haben nicht nur Auswirkungen auf die technischen Aspekte eines Systems, sondern auch auf die fach-lichen Anforderungen, die ihnen zugrunde liegen. Sie bedingen zusätzliche fachliche Anforderungen, die beschreiben, wie sich das System beim Eintreten eines solchen Zustands verhalten soll.

Sie müssen schon vor der Entwicklung berücksichtigt werden, um technisch geeignete Fallback-Mechanismen, wie die Auslieferung eines Standardwerbebanners, implementieren zu können. Dieser Umstand macht deutlich, warum wir uns mit dem Begriff Resilient Software Design nicht nur auf der technischen Implementierungs-ebene beschäftigen müssen und warum der Begriff gerade in aller Munde ist.

Es existieren bereits für viele populäre Programmiersprachen Bibliotheken, die den Implementierungsaufwand für einen Circuit Breaker auf ein Minimum reduzieren. Eines der bekanntesten Bei-spiele im Java-Umfeld ist Netflix Hystrix [6], welches durch Spring Cloud auch einfach mit Hilfe von Annotationen eingebunden wer-den kann und in diesem Beispiel zum Einsatz kam. [7]

In dem zuvor erwähnten Beispiel wurde der Circuit Breaker mit einem Schwellwert von 200ms für die Antwortzeit des dahin-terliegenden Content Systems implementiert. Zusätzlich wurde für den Fall einer Schwellwertüberschreitung vorgesehen, dass neutrale Standardbanner ausgeliefert werden. Durch diesen Me-chanismus konnte das Content System, das unter der Last in die Knie gegangen war, vor einem Komplettausfall (welcher zu wei-teren Kettenreaktionen hätte führen können) geschützt werden. Außerdem stand Zeit für die Fehleranalyse zur Verfügung, wäh-rend der Ad-Service und das Portal den Betrieb in diesem partiel-len Fehlerzustand aufrechterhalten konnten. Binnen einer Stunde wurde der fehlerhafte Programmcode identifiziert und der korri-gierte Ad-Service deployt. Während dieser Zeit erholte sich das unter Last stehende Content System. Anschließend schloss sich der Circuit Breaker ohne weiteres Zutun und die personalisierte Werbung konnte durch den Ad-Service wieder an das Portal und seine Besucher ausgeliefert werden.

Abbildung 3 - Circuit Breaker vgl. [5]

Openon call / pass throughcall succeeds / rest countcall fails / count failurethresholh rechead / trip breaker

Half-Openon call / pass throughcall succeeds / resetcall fails / trip breaker

ClosedTRIP BREAKER

ATTEMPT RESET

RESETTRIP BREAKER

on call / failon timeout / attempt reset


Er kann gezielt einzelne Systeme deaktivieren bzw. herunterfah-ren, um Fehlerzustände in anderen Systemen und Systemgruppen zu verursachen. Diese und weitere Vorgehensweisen sind allge-mein unter dem Namen „Error Injection“ bekannt. Fehler können nicht nur durch das Deaktivieren von Systemen „injiziert“ werden. Weitere Maßnahmen können zum Beispiel verlängerte oder stark schwankende Anwortzeiten, ein enormer Lastanstieg, fehlerhafte Antworten oder korrupte Datensätze in Datenbanken sein.

Natürlich ist das alleinige Deaktivieren von Systemen nicht aus-reichend. Damit auftretende Fehler überwacht werden können, müssen geeignete Monitoring-Lösungen implementiert werden, die Rückschlüsse auf das Verhalten der von den Ausfällen betrof-fenen Systeme liefern können.

Die Ziele von Chaos Testing sind, aus den aufgetretenen Fehlern zu lernen und sie zu korrigieren. Deshalb sollten diese Tests nur zu Zeiten stattfinden, in denen die an der Entwicklung und dem Be-trieb von Systemen beteiligten Ingenieure anwesend und Nutzer des Dienstes nicht in einem erheblichen Maß von den Ausfällen betroffen sind. Aus diesem Grund sollten die üblichen Bürozeiten gewählt und Schwerlastzeiten vermieden werden.

Obwohl im Beispiel ein möglicher Ausfall bedacht wurde, fand ein Test unter realen Bedingungen nie statt. Zudem fehlte der prak-tische Beweis, ob der Mechanismus auch wirklich in einer kom-plexen Produktionsumgebung funktioniert, die sich häufig von den Testumgebungen unterscheidet. Deshalb wirft dieser Artikel einen Blick über den Tellerrand hinaus und stellt ein interessantes Konzept vor, welches zeigt, dass Resilient Software Design nicht bei der Entwicklung von Softwaresystemen stoppt, sondern bei Test und dem produktiven Betrieb von Software weitergeht.

6. CHAOS TESTING

Resilient Software Design erfordert eine geradezu paranoide Denkweise. Was schiefgehen kann, wird schiefgehen. Dieser Gedanke hat den verantwortlichen Personen, die hinter Netflix‘s Chaos Monkey Projekt [5] stecken, wahrscheinlich schlaflose Nächte beschert. Doch was steckt hinter Chaos Monkey? Dazu muss man sich eine Horde bewaffneter Affen vorstellen, die durch ein Rechenzentrum stürmt und wahllos auf beliebige Systeme schießt. Diese Vorstellung erscheint nicht nur wegen der martialischen Art und Weise angsteinflößend. Im Software-alltag treibt sie den Beteiligten sicher auch tagsüber den Schweiß auf die Stirn.

Zugegeben, es ist eine drastische Maßnahme, wahllos Systeme zu deaktivieren und die Auswirkungen zu beobachten. Es ist jedoch auch ein sehr effektives Mittel, um die Robustheit der eingesetzten Systeme zu prüfen. Zur Stabilität gehört in diesem Fall nicht nur der Code der Anwendung, sondern die gesamte Organisation. Auf welche Art und Weise und wie schnell wird der Fehler registriert? Wie erfolgt die Kommunikation? Was sind die Auswirkungen? Wie zügig kann der Fehler behoben werden? Existieren überhaupt die notwendigen Organisations- und Kommunikationsstrukturen, um den Fehler beheben zu können?

Diese und weitere Fragen machen deutlich, dass Chaos durch die-se Vorgehensweise nicht verursacht, sondern vermieden werden soll und in vollem Einklang mit dem eingangs erwähnten Grund-satz von Resilient Software Design „Do not try to avoid failures. Embrace them“ steht.

Chaos Testing sorgt bereits in der Entwicklung dafür, dass mit der Unvorhersehbarkeit gerechnet wird und sich keine unangebrach-ten „das wird nie passieren“ oder „auf unserer Umgebung hat alles funktioniert“ Mentalitäten einstellen. Diese sind allzu häufig der Grund dafür, dass bewusst Risiken eingegangen werden, die zu den bereits erwähnten Kettenreaktionen führen können. Es ist schwierig, alle beteiligten Systeme einer Produktionsumgebung in einer Testumgebung zu replizieren. Mit einer zunehmenden An-zahl an Microservices kann der Aufwand dafür exorbitant wachsen.

Netflix‘s Software Ingenieure haben, um manuelle Aufwände für die Überprüfung von Resilient Software Design und die Durch-führung Chaos Testing zu minimieren, mehrere Tools unter dem Sammelbegriff „Simian Army“ entwickelt und unter der Apache License als Open Source Software veröffentlicht [9] . Eines dieser Tools ist der Chaos Monkey, dem das Chaos Monkey Projekt von Netflix seinen Namen verdankt.


Dieses Übungsszenario sorgt dafür, dass mit dem Auftreten von Softwarefehlern im Produktionseinsatz auf jeder Organisations-ebene umgegangen werden kann. Dadurch kann das Bewusstsein für Resilient Software Design gestärkt und seine Umsetzung forciert werden. Auch wenn nachvollziehbar ist, dass eine solch drastische Vorgehensweise zu Beginn großes Unbehagen bei allen Betroffenen von der Entwicklung bis zum Betrieb auslösen kann. Es muss berücksichtigt werden, vorab Maßnahmen einzuleiten und umzusetzen, um dieses Unbehagen gar nicht erst entstehen zu lassen. Eine „Ausrede“, nicht für Resilient Design oder Software Resilience im Allgemeinen zu sorgen, kommt nicht mehr in Frage, da ein Ausfall jederzeit auftreten und sogar bewusst ausgelöst werden kann.

Abschließend sollte noch erwähnt werden, dass Resilient Software Design nicht immer angewendet werden kann. Eine Ausnahme stellen lebenskritische oder Echtzeitapplikationen dar. Aufgrund ihrer Konzeption, möglichst keine Fehlerzustände auftreten zu lassen, können diese dem Ansatz von Natur aus nicht folgen. Eine „immer möglich und in Ordnung“-Betrachtung gibt es hier nicht. Per se ist es möglich, fast jedes aktuelle System als verteiltes Sys-tem zu betrachten und einzelne Maßnahmen zum Erreichen eines Resilient Designs umzusetzen, jedoch ist das Chaos Testing bei einem monolithischen System nicht in der vorgestellten Art und Weise anwendbar.

7. FAZIT

Auch wenn in diesem Blickpunkt nur ein erster Überblick über Resilient Software Design vermittelt wurde, existieren noch viele weitere Maßnahmen, um Resilient Software Design zu unterstützen. Ein Kochrezept kann wie so oft leider nicht erstellt werden, denn jede Maßnahme muss für einen konkreten Fall geprüft werden. Auch sollte die Wirtschaftlichkeit der eingesetzten umzusetzenden Maßnahmen geprüft werden. Resilient Software Design ist überwiegend, aber nicht ausschließlich, im agilen Umfeld bei der Entwicklung von verteilten Syste-men anzusiedeln und spiegelt sich in den sechs Bausteinen der ganzheitlichen Agilität wieder.

Zusammenfassend steht Resilient Software Design für die Qualität der Software und ist einer von vielen Wegen, höhere Robustheit und höhere Kundenzufriedenheit zu erreichen und das Risiko von Komplettausfällen zu minimieren. Der gedankliche Ansatz dahinter ist geradezu menschlich. Fehler passieren, letz-ten Endes kommt es hauptsächlich darauf an wie man mit ihnen umgeht, sich mit ihnen auseinandersetzt oder ob man lieber die Augen verschließt und auf das Beste hofft. Denn manchmal heißt es plötzlich:

»Hinter Dir! Ein Drei-köpfiger Affe!« Monkey Island


Literaturverzeichnis

[1] H. Duschinger, „Theorie und Praxis zur Einführung agiler Me-thoden bei Banken,“ Banking and Information Technology (BIT), Nr. 2, 2016.

[2] W. Vogel, „Twitter,“ Amazon.com, 18. Mai 2015. [Online]. Avai-lable: https://twitter.com/werner/status/600474468507525120. [Zugriff am 18. November 2016].

[3] L. Lamport, Quote.

[4] U. Friedrichsen, „Patterns of resilience,“ 5. November 2014. [Online]. Available: http://de.slideshare.net/ufried/patterns-of-re-silience. [Zugriff am 17. November 2016].

[5] M. T. Nygard, Release It!, Pragmatic Bookshelf, 2007.

Die Blickpunkte sind ein kostenloser Newsletter der PENTASYS AG.

PENTASYS ist ein führender IT-Projektdienstleister, der als agiler Enabler die Effizienz und Wettbewerbsfähigkeit großer, namhafter Kunden durch individuelle, qualitativ hochwertige Software-Entwicklung und IT-Be-ratung steigert. Als Partner und Ratgeber unterstützt PENTASYS seine Kunden bei den rasanten globalen Veränderungen und trägt somit maß-geblich zum Erfolg seiner Kunden bei. Zu den Referenzkunden gehören namhafte Unternehmen aus den Branchen Automotive, Financial Services, Telecommunication, Travel, Transport & Logistics und Cross Industry Solu-tions. Das Unternehmen ist ISO-9001/2008 zertifiziert und beschäftigt ca. 500 Mitarbeiter am Hauptsitz München und an den Standorten Stuttgart, Nürnberg, Frankfurt am Main, Köln und Hamburg. PENTASYS ist ein Toch-terunternehmen der französischen AUSY Group, die 4.000 Mitarbeiter in 11 Ländern beschäftigt.

Sämtliche Inhalte des Newsletters, auch Konzepte und Design, sind urheberrechtlich geschützt. Das Copyright/Urheberrecht liegt bei der PENTASYS AG.

©2017 PENATSYS AG

PENTASYS AGRüdesheimer Straße 980686 MünchenTel.: +49 89 5 79 [email protected]

Über den Autor

Daniel Fistric ist Senior Consultant bei der PENTASYS AG. Sein Fokus liegt auf der agilen Softwareentwicklung im Bereich Finan-cial Services. Neben Kundenprojekten engagiert er sich bei der Be-treuung von Abschlussarbeiten und interessiert sich für aktuelle Trends und Themen in der Softwareentwicklung.

Seinen Bachelorabschluss in Information Systems and Manage-ment schloss er mit einer Arbeit über die prototypische Entwick-lung eines Location Based Social Networks ab. In seiner Freizeit beschäftigt er sich außerdem mit der Entwicklung von Android Apps und der Umsetzung von Raspberry Pi Projekten.

[6] D. Gross, „Hystrix - Defend your app,“ 1. März 2015. [Online]. Available: https://github.com/Netflix/Hystrix/wiki. [Zugriff am 17. November 2016].

[7] Pivotal Software, „Getting Started - Circuit Breaker,“ Pivotal Software, 2016. [Online]. Available: https://spring.io/guides/gs/circuit-breaker/. [Zugriff am 17. November 2016].

[8] L. Hochstein und C. Rosenthal, „Netflix Chaos Monkey Upgra-ded,“ 19. Oktober 2016. [Online]. Available: http://techblog.netflix.com/2016/10/netflix-chaos-monkey-upgraded.html. [Zugriff am 17. November 2016].

[9] Netflix, Inc., „Netflix Simian Army,“ Netflix, Inc., 2016. [Online]. Available: https://github.com/Netflix/SimianArmy. [Zugriff am 17. November 2016].


Documents

RESILIENT SOFTWARE DESIGN - pentasys.de · am besten mit „A distributed system is one in which the failure of a computer you didn‘t even know existed can render your own computer