Tweet
Tweet

Slide 1

Slide 1 text

Michael Wittig | tecRacer Agile Banking mit DevOps und AWS

Slide 2

Slide 2 text

• Software Entwickler • widdix GmbH • AWS Cloud Architekt • tecRacer • IT Infrastruktur Migration der ersten deutschen Bank nach AWS • Hintergrund im algorithmischen Handel und der Zeitreihenanalyse Michael Wittig

Slide 3

Slide 3 text

• Ausgangssituation • Strategie • Umsetzung • Probleme • Fazit Agenda

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

• On-Premise / Colocation • Patch-Management • Log-Management • Monitoring • Deployment Operations

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

• 2 x im Jahr Release • hohes Risiko • viele Fehler werden erst in Testphase entdeckt • lange Testphasen • Code mehrere Wochen nicht funktionstüchtig • SVN wird als Code-Backup benutzt • eine große JavaEE Anwendung • Kernbanksystem Development

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

• Ausgangssituation • Strategie • Umsetzung • Probleme • Fazit Agenda

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

Grenzen sind nicht zu denken ohne ein Dahinter, setzen also die Möglichkeit des Überschreitens voraus.

Slide 14

Slide 14 text

Wir gehen davon aus, dass nicht alles so bleiben wird, wie es ist.

Slide 15

Slide 15 text

Unser Ziel ist eine von Menschen überwachte, von sich selbst betriebene IT.

Slide 16

Slide 16 text

Wir unterstützen ein sprunghaftes Kundenwachstum.

Slide 17

Slide 17 text

Time-To-Market von Stunden und nicht Jahren.

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

• ist in der Lage ihren Betrieb zu überwachen und aufrecht zu erhalten. • muss nie komplett ausgeschaltet werden. • läuft verteilt an mindestens zwei Orten. • wird als sich änderndes System begriffen dessen Kommunikationsströme einer starken Schwankung unterliegen. • kann sprunghaftes Kundenwachstum verarbeiten. • Der aktuelle Zustand der Plattform (Status quo) wird bei der Konzeption nicht limitierend berücksichtigt. Die Plattform…

Slide 20

Slide 20 text

• Ausgangssituation • Strategie • Umsetzung • Probleme • Fazit Agenda

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

• Git Workflow • privates (Maven / rpm / npm) Repo • Jenkins Workflow • You built it, you own it! • wöchentliches Release durch Entwickler • Micro-Services • Amazon Web Services 2x7 Einblicke

Slide 23

Slide 23 text

• zwei Ansätze • aus master muss immer released werden können • Version := Tag • Feature := Branch • Feature-Branch kann via Jenkins auf Testsystem deployed werden • master -> early -> live • early wird automatisch auf Testsystem deployed • aus live muss immer released werden können • Version := Tag • Feature := Branch • Pull-Requests • Tool Git Workflow

Slide 24

Slide 24 text

• Jedes Release hat eine unveränderliche Versionsnummer • Do One Thing and Do It Well • orchestrieren: ls -l | awk '{print $3}' | sort | uniq -c • Code auslagern in Bibliotheken • keine Breaking Changes… • ...aber @Deprecated muss nur 4 Wochen supportet werden privates (Maven / rpm / npm) Repo

Slide 25

Slide 25 text

• bei Commit • bauen • analysieren • testen • zeitgesteuert • Integrationstest • manuell • Release • Integrationstest • Testumgebung provisionieren • automate it! Jenkins Workflow

Slide 26

Slide 26 text

• Entwickler entscheiden, welche Technologien benutzt werden • mindestens zwei Experten • aktiv in Mailinglisten • Expertenwissen aufbauen • Aktualisierung bei neuen Version • Verantwortlich für Betrieb • Logging, Monitoring, Backup • Verantwortlich für Release • Packaging, Testing, Deployment • Standards vorhanden und können genutzt werden • Lose Kopplung zwischen Service, Technologie, Entwicklerteam You built it, you own it!

Slide 27

Slide 27 text

• Ablauf • Dienstag Mittag: Release • Dienstag Mittag: Deployment auf staging Testumgebung • Dienstag Nachmittag: technische Tests (Abnahme) • Mittwoch: fachliche Tests (Abnahme) • Mittwoch Abend: Deployment auf Produktion • ermutigt Entwickler dazu, in kleinen Schritten zu entwickeln • reduziert Deployment Risiko • beugt endlosen Features vor • enge Feedback-Schleife wöchentliches Release durch Entwickler

Slide 28

Slide 28 text

enge Feedback-Schleife Entwicklung Test Deployment Kunden- Feedback

Slide 29

Slide 29 text

• ~ 20 Services • Hazelcast • ActiveMQ • versionierte, unveränderliche, JSON Messages • bei Änderung an JSON Struktur wird eine neue Version erzeugt • alte Version wird mindestens 4 Wochen parallel unterstützt • Entkoppelung • Deployment • Entwickler • Technologien • Hystrix Micro-Services

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

• Verlagerung der gesamten Infrastruktur nach AWS • erste Bank in Deutschland • Herausforderung: Datenschutz + Regulierung • Infrastructure as Code • keine manuellen Infrastruktur-Änderungen • Methoden aus der SW Entwicklung • Erhöht Effizienz und Qualität • alles in Git • Peer-Review • Pull-Request • Changes werden durch Jenkins ausgeführt • CloudFormation Amazon Web Services

Slide 32

Slide 32 text

CloudFormation

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

• Immutable & Stateless Server • agile Testumgebungen • automatisierte Integrationstests • staging Testumgebung • Echtzeit Log-Analyse • Echtzeit Monitoring • Dashboard 2x7 Einblicke

Slide 35

Slide 35 text

• Server werden entsorgt wenn sie nicht mehr benötigt werden • Keine Ansammlung von Müll auf einem Server • Elastizität • steigender Load: Server hinzufügen • sinkender Load: Server entfernen • Zustand gehört in eine „Datenbank“ • ermöglicht Ausfallsicherheit • Nutzt Pay-as-you-go Prinzip • Automatisierung • Installation • Configuration Immutable & Stateless Server

Slide 36

Slide 36 text

• temporäre Testumgebungen für Entwickler • keine Kundendaten • wegwerfen nach Nutzung • AWS + Vagrant + Chef agile Testumgebungen

Slide 37

Slide 37 text

• Vagrant + Chef • CentOS • Herausforderungen: Abhängigkeiten? • Wer weiß eigentlich welcher Service mit wem redet? • Code-Analyse • Dependency-Graph in Neo4j • Datenbanken • MongoDB, CouchDB, PostgreSQL, Redis • Plattformen • Java EE (JBoss), Java (Spring), Node.js • JUnit automatisierte Integrationstests

Slide 38

Slide 38 text

• Restriktiver Zugang • Kundendaten • 1-zu-1 Kopie von Produktion • „Öffnungszeiten“ staging Testumgebung

Slide 39

Slide 39 text

• Alerting direkt an verantwortlichen Entwickler • Verkürzung der Reaktionszeit auf Fehler • Durchsuchbare Logs Echtzeit Log-Analyse

Slide 40

Slide 40 text

• Alerting direkt an verantwortlichen Entwickler • Verkürzung der Reaktionszeit auf Fehler • Historie • Änderung nach Release? • Auslastung der Server Echtzeit Monitoring

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

• Unsichtbares sichtbar machen • Inhalt • Redmine-Metriken • offene Bugs, neue Bugs • Git-Metriken • aktive Branches, inaktive Branches • Server-Metriken • Kunden-Metriken • Registrierungen, Transaktionen, Logins • Uptime-Metriken • externe Überwachung Dashboard

Slide 43

Slide 43 text

• Ausgangssituation • Strategie • Umsetzung • Probleme • Fazit Agenda

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

• Wer hat “Lust” auf 24/7 Betrieb? • Dev verschluckt Ops Probleme

Slide 46

Slide 46 text

• Ausgangssituation • Strategie • Umsetzung • Probleme • Fazit Agenda

Slide 47

Slide 47 text

groß denken

Slide 48

Slide 48 text

entkoppeln

Slide 49

Slide 49 text

orchestrieren

Slide 50

Slide 50 text

1. A new system generates new problems, and these problems are bigger than the original problem. 2. Systems tend to grow. 3. Complex systems can not be predicted and produce unexpected outcomes. 4. The system does not do what it says it is doing. 5. Systems get abused. 6. A complex system can fail in an infinite number of ways. 7. Loose systems last longer and work better. avoid systems

Slide 51

Slide 51 text

• Ausgangssituation • Strategie • Umsetzung • Probleme • Fazit Agenda

Slide 52

Slide 52 text

http://manning.com/wittig Michael Wittig [email protected] SaaS Zeitreihendatenbank TimeSeries.Guru 39% Rabatt Code ctwdevopsber