Entwicklung verteilter Systeme - Herausforderungen nicht nur für die Architektur, BedCon 2015

Jedes Platform wächst mit der Zeit. Mehr Entwickler mit noch mehr Ideen und Vorstellungen arbeiten alle gemeinsam an der Weiterentwicklung.

Das System wird grösser und wird auf viele Systeme verteilt. Häufig wird ein Technologie Stack vorgegeben um es vermeintlich wartbarer und stabiler zu machen. Zusätzlich wird die Software oft dabei von Entwicklung zu QA weitergereicht und am Schluss von Operations deployed und betrieben. Das Ergebnis davon sind lange Releasezyklen und das verschenkte Potenzial weil nicht die richtigen Tools genutzt werden konnten.

Dieser Vortrag erläutert unsere Leitplanken zur Entwicklung verteilter Systeme bei der E-POST. Wie erlauben wir es den 15 Teams mit 100 Personen 'The right tool for the right job' einzusetzen statt ein starres Korsett an Technologien vorzugeben? Welche Rahmenbedingungen müssen beachtet werden und wo kann ein Team autonom entscheiden wie eine Software zu entwickeln ist? Trotz wachsender Anzahl verteilter Systemen und steigender Komplexität wollen wir weiterhin eine stabile Platform zur Verfügung stellen. Es wird erklärt welche Anforderungen wir dabei in den Bereichen Architektur, Entwicklung, Testen, Deployment, Betrieb und Security vorgeben und was die Teams dabei beachten müssen.

Transcript

1. Entwicklung verteilter Systeme Oliver Wehrens, @owehrens E-POST Development GmbH, DPDHL Herausforderungen nicht nur an die Architektur
3. Produkte Cloud Brief Fax Mobile Apps API Grosskunden Einlieferung E-POST Ident E-POST Scan
4. Historie 2008: Start Entwicklung Prototyp mit agilem Vorgehen 2009/2010: Aufbau E-POST Platform mit linearem Vorgehensmodell 2011: Weiter- entwicklung mit agilem Vorgehensmodell 2012: Aufbau EPD in Berlin 2013: Transition neues Architekturkonzept 2014: Produktionszugriff der Teams 2015: Anpassung Organisations- struktur
5. Zahlen, Daten, Fakten
6. ~100 ~150
7. 100 Hosttypen 70 Produktion 30 Dev Infrastuktur
8. ~2000 VMs ~25 Server ~200 VMs ~20 Server Entwicklung Produktion
9. Damals …
10. 2010/2011 4 Deployment / Jahr Entwicklung QA Betrieb
11. 2010/2011 4 Deployment / Jahr Entwicklung QA Betrieb Business
12. Herausforderungen Schnelles Rollout von neuen Features Schnelles Testen von Funktionalität am Markt Es muss einfach sein Fehler zu beheben Flexibilisierung des Technologie-Stacks bei gleichzeitiger Kontrolle
13. –Arc Team @ EPD “Wir wollen eine Architektur in der wir Software jederzeit einfach an neue Bedürfnisse anpassen können.”
14. Entwicklung Organisation Betrieb
15. Entwicklung
16. 3 Schichten Architektur UI Logik Datenbank
17. Monolith UI Logik Datenbank
18. … mit mehr Teams UI Brief Abrechnung Datenbank Kunde Team A Team B
19. … wird schwierig UI Brief Abrechnung Kunde
20. Ein Service bildet genau nur eine Fachlichkeit ab.
21. UI Brief Abrechnung Datenbank UI Kunde Datenbank Team A Team B Bounded Context
22. UI Brief Abrechnung Datenbank UI Kunde Datenbank UI Integration
23. UI Brief Abrechnung Datenbank UI Kunde Datenbank Verteilter Monolith
24. Was kostet Zeit? Kommunikation mit anderen Teams Einarbeitung/Abstimmung im Quellcode Warten auf Zuarbeiten von anderen Teams Warten auf Deployment von anderen Teams Warten auf gemeinsames Deployment Fester Technologiestack
25. Unabhängigkeit.
26. Unabhängigkeit befähigt die Teams Fachlichkeiten effizient und schnell umzusetzen.
27. Datenbank Datenbank Abrechnung Kunde UI
28. Datenbank Datenbank Abrechnung Kunde Stabile Schnittstelle UI
29. Datenbank Schema Datenbank Schema Abrechnung Kunde E-POST DB Setup UI
30. System Migration Abrechnung Kunde Alt Neu ~ 15 Komponenten ~ 55 Komponenten Deployment Architektur
31. Unabhängigkeit … der Traum jedes Entwicklers. “Ich kann machen was ich will.”
32. Abrechnung REST Kunde Thrift Brief Login … SOAP Avro My Own MANAGEMENT SAYS NO.
33. Architektur Entwicklung Deployment Security Testen Betrieb Leitplanken Leitplanken
34. Mikroarchitektur Abrechnung Kunde Brief Team A Team B Team C
35. Mikroarchitektur Kunde Brief Team B Team C Team A Teamarchitekt Teamarchitekt Teamarchitekt
36. Makroarchitektur Abrechnung Kunde Brief
37. Zustandsfrei (Phönix Server) Status in Datenbank REST/HATEOAS API rückwärts kompatibel Resilience Makroarchitektur
38. Entwicklung Jederzeit kritische Fehler beheben Automatisches Datenbank Setup Deklarierte Service Abhängigkeiten Keine geteilten Daten zwischen Services
39. Deployment Installation mit RPM Paketen Automatisierte Auslieferung Provisionierung via Puppet Service Konfiguration mit Hiera
40. Security Explizite Sicherheitsanforderungen Sichere Kommunikation und Authentifizierung
41. Testen Smoke Test auf der Preview Stage für jede Komponente
42. Betrieb Virtualisierung Standard OS Start/Stop Zentrales Logging und Monitoring Rollout in der Produktion
43. Organisation
44. Abteilungen aufbrechen Entwicklung QA Betrieb
45. Abteilungen aufbrechen Entwicklung QA Betrieb
46. Abteilungen aufbrechen Entwicklung QA Betrieb
47. Abteilungen aufbrechen Entwicklung QA Betrieb
48. Organisatorisch ändern Development Team Team Team Team Team Team Team Team Team Team Team Team
49. Organisatorisch ändern Development Unit 1 Development Unit 2 Development Unit 3 Team Team Team Team Team Team Team Team Team Team Team Team Lesen / Schreiben Cloud / Einlieferung Ident / User
50. Organisatorisch ändern Development Unit 1 Development Unit 2 Development Unit 3 Team Team Team Team Team Team Team Team Team Team Team Team Development Unit 4 Team Team Team Team Lesen / Schreiben Cloud / Einlieferung Ident / User …
51. Betrieb
52. Anpassung Dev & Prod Eigne Virtualisierung CentOS und Debian Entwicklungs Puppet Eigenes Deployment Keine Virtualisierung Eigenes Puppet Betriebs Deployment RHEL Viele Fehlerquellen
53. Anpassung Dev & Prod Open Nebula Ein Puppet Hiera Gleichen Deploymenttools CentOS RHEL & CentOS
54. … und was ist draus geworden ?
55. 2013 vs. 2015 Deployments +567 % Stabilität +0.2 % Rufbereitschaft -40% Kritische Fehler Behebung -90% Fehlerbehebungsdauer -55%
56. Zusammenfassung Architektur muss verteilte Systeme erlauben Entwicklung muss vollautomatisiert sein Einheitliche Tools Entwicklung/Betrieb Organisation muss DevOps erlauben Möglichst unabhängige Teams (Tech/Orga)
57. Was hätte besser sein können ? Schnelles Rollout besser planen 3 mal Orga Strukturen neu Früher Dev Produktionszugriff Leitplanken früher kommunizieren Mehr (Über)Kommunikation Mehr Austausch zwischen den Teams
58. Zukunft Alte Komponenten entfernen Mehr Dashboards Mehr Automatisierung VMs? Container? Ungleichheiten Dev/Prod beseitigen
59. Fragen @owehrens speakerdeck.com/owehrens Vielen Dank!