Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierter Enterprise-Computing-Lösungen geht. Das gilt zumindest immer dann, wenn die Anwendung als Monolith in einem Application-Server deployt werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so mit Hilfe von Nebenprojekten wie Eclipse MicroProfile den Anforderungen moderner Cloud-Native-Anwendungen gerecht zu werden. Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien, aka Serverless, eine gute Figur macht.
http://www.opitz-consulting.com/go/3-6-11 --- Softwareentwicklung, -test und -betrieb können durch Virtualisierung viele Vorteile erzielen. In diesem Zusammenhang werden häufig Werkzeuge für die Bereitstellung von Umgebungen eingesetzt. Verschiedene Werkzeuge adressieren aber unterschiedliche Einsatzszenarien. Wo im Applikationslebenszyklus können diese Werkzeuge sinnvoll eingesetzt werden und wie sieht es mit Kosten und Nutzen aus? ---- Unser Senior Software Architect Richard Attermeyer stellte bei der W Jax am 5.11.2014 in München die Tools Vagrant, Puppet und Docker im Einzelnen vor und erläuterte ihren Nutzen anhand von Use Cases und Live Demos. ---- Weitere Infos: https://jax.de/wjax2014/sessions/vagrant-puppet-docker-fuer-entwickler-und-architekten ---- Über uns: Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.---- Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10 ---- Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874 ---- Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Java scheint mit seinem Memory- und Runtime-Overhead in Zeiten von Cloud-native und Serverless nicht wirklich gut für die Zukunft gerüstet. Erschwerend kommt hinzu, dass viele auf Java basierende Frameworks mit Annotation Scanning, Aufbau von Proxies und Caches das Start- und Speicherverhalten weiter negativ beeinflussen. Bedeutet das das Aus für Java in der Wunderwelt der Cloud? Mitnichten! Projekte wie Quarkus versuchen, Java in der Cloud zur Numero Uno werden zu lassen. Und das auf beeindruckende Art und Weise. Die Session zeigt anhand praktischer Beispiele, was heute bereits möglich ist.
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer InfrastrukturQAware GmbH
JAX 2017, Mainz: Vortrag von Josef Fuchshuber (@fuchshuber, Cheftechnologe bei QAware) und Tobias Placht (@knacht, Software Ingenieur bei QAware).
Abstract: Wie oft kannst du ein neues Feature releasen? Jede Woche? Jeden Tag? Jede Stunde? Continuous Delivery ist einer der wesentlichen Treiber, warum wir Cloud-native Anwendung bauen. Für Software-driven Organisationen ist das der Schlüssel für eine sicherere, stabilere Software bei minimiertem Risiko und kurzen Feedbackschleifen. Die Herausforderung dabei ist, aus jeder Codeänderung möglichst schnell eine lauffähige und gründlich getestete Software zu machen. Das ist für viele Firmen ein wesentlicher Wettbewerbsvorteil. Wir zeigen in diesem Vortrag eine Werkzeugkette, mit der Continuous Delivery nicht nur für Cloud-native Anwendungen, sondern auch auf Cloud-nativer Infrastruktur möglich ist. Ganz im Gedanken von „Everything is Code“ betrachten wir dabei nicht nur das Bauen und Testen von Software, sondern auch die Automatisierung der Infrastrukturbereitstellung, der Deployments und Roll-outs. Dabei treffen alte Bekannte (z.B. Jenkins, SonarQube) auf Cloud-Computing-Technologien wie z.B. Docker für Betriebssystemvirtualisierung und DC/OS für das Clustermanagement.
Testgetriebene Entwicklung mit Jasmine und Karma hat sich mittlerweile schon als defacto-Standard etabliert. Routinen ohne Abhängigkeiten lassen sich damit ohne Probleme testen. Die Schwierigkeiten beginnen jedoch schon, wenn es um die Auflösung von Abhängigkeiten geht. In diesem Vortrag werden verschiedene Strategien und Werkzeuge vorgestellt, mit denen Abhängigkeiten zu Objekten und Funktionen oder zum Server abgedeckt werden können. Aber nicht nur Abhängigkeiten stellen Schwierigkeiten bei der testgetriebenen Entwicklung dar, auch der Umgang mit Fixtures ist bei der testgetriebenen Entwicklung mit JavaScript relevant. Abgerundet wird dieser Vortrag mit einigen Best Practices für die testgetriebenen Entwicklung mit JavaScript.
Continuous Lifecycle / ContainerConf, Februar 2021, online: Vortrag von Benjamin Tokgöz (@benn0rs, Cloud Solution Architect bei Microsoft) & Josef Fuchshuber (@fuchshuber, Director of Quality, Productivity & Innovation bei bei QAware)
== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ==
Abstract: Status quo: Chaos Engineering
Die Prinzipien des Chaos Engineering sind nicht neu. Beim Chaos Engineering werden Experimente am „lebenden System” durchgeführt. Es werden Ausfälle absichtlich herbeigerufen oder Systeme in widrigste Umstände gebracht. Immer mit dem Ziel Schwachstellen zu finden, frühzeitig zu beheben und dadurch stabilere Systeme und Vertrauen in das System zu bekommen.
Durch den Einzug von Microservice-Architekturen und die damit verbundene Vervielfältigung des Verteilungsgrades hat sich die Daseinsberechtigung für Chaos Engineering dramatisch erhöht. Denn die Komplexität des Runtime-Layers kann bei Microservice-Architekturen sehr schnell ins Unermessliche führen.
Dieser Talk führt in die Prinzipien des Chaos Engineering ein und zeigt den aktuellen Stand der Werkzeuge mit denen Experimente an Cloud-Native-Plattformen und -Applikationen durchgeführt werden können.
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierter Enterprise-Computing-Lösungen geht. Das gilt zumindest immer dann, wenn die Anwendung als Monolith in einem Application-Server deployt werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so mit Hilfe von Nebenprojekten wie Eclipse MicroProfile den Anforderungen moderner Cloud-Native-Anwendungen gerecht zu werden. Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien, aka Serverless, eine gute Figur macht.
http://www.opitz-consulting.com/go/3-6-11 --- Softwareentwicklung, -test und -betrieb können durch Virtualisierung viele Vorteile erzielen. In diesem Zusammenhang werden häufig Werkzeuge für die Bereitstellung von Umgebungen eingesetzt. Verschiedene Werkzeuge adressieren aber unterschiedliche Einsatzszenarien. Wo im Applikationslebenszyklus können diese Werkzeuge sinnvoll eingesetzt werden und wie sieht es mit Kosten und Nutzen aus? ---- Unser Senior Software Architect Richard Attermeyer stellte bei der W Jax am 5.11.2014 in München die Tools Vagrant, Puppet und Docker im Einzelnen vor und erläuterte ihren Nutzen anhand von Use Cases und Live Demos. ---- Weitere Infos: https://jax.de/wjax2014/sessions/vagrant-puppet-docker-fuer-entwickler-und-architekten ---- Über uns: Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.---- Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10 ---- Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874 ---- Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Java scheint mit seinem Memory- und Runtime-Overhead in Zeiten von Cloud-native und Serverless nicht wirklich gut für die Zukunft gerüstet. Erschwerend kommt hinzu, dass viele auf Java basierende Frameworks mit Annotation Scanning, Aufbau von Proxies und Caches das Start- und Speicherverhalten weiter negativ beeinflussen. Bedeutet das das Aus für Java in der Wunderwelt der Cloud? Mitnichten! Projekte wie Quarkus versuchen, Java in der Cloud zur Numero Uno werden zu lassen. Und das auf beeindruckende Art und Weise. Die Session zeigt anhand praktischer Beispiele, was heute bereits möglich ist.
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer InfrastrukturQAware GmbH
JAX 2017, Mainz: Vortrag von Josef Fuchshuber (@fuchshuber, Cheftechnologe bei QAware) und Tobias Placht (@knacht, Software Ingenieur bei QAware).
Abstract: Wie oft kannst du ein neues Feature releasen? Jede Woche? Jeden Tag? Jede Stunde? Continuous Delivery ist einer der wesentlichen Treiber, warum wir Cloud-native Anwendung bauen. Für Software-driven Organisationen ist das der Schlüssel für eine sicherere, stabilere Software bei minimiertem Risiko und kurzen Feedbackschleifen. Die Herausforderung dabei ist, aus jeder Codeänderung möglichst schnell eine lauffähige und gründlich getestete Software zu machen. Das ist für viele Firmen ein wesentlicher Wettbewerbsvorteil. Wir zeigen in diesem Vortrag eine Werkzeugkette, mit der Continuous Delivery nicht nur für Cloud-native Anwendungen, sondern auch auf Cloud-nativer Infrastruktur möglich ist. Ganz im Gedanken von „Everything is Code“ betrachten wir dabei nicht nur das Bauen und Testen von Software, sondern auch die Automatisierung der Infrastrukturbereitstellung, der Deployments und Roll-outs. Dabei treffen alte Bekannte (z.B. Jenkins, SonarQube) auf Cloud-Computing-Technologien wie z.B. Docker für Betriebssystemvirtualisierung und DC/OS für das Clustermanagement.
Testgetriebene Entwicklung mit Jasmine und Karma hat sich mittlerweile schon als defacto-Standard etabliert. Routinen ohne Abhängigkeiten lassen sich damit ohne Probleme testen. Die Schwierigkeiten beginnen jedoch schon, wenn es um die Auflösung von Abhängigkeiten geht. In diesem Vortrag werden verschiedene Strategien und Werkzeuge vorgestellt, mit denen Abhängigkeiten zu Objekten und Funktionen oder zum Server abgedeckt werden können. Aber nicht nur Abhängigkeiten stellen Schwierigkeiten bei der testgetriebenen Entwicklung dar, auch der Umgang mit Fixtures ist bei der testgetriebenen Entwicklung mit JavaScript relevant. Abgerundet wird dieser Vortrag mit einigen Best Practices für die testgetriebenen Entwicklung mit JavaScript.
Continuous Lifecycle / ContainerConf, Februar 2021, online: Vortrag von Benjamin Tokgöz (@benn0rs, Cloud Solution Architect bei Microsoft) & Josef Fuchshuber (@fuchshuber, Director of Quality, Productivity & Innovation bei bei QAware)
== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ==
Abstract: Status quo: Chaos Engineering
Die Prinzipien des Chaos Engineering sind nicht neu. Beim Chaos Engineering werden Experimente am „lebenden System” durchgeführt. Es werden Ausfälle absichtlich herbeigerufen oder Systeme in widrigste Umstände gebracht. Immer mit dem Ziel Schwachstellen zu finden, frühzeitig zu beheben und dadurch stabilere Systeme und Vertrauen in das System zu bekommen.
Durch den Einzug von Microservice-Architekturen und die damit verbundene Vervielfältigung des Verteilungsgrades hat sich die Daseinsberechtigung für Chaos Engineering dramatisch erhöht. Denn die Komplexität des Runtime-Layers kann bei Microservice-Architekturen sehr schnell ins Unermessliche führen.
Dieser Talk führt in die Prinzipien des Chaos Engineering ein und zeigt den aktuellen Stand der Werkzeuge mit denen Experimente an Cloud-Native-Plattformen und -Applikationen durchgeführt werden können.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
The Architecture Gathering 2018, München: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware)
Abstract:
Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise-Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.
Im alltäglichen Einsatz verwenden wir eine potentiell steigende Anzahl an immer größeren Bibliotheken. Diese helfen uns schneller und effizienter unsere Ziele zu erreichen, werden ständig gewartet und ersparen nebenbei auch jede Menge Fehlerlösungs- und Dokumentationsaufwand. Gleichzeitig bedeuten sie jedoch einen unmittelbar höheren Aufwand für das Build und Dependency Management. Wie bekommt man dieses Problem in den Griff?
In der letzten Dekade hat das BuildSystem CMake diesbezüglich große Fortschritte bei der schnellen und alltäglichen Wiederverwendbarkeit von C++ Code bewirkt. So fördert zum Beispiel die Unabhängigkeit von spezifischen BuildSystemen zusammen mit Git und innovativen Hostern wie GitHub insbesondere die Entstehung und Verwendung von OpenSource
Software. Wie sieht die Zukunft aus?
Dependency Manager wie biicode zeigen einen noch komfortableren Weg auf, mit eigenem oder Drittanbieter Code zu arbeiten. Download, Build und Einbindung von Dependencies wird damit so einfach wie das Installieren einer App aus dem AppShop. Doch welche Vor- und Nachteile hat dieses System? Welche Alternativen gibt es?
Steinzeit war gestern! Wege der cloud-nativen EvolutionQAware GmbH
Continuous Lifecycle 2018, Mannheim: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware)
=== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ===
Abstract:
Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.
Slides from the DevOps day in Bern. The slidedeck covers basic DevOps but concentrates on Feature Teams, where DevOps is an enabler and integration technique.
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Docker und Kubernetes Patterns & Anti-PatternsQAware GmbH
JavaLand 2018, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware).
Abstract:
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & CoOPEN KNOWLEDGE GmbH
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierte Enterprise Computing Lösungen geht. Dies gilt zumindest immer dann, wenn die Anwendung als Monolithen in einem Application Server deployed werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so, mit Hilfe von Side-Projekten wie dem Eclipse MicroProfile, den Anforderungen moderner Cloud Native Anwendungen gerecht zu werden.
Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien aka Serverless, eine gute Figur macht.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
JCON 2018, Düsseldorf: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware)
Abstract:
Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die CloudOPEN KNOWLEDGE GmbH
Cloud is the new normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer, cloudspezifischer Architekturmuster? Was unterscheidet dabei die verschiedenen As-a-Service-Varianten (IaaS, PaaS, BaaS und FaaS) voneinander und für welchen Anwendungsfall nimmt man was? Fragen über Fragen – aber keine Panik, der Talk liefert Antworten.
„Bekommen Sie Ihre SQL Datenbank unter Kontrolle”
Ein Großteil des existierenden .NET Codes steht unter Quellcodeverwaltung und bereits heute verwenden viele Anwendungsentwickler irgendeine Form von Continuous Integration. Die Datenbankentwickler hängen an dieser Stelle leider ein wenig hinterher. Dabei sind gerade die Daten das Herzstück einer Anwendung und Änderungen an Datenbankstrukturen daher besonders komplex. Der erste Schritt um eine Verbesserung herbeizuführen ist es, die Datenbank ebenfalls unter Quellcodeverwaltung zu stellen. Das erleichtert nicht nur die Zusammenarbeit mit anderen Teammitgliedern und ermöglicht ein einfacheres Deployment, sondern es bildet auch die Grundlage für Continuous Integration, sowie automatisiertes Testing.
Dieser User-Group Abend zeigt:
* wie man seine SQL Datenbank genauso einfach in die Quellcodeverwaltung bringt wie .NET Code
* wie man seine Datenbank direkt aus der Quellcodeverwaltung heraus deployen kann und
* wie man einen ersten Schritt in Richtung Continous Integration machen kann
Kaps - Es muss nicht immer Kubernetes seinStephan Kaps
In vielen größeren Institutionen gibt es noch jede Menge Software, die eher monolithisch aufgebaut ist, die häufig in Applikation-Servern auf dedizierten virtuellen Maschinen von einem eher klassisch aufgestellten und organisatorisch separierten IT-Betrieb betrieben wird. In Fachzeitschriften, Online-Artikeln und Konferenzen wird vorgeführt, wie einfach es doch ist, einen Hello-World Spring Boot Microservice mit mehreren Instanzen auf Kubernetes zu deployen. Doch zurück im Unternehmen wird klar: sollte man es tatsächlich schaffen, alle notwendigen Personen davon zu überzeugen, ab sofort Kubernetes einzuführen, wird das für einen meist auch personell am Limit arbeitenden IT-Betrieb schnell zu einem Projekt mit vermutlich 1-2 Jahren Laufzeit (je nach Erfahrung), mit möglichen Seiteneffekten wie reduzierter Handlungsfähigkeit für das laufende Geschäft und dem Zurückstellen anderer Modernisierungsmaßnahmen. In diesem Vortrag werden wir die sich kontinuierlich entwickelnde (evolving) Architektur einer Anwendungslandschaft hin zu Cloud Native betrachten und dabei (OpenSource) Werkzeuge kennen lernen für die schrittweise Anpassung der on-premise Infrastruktur, ohne Kubernetes.
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“OPEN KNOWLEDGE GmbH
„Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer Cloud-spezifischer Architekturmuster? Wie kann uns das Cloud Maturity Model dabei helfen? Und was steckt eigentlich hinter Akronymen wie IaaS, PaaS, BaaS, SaaS und FaaS?
Im Rahmen des Worskhops werde ich eine klassische Enterprise Anwendung Schritt für Schritt in die Cloud migrieren und dabei die verschiedenen Stufen / Reifegrade des Cloud Maturity Models durchlaufen. Angefangen bei "Lift & Shift" bis hin zu "Cloud Native" und "Cloud Voodoo – aka Serverless".
Continuous Integration wird längst in vielen Projekten praktiziert. Kein Wunder, steht für das Tooling doch in vielen Fällen ein Jenkins oder Travis zur Verfügung. Mit GitLab CI ist dies jedoch nicht mehr nötig. Schritt für Schritt wird in dieser Session eine Pipeline mit verschiedenen Test- und Analysetools aufgesetzt -- zur Integration in neue und bestehende Projekte.
Production-ready Infrastruktur in 3 WochenAndré Goliath
Es gibt sie doch noch: Projekte die man auf der grünen Wiese starten darf - incl. Infrastruktur. Nur AWS als Cloud Provider ist gesetzt. In dieser Session gebe ich nach den ersten Wochen Einblicke und Lessons Learned, wie wir vom Zustand eines weißen Blatt Papiers auf ein Account- und Infrastruktur-Setup gekommen sind, mit dem wir zumindest mal sofort loslegen können ohne die üblichen „Abkürzungen“ bei Qualität und Featureumfang zu gehen. Ein wesentlicher Teil davon ist das Tooling von gruntwork.io, welches in diesem Kontext kurz vorgestellt wird. [Disclaimer: Wir sind auch nur normale Kunden mit einer gruntworks-Subscription ohne weitere Connections dorthin – diese Session wird also explizit keine gruntwork.io Werbeveranstaltung, auch wenn sich das inhaltlich nicht 100%ig vermeiden lässt]
Slides from the Softwerkskammer Chemnitz meetup on Tuesday, 14th of September on
- chaos engineering
- software resilience
- resilience patterns
- execution of chaos experiments
- creation of chaos backlog
- finding weaknesses in your service landscape
- dark debt
- grey failure
Was Software-Entwickler von der Raumfahrt lernen könnenRamon Anger
Das ist das Slidedeck aus dem Meetup der Softwerkskammer Chemnitz vom 12.01.2021 zum Thema "Was Software-Entwickler von der Raumfahrt lernen können". Die Slides setzen sich mit Software-, Prozess- und Bedienfehlern in der Raumfahrt auseinander und zeigen Berührungspunkte zur Software-Entwicklung auf.
Weitere ähnliche Inhalte
Ähnlich wie Chaos Kata Fitnesstraining für DevOps Teams
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
The Architecture Gathering 2018, München: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware)
Abstract:
Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise-Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.
Im alltäglichen Einsatz verwenden wir eine potentiell steigende Anzahl an immer größeren Bibliotheken. Diese helfen uns schneller und effizienter unsere Ziele zu erreichen, werden ständig gewartet und ersparen nebenbei auch jede Menge Fehlerlösungs- und Dokumentationsaufwand. Gleichzeitig bedeuten sie jedoch einen unmittelbar höheren Aufwand für das Build und Dependency Management. Wie bekommt man dieses Problem in den Griff?
In der letzten Dekade hat das BuildSystem CMake diesbezüglich große Fortschritte bei der schnellen und alltäglichen Wiederverwendbarkeit von C++ Code bewirkt. So fördert zum Beispiel die Unabhängigkeit von spezifischen BuildSystemen zusammen mit Git und innovativen Hostern wie GitHub insbesondere die Entstehung und Verwendung von OpenSource
Software. Wie sieht die Zukunft aus?
Dependency Manager wie biicode zeigen einen noch komfortableren Weg auf, mit eigenem oder Drittanbieter Code zu arbeiten. Download, Build und Einbindung von Dependencies wird damit so einfach wie das Installieren einer App aus dem AppShop. Doch welche Vor- und Nachteile hat dieses System? Welche Alternativen gibt es?
Steinzeit war gestern! Wege der cloud-nativen EvolutionQAware GmbH
Continuous Lifecycle 2018, Mannheim: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware)
=== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ===
Abstract:
Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.
Slides from the DevOps day in Bern. The slidedeck covers basic DevOps but concentrates on Feature Teams, where DevOps is an enabler and integration technique.
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Docker und Kubernetes Patterns & Anti-PatternsQAware GmbH
JavaLand 2018, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware).
Abstract:
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & CoOPEN KNOWLEDGE GmbH
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierte Enterprise Computing Lösungen geht. Dies gilt zumindest immer dann, wenn die Anwendung als Monolithen in einem Application Server deployed werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so, mit Hilfe von Side-Projekten wie dem Eclipse MicroProfile, den Anforderungen moderner Cloud Native Anwendungen gerecht zu werden.
Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien aka Serverless, eine gute Figur macht.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
JCON 2018, Düsseldorf: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware)
Abstract:
Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die CloudOPEN KNOWLEDGE GmbH
Cloud is the new normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer, cloudspezifischer Architekturmuster? Was unterscheidet dabei die verschiedenen As-a-Service-Varianten (IaaS, PaaS, BaaS und FaaS) voneinander und für welchen Anwendungsfall nimmt man was? Fragen über Fragen – aber keine Panik, der Talk liefert Antworten.
„Bekommen Sie Ihre SQL Datenbank unter Kontrolle”
Ein Großteil des existierenden .NET Codes steht unter Quellcodeverwaltung und bereits heute verwenden viele Anwendungsentwickler irgendeine Form von Continuous Integration. Die Datenbankentwickler hängen an dieser Stelle leider ein wenig hinterher. Dabei sind gerade die Daten das Herzstück einer Anwendung und Änderungen an Datenbankstrukturen daher besonders komplex. Der erste Schritt um eine Verbesserung herbeizuführen ist es, die Datenbank ebenfalls unter Quellcodeverwaltung zu stellen. Das erleichtert nicht nur die Zusammenarbeit mit anderen Teammitgliedern und ermöglicht ein einfacheres Deployment, sondern es bildet auch die Grundlage für Continuous Integration, sowie automatisiertes Testing.
Dieser User-Group Abend zeigt:
* wie man seine SQL Datenbank genauso einfach in die Quellcodeverwaltung bringt wie .NET Code
* wie man seine Datenbank direkt aus der Quellcodeverwaltung heraus deployen kann und
* wie man einen ersten Schritt in Richtung Continous Integration machen kann
Kaps - Es muss nicht immer Kubernetes seinStephan Kaps
In vielen größeren Institutionen gibt es noch jede Menge Software, die eher monolithisch aufgebaut ist, die häufig in Applikation-Servern auf dedizierten virtuellen Maschinen von einem eher klassisch aufgestellten und organisatorisch separierten IT-Betrieb betrieben wird. In Fachzeitschriften, Online-Artikeln und Konferenzen wird vorgeführt, wie einfach es doch ist, einen Hello-World Spring Boot Microservice mit mehreren Instanzen auf Kubernetes zu deployen. Doch zurück im Unternehmen wird klar: sollte man es tatsächlich schaffen, alle notwendigen Personen davon zu überzeugen, ab sofort Kubernetes einzuführen, wird das für einen meist auch personell am Limit arbeitenden IT-Betrieb schnell zu einem Projekt mit vermutlich 1-2 Jahren Laufzeit (je nach Erfahrung), mit möglichen Seiteneffekten wie reduzierter Handlungsfähigkeit für das laufende Geschäft und dem Zurückstellen anderer Modernisierungsmaßnahmen. In diesem Vortrag werden wir die sich kontinuierlich entwickelnde (evolving) Architektur einer Anwendungslandschaft hin zu Cloud Native betrachten und dabei (OpenSource) Werkzeuge kennen lernen für die schrittweise Anpassung der on-premise Infrastruktur, ohne Kubernetes.
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“OPEN KNOWLEDGE GmbH
„Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer Cloud-spezifischer Architekturmuster? Wie kann uns das Cloud Maturity Model dabei helfen? Und was steckt eigentlich hinter Akronymen wie IaaS, PaaS, BaaS, SaaS und FaaS?
Im Rahmen des Worskhops werde ich eine klassische Enterprise Anwendung Schritt für Schritt in die Cloud migrieren und dabei die verschiedenen Stufen / Reifegrade des Cloud Maturity Models durchlaufen. Angefangen bei "Lift & Shift" bis hin zu "Cloud Native" und "Cloud Voodoo – aka Serverless".
Continuous Integration wird längst in vielen Projekten praktiziert. Kein Wunder, steht für das Tooling doch in vielen Fällen ein Jenkins oder Travis zur Verfügung. Mit GitLab CI ist dies jedoch nicht mehr nötig. Schritt für Schritt wird in dieser Session eine Pipeline mit verschiedenen Test- und Analysetools aufgesetzt -- zur Integration in neue und bestehende Projekte.
Production-ready Infrastruktur in 3 WochenAndré Goliath
Es gibt sie doch noch: Projekte die man auf der grünen Wiese starten darf - incl. Infrastruktur. Nur AWS als Cloud Provider ist gesetzt. In dieser Session gebe ich nach den ersten Wochen Einblicke und Lessons Learned, wie wir vom Zustand eines weißen Blatt Papiers auf ein Account- und Infrastruktur-Setup gekommen sind, mit dem wir zumindest mal sofort loslegen können ohne die üblichen „Abkürzungen“ bei Qualität und Featureumfang zu gehen. Ein wesentlicher Teil davon ist das Tooling von gruntwork.io, welches in diesem Kontext kurz vorgestellt wird. [Disclaimer: Wir sind auch nur normale Kunden mit einer gruntworks-Subscription ohne weitere Connections dorthin – diese Session wird also explizit keine gruntwork.io Werbeveranstaltung, auch wenn sich das inhaltlich nicht 100%ig vermeiden lässt]
Slides from the Softwerkskammer Chemnitz meetup on Tuesday, 14th of September on
- chaos engineering
- software resilience
- resilience patterns
- execution of chaos experiments
- creation of chaos backlog
- finding weaknesses in your service landscape
- dark debt
- grey failure
Was Software-Entwickler von der Raumfahrt lernen könnenRamon Anger
Das ist das Slidedeck aus dem Meetup der Softwerkskammer Chemnitz vom 12.01.2021 zum Thema "Was Software-Entwickler von der Raumfahrt lernen können". Die Slides setzen sich mit Software-, Prozess- und Bedienfehlern in der Raumfahrt auseinander und zeigen Berührungspunkte zur Software-Entwicklung auf.
Mob Programming - Ein ErfahrungsberichtRamon Anger
Slides der ersten Meetup Session der Softwerkskammer Chemnitz am 17.03.2020.
In der Session erfahrt ihr einiges über Mob Programming, Remote Mob Programming, wie ihr den Flow beim Mobben aufrecht erhalten könnt, wie ihr eure Chefs davon überzeugen könnt, Mob Programming durchzuführen und wie im Idealfall euer Arbeitsplatz für gemeinsame Mobbing Sessions aussehen sollte.
The document outlines different approaches to either kill or grow architecture. To kill architecture, it recommends hiding behind plans, designing systems yearly, solving problems analytically, creating strict design rules, and fulfilling all customer demands. To grow architecture, it suggests solving problems systemically, practicing design continuously, proving ideas through trial and error, responding to changing needs, balancing design and customers, and mastering best practices. The overall message is that architecture and design benefit from an agile mindset that embraces flexibility and continuous improvement.
Where are all transactions gone? Was in_der_cloud_alles_verboten_istRamon Anger
Mein Vortrag auf der OOP 2015
Where all the transactions gone?
Was in der Cloud alles verboten ist.
Gegenstand des Vortrags sind neun Dinge, die in der Cloud im Gegensatz zu inhouse-Anwendungen grundlegend anders sind. Darüber hinaus geht der Vortrag kurz auf DevOps für die Cloud und Organisation für die Cloud ein.
Ursprünglich hat mein Kollege Marc Bauer den Vorschlag eingereicht, hatte dann aber leider keine Möglichkeit, den Vortrag selbst zu halten.
Slidedeck meines Vortrags auf den Berlin Days of Softwareengineering am 07.10.2014
Slidedeck of my talk at Berlin Days of Softwareengineering on 2014.10.07
4. Früher. Ganz früher
wurden Release gemalt
1-2 Releases pro Jahr
NEVER TOUCH A RUNNING SYSTEM!
NEVER CHANGE A RUNNING SYSTEM!
Rembrandt und Saskia im Gleichnis vom verlorenen Sohn. (1635/36), gemeinfrei
5. Copyright JD Hancock, licensed under a Creative Commons Attribution 3.0
Unported License, http://photos.jdhancock.com/photo/2010-06-30-223624-the-
pride-of-one.html
Dann wechselte das
Wetter.
Schneller (besser sofort) liefern:
sicherer, skalierbarer
besser wartbar/betreibbar
näher am Betriebssystem
6. Dann wechselte das
Wetter.
Schneller (besser sofort) liefern:
sicherer, skalierbarer
besser wartbar/betreibbar
näher am Betriebssystem
Copyright JD Hancock, licensed under a Creative Commons Attribution 3.0
Unported License, http://photos.jdhancock.com/photo/2010-06-30-223624-the-
pride-of-one.html
Und das in deutlich
komplexeren Systemen
8. Wie gehen die großen Player
mit Ausfällen um?
Gibt es da überhaupt
Ausfälle?
https://status.aws.amazon.com/ am 11.09.2019
https://developers.facebook.com/status/dashboard/ am 11.09.2019
9. Everything
fails all the
time! Werner Vogels (CTO Amazon):
… Everything fails all the
time.
We lose whole datacenters!
Those things happen…
10. Everything
fails all the
time! Werner Vogels (CTO Amazon):
… Everything fails all the
time.
We lose whole datacenters!
Those things happen…
Und warum?
14. Technical Dept
* kann aufgebaut werden
* im Code sichtbar
* durch Refactoring entfernen
* Fehler beim Zusammenspiel von
Komponenten
* nicht auf Code beschränkt
* kann bedingt bewusst aufgebaut werden
* kann „überall“ auftreten
* Auswirkungen in komplexen Systemen
sichtbar
Dark Dept
17. Es geht immer
irgendwie um
Resilience
Resilience:
* Elastizität
* Widerstandsfähigkeit
* Wiederanlauffähigkeit
Betroffen:
* Organisation
* IT-System
https://pxhere.com/en/photo/865929, gemeinfrei
18. Es geht immer
irgendwie um
Resilience
Resilience Muster/Lösungen:
* Redundancy
* Auto scaling
* Immutable infrastructure
* Statelessness
* Backoff algorithms
* Timeout
* Idempotent operations
* Service degradation
* Fallback
* Rejection
* Circuit breaker
* Health check
* Caching caching
* Bulkhead
* Loose coupling
* Self-containment
* Fail fast
* Bounded queues
* Shed Load
* Monitoring
https://pxhere.com/en/photo/865929, gemeinfrei
19. Chaos
Engineering
Services sind gut getestet
Integration der Services ist hart/
komplex/mit Überraschung verbunden
Integration im Cloud-Zeitalter
funktioniert anders als in der
„IT-Steinzeit“
Find the hard to find bugs
Quelle: https://news.cornell.edu/stories/2019/03/help-ai-microservices-divvy-tasks-improve-cloud-apps
https://pixabay.com/de/photos/hammer-nagel-geb%C3%A4ude-tool-arbeit-3717210/
20. Geschichten die das
Entwicklerleben schreiben …
* Chaos Monkey mal eben in
Produktion starten und schauen
was passiert
* Prod-DB stoppen und erwarten,
dass die Standby-DB übernimmt
* LoadBalancer überbrücken und
alle Anfragen auf einen einzelnen
Prod-Server leiten (Lastprüfung)
Chaos
Engineering
done wrong
21. … ohne die Aktion vorher
kommuniziert zu haben!
Chaos
Engineering
done wrong
Geschichten die das
Entwicklerleben schreiben …
* Chaos Monkey mal eben in
Produktion starten und schauen
was passiert
* Prod-DB stoppen und erwarten,
dass die Standby-DB übernimmt
* LoadBalancer überbrücken und
alle Anfragen auf einen einzelnen
Prod-Server leiten (Lastprüfung)
27. Chaos
Hypothesis
Backlog
1. Bilde System / Service
Architektur ab
2. Suche potentielle Fehlstellen
3. Stelle Hypothesen zum
Verhalten auf
A. (Fast) sicheres Wissen
B. Idee/Vermutung
4. Bewerten
A. Schaden
B. Wahrscheinlichkeit
Ergebnis: Backlog
—> Priorisieren
—> Pflegen/Aktualisieren
BacklogSystem Architektur Problem/
Experiment
28. Chaos
Experiment
1. Wähle Hypothese aus Backlog
2. Starte mit stabilem System
3. Erzeuge Fehlerfall
4. Vergleiche Hypothese mit
gemessener Systemreaktion
5. Ziehe Konsequenzen aus dem
Ergebnis
A. Code/Konfiguration/
Architektur
B. Automatisieren
C. Betriebshandbuch
D. Nihil
http://principlesofchaos.org
29. Chaos
Experiment
1. Wähle Hypothese aus Backlog
2. Starte mit stabilem System
3. Erzeuge Fehlerfall
4. Vergleiche Hypothese mit
gemessener Systemreaktion
5. Ziehe Konsequenzen aus dem
Ergebnis
A. Code/Konfiguration/
Architektur
B. Automatisieren
C. Betriebshandbuch
D. Nihil
http://principlesofchaos.org
[Muss natürlich
vorbereitet und
kommuniziert werden]
32. Tools kennen und anwenden
• Git
• Jenkins, Gitlab
• Docker
• Kubernetes
• Puppet, Chef, Ansible …
Verändere eine einzelne Codezeile
• mit sichtbarem Output in App
• die nur einmal ausgeführt wird
• in potentiellem Performance
Bottleneck
• in Infrastruktur-Automation
und deploye die Änderung
DevOps Kata
33. Tools kennen und anwenden
• Git
• Jenkins, Gitlab
• Docker
• Kubernetes
• Puppet, Chef, Ansible …
Verändere eine einzelne Codezeile
• mit sichtbarem Output in App
• die nur einmal ausgeführt wird
• in potentiellem Performance
Bottleneck
• in Infrastruktur-Automation
und deploye die Änderung
DevOps Kata
Kenne deine Tools
Kenne deine Umgebung
34. Tools kennen und anwenden
• Git
• Jenkins, Gitlab
• Docker
• Kubernetes
• Puppet, Chef, Ansible …
Verändere eine einzelne Codezeile
• mit sichtbarem Output in App
• die nur einmal ausgeführt wird
• in potentiellem Performance
Bottleneck
• in Infrastruktur-Automation
und deploye die Änderung
DevOps Kata
Kenne deine Tools
Kenne deine Umgebung
Experimente?
Experimente in der Organisation?
36. Game Day
Ein Experiment zu einer Zeit an
einem Ort
1. Ziel definieren
Welches Ergebnis wird erwartet?
2. Experiment vorbereiten
Umgebung, Test(s) vorbereiten
Rollen/Aufgaben verteilen
3. Zeitpunkt/Ziel kommunizieren!
4. Experiment durchführen
Annahmen validieren
5. Auswerten
6. Maßnahmen definieren
Chaos Kata
https://de.slideshare.net/BilalAybar/chaos-engineering-gameday-on-aws
Experiment in der Organisation
* DevOps Team
* Bad Guy
* IT Operations?
* Andere Beteiligte?
37. Game Day
Ein Experiment zu einer Zeit an
einem Ort
1. Ziel definieren
Welches Ergebnis wird erwartet?
2. Experiment vorbereiten
Umgebung, Test(s) vorbereiten
Rollen/Aufgaben verteilen
3. Zeitpunkt/Ziel kommunizieren!
4. Experiment durchführen
Annahmen validieren
5. Auswerten
6. Maßnahmen definieren
Chaos Kata
https://de.slideshare.net/BilalAybar/chaos-engineering-gameday-on-aws
[Wie hat das Team agiert?
War die Auswirkung überhaupt
sichtbar?]
Experiment in der Organisation
* DevOps Team
* Bad Guy
* IT Operations?
* Andere Beteiligte?
40. Experiment: Adressservice unter
Hochlast
Webservice zur Gültigkeitsprüfung
von Adressen …
Ziel: 10.000 Service-Anfragen pro
Sekunde per Lasttreiber über API-
Gateway; 30 Sekunden lang
Scope: Einzelne Instanz, Pre-
Production
Erwartungshaltung:
Service verarbeitet Last ohne
Fehler 503 (unavailable) zurück
zuliefern
Anfragen an DataStore werden zu
über 95% aus Cache beantwortet
Gestiegene Last ist per
Monitoring deutlich sichtbar
Chaos Kata
Experiment am Code (Service)
41. Experiment: Adressservice unter
Hochlast
Webservice zur Gültigkeitsprüfung
von Adressen …
Ergebnis:
Service liefert in den ersten
sechs Sekunden 23.938 mal 503
(unavailable) zurück
Anfragen an DataStore wurden in
den ersten sechs Sekunden zu
42.3% aus Cache beantwortet
Gestiegene Last in den ersten
sechs Sekunden per Monitoring
deutlich sichtbar (Lastanstieg
gegenüber Normal 452%)
Chaos Kata
Experiment am Code (Service)
42. Experiment: Adressservice unter
Hochlast
Webservice zur Gültigkeitsprüfung
von Adressen …
Ergebnis:
Service liefert in den ersten
sechs Sekunden 23.938 mal 503
(unavailable) zurück
Anfragen an DataStore wurden in
den ersten sechs Sekunden zu
42.3% aus Cache beantwortet
Gestiegene Last in den ersten
sechs Sekunden per Monitoring
deutlich sichtbar (Lastanstieg
gegenüber Normal 452%)
API-Gateway nach sechs Sekunden
abgestürzt; innerhalb der
verbleibenden 24 Sekunden nicht
wieder verfügbar
Automatischer Neustart des API-
Gateway 42 Sekunden nach Absturz
Chaos Kata
Experiment am Code (Service)
43. Experiment: Adressservice unter
Hochlast
Webservice zur Gültigkeitsprüfung
von Adressen …
Maßnahmen:
Pufferungs-Strategie für
Adressservice prüfen
Caching-Strategie DataStore
prüfen
Backup-Strategie API-Gateway
untersuchen
Wiederanlaufdauer API-Gateway
Instanz prüfen
Automatisierung des Experiments
für CI prüfen
Chaos Kata
Experiment am Code (Service)
44. Experiment: Adressservice unter
Hochlast
Webservice zur Gültigkeitsprüfung
von Adressen …
Maßnahmen:
Pufferungs-Strategie für
Adressservice prüfen
Caching-Strategie DataStore
prüfen
Backup-Strategie API-Gateway
untersuchen
Wiederanlaufdauer API-Gateway
Instanz prüfen
Automatisierung des Experiments
für CI prüfen
Chaos Kata
Experiment am Code (Service)
Maßnahmen priorisieren und
einzeln prüfen
Lösungen einzeln umsetzen
Experiment mit Einzellösung
wiederholen
<— Kata
45. Chaos Kata gewöhnen uns an
potentielle Incidents
Headless Chicken Mode bleibt aus
Zusammenarbeit zwischen
Beteiligten ist erprobt
Wissen, wo man hinschauen muss
Erfahrung ermöglicht schnellen
Wechsel in Lösungsmodus
Chaos Kata
Experiment am Code (Service)
47. Chaos Paranoia Muss das alles geprüft werden?
1. Risikobewertung
2. Priorisierung
<— gehört bereits zum Chaos
Hypothesis Backlog
48.
49. Smyte Acquisition by Twitter
on 21.06.2018
San Francisco-based startup
that provides companies with
tools to alleviate trolling,
spam, harassment and improve
security
… A vendor notified us of
their acquisition at 6am
this morning and shut down
their APIs 30 minutes later,
creating a production outage
for npm (package publishes
and user registrations) …
… it appears that some
customers have been shut out
of smyte's API immediately,
without prior warning