Agile Banking mit DevOps und AWS

Innovation in der Finanzbranche ist technologiegetrieben und erfordert eine Time-To-Market von Stunden und nicht - wie bisher üblich - Jahren. DevOps und Cloud Computing bilden das Fundament, auf dem eine hohe Entwicklungsgeschwindigkeit bei gleichzeitig hoher Qualität und Sicherheit realisiert werden kann. Die Zauberworte dabei heißen automatischer Integrationstest, Infrastructure as Code und agile Testumgebungen. Dieser Vortrag beschreibt praxisnah die Transformation einer Wertpapierhandelsbank von On-Premise nach AWS (Amazon Web Services) und geht dabei auf technische Herausforderungen und den Wandel zu einer DevOps Kultur ein.

Transcript

1. Michael Wittig | tecRacer Agile Banking mit DevOps und AWS
2. • 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
3. • Ausgangssituation • Strategie • Umsetzung • Probleme • Fazit Agenda
5. • On-Premise / Colocation • Patch-Management • Log-Management • Monitoring • Deployment Operations
7. • 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
11. • Ausgangssituation • Strategie • Umsetzung • Probleme • Fazit Agenda
13. Grenzen sind nicht zu denken ohne ein Dahinter, setzen also die Möglichkeit des Überschreitens voraus.
14. Wir gehen davon aus, dass nicht alles so bleiben wird, wie es ist.
15. Unser Ziel ist eine von Menschen überwachte, von sich selbst betriebene IT.
16. Wir unterstützen ein sprunghaftes Kundenwachstum.
17. Time-To-Market von Stunden und nicht Jahren.
19. • 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…
20. • Ausgangssituation • Strategie • Umsetzung • Probleme • Fazit Agenda
22. • 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
23. • 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
24. • 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
25. • bei Commit • bauen • analysieren • testen • zeitgesteuert • Integrationstest • manuell • Release • Integrationstest • Testumgebung provisionieren • automate it! Jenkins Workflow
26. • 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!
27. • 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
28. enge Feedback-Schleife Entwicklung Test Deployment Kunden- Feedback
29. • ~ 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
31. • 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
32. CloudFormation
34. • Immutable & Stateless Server • agile Testumgebungen • automatisierte Integrationstests • staging Testumgebung • Echtzeit Log-Analyse • Echtzeit Monitoring • Dashboard 2x7 Einblicke
35. • 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
36. • temporäre Testumgebungen für Entwickler • keine Kundendaten • wegwerfen nach Nutzung • AWS + Vagrant + Chef agile Testumgebungen
37. • 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
38. • Restriktiver Zugang • Kundendaten • 1-zu-1 Kopie von Produktion • „Öffnungszeiten“ staging Testumgebung
39. • Alerting direkt an verantwortlichen Entwickler • Verkürzung der Reaktionszeit auf Fehler • Durchsuchbare Logs Echtzeit Log-Analyse
40. • Alerting direkt an verantwortlichen Entwickler • Verkürzung der Reaktionszeit auf Fehler • Historie • Änderung nach Release? • Auslastung der Server Echtzeit Monitoring
42. • 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
43. • Ausgangssituation • Strategie • Umsetzung • Probleme • Fazit Agenda
45. • Wer hat “Lust” auf 24/7 Betrieb? • Dev verschluckt Ops Probleme
46. • Ausgangssituation • Strategie • Umsetzung • Probleme • Fazit Agenda
47. groß denken
48. entkoppeln
49. orchestrieren
50. 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
51. • Ausgangssituation • Strategie • Umsetzung • Probleme • Fazit Agenda
52. http://manning.com/wittig Michael Wittig mwittig@tecracer.de SaaS Zeitreihendatenbank TimeSeries.Guru 39% Rabatt Code ctwdevopsber