Nie wieder Monolithen! Ein Praxisbericht über Micro Services.

Keiner will Sie, und dennoch entstehen Sie wie von Zauberhand: Anwendungsmonolithen. Mit Micro Services wird es möglich, die SOLID Prinzipen auf die Architektur anzuwenden. Anwendungen werden in kleine, kollaborierende Services zerlegt. Der Entstehung von grossen Software-Monolithen wird dadurch dauerhaft ein Riegel vor geschoben.

Die einzelnen Konzepte hinter dem Micro Service Architekturstil sind leicht zu erfassen und vieles davon ist bereits bekannt. In der Umsetzungspraxis entstehen dennoch einige Fragen, die beantwortet werden wollen:

- Welche Technologien bieten sich an?
- Wie können Integrationstests gestaltet werden?
- Was ändert sich an einer Continuous Deployment Pipeline, wenn plötzlich viele, im lifecycle unabhängige Services deployed werden wollen?
- Auf welche Aspekte muss beim Betrieb von Micro Services geachtet werden?

In diesem Vortrag stelle ich vor, welche Antworten wir bei der Hypoport AG auf diese Fragen gefunden haben. Am Ende werden Sie in der Lage sein, innerhalb kürzester Zeit, eigene Micro Services Aufzusetzen, zu Testen und zu Deployen.

Transcript

1. Nie wieder Monolithen! Ein Praxisbericht über Micro Services. Timmo Freudl-Gierke @timmo_gierke 1 Micro Service User Group München 25. September 2014
2. © 2011 HYPOPORT AG Organisator der 
 MongoDB User Group Berlin Head Architekt EUROPACE 2 Plattform Timmo Freudl-Gierke twitter: @timmo_gierke 2
3. Agenda • Fachlicher Kontext • Monolithen • Micro Services • Macro- und Micro- Architektur • Technologiestack • Betrieb • Zusammenfassung
5. Der Finanzmarktplatz
8. 3,1 Mrd €
10. Monolithen
11. EUROPACE Classic 11
12. Monolithic Application Pattern One Big App - One Big Database 12
13. Eigenschaften • Ein VCS (git) • Keine Steuerung der Abhängigkeiten • Ein Software Artefakt • Homogene Technologiestack • i.d.R. grosse Anwendungs-Library (“util”) • Verschmelzung unterschiedl. Fachlichkeiten
14. Monolithic Application Pattern Horizontale, technische Ebene 14
15. Monolithic Application Pattern Vertikale, fachliche Bereiche 15
16. Konsequenzen • Seiteneffekte • (Integrations-) Testbarkeit • Lange Buildzeiten • Hoher Einarbeitungsaufwand • Risiko von Änderungen • Kostenintensive Skallierbarkeit • Wenig Overhead bei (sehr) kleinen Anwendungen
17. Multi-Module Maven Projects
18. Core Asset Extrahieren! 2007 18
19. Rechenkern 19
20. Rechenkern Frontend Adapter Angebot-Workflows Frontend Adapter Frontend Adapter Product Engine Bank A Product Engine Bank B …
21. Eigenschaften • Ein VCS (git) - Ein IDE Projekt • Nachvollziehbare Abhängigkeiten (Maven)! • Ein Software Artefakt (WAR) • Eine Deployment Pipeline • Homogene Technologiestack • i.d.R. grosse Anwendungs-Library (“util”)
22. Weiterentwicklung 0 100 200 300 400 2008 2010 Gestern Java + Grooy: > 1 M lines, XML 1,2 M lines # pom’s
23. Konsequenzen • TDD Zyklus dauert > 20 Sek • Integrationstest-Feedback > 40 min • Release-Build > 1 Std • Innovation beschränkt auf Framework updates • Gebunden an Java / Spring / Maven
24. Multi-Webapp Application
25. Conway’s Law “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.”
26. Vorgangs Management Übersicht Partner Management Baufi Smart Kredit Smart Bauspar Smart Reporting Dokumenten Verwaltung Rechenkern 26 Antragsübersicht EUROPACE 2 Frontend WebApps
27. DB per WebApp WebApp
28. Deployment Pipeline
29. Eigenschaften • Ein VCS (git) - Ein IDE Projekt • Nachvollziehbare Abhängigkeiten (Maven) • N Software Artefakte (WARs) mit eigener DB • Heterogener (Java) Technologiestack möglich • Eine Deployment Pipeline • Grosse Anwendungs-Library (“util”)
30. Weiterentwicklung Entscheidung Mitte 2012: “Die Vorteile des “single project / single pipeline” überwiegen, wenn wir die langen Buildzeiten in den Griff bekommen” => Maven Milk Plugin
31. Weiterentwicklung Classes per WebApp 80 - 2000 Maven Projekts per WebApp 5 - 50 Total Clases > 5k Total Maven Projects > 200 Technologiehomogenität 90% Herbst 2013
32. Konsequenzen • TDD Zyklus dauert > 30 Sek • Integrationstest-Feedback 3 .. 30 min (Milk Plugin) • Commit-to-Prod ~ 1 Std. • Rollout-“Stau” durch single Pipeline • Technologieunabhängigkeit wurde nicht genutzt (Effizienz, Komfort-Zone, Projektdruck) • Verzahnung / Kohäsion durch übergreifende Libraries
33. Ein neuer Architekturstiel musste her!
35. Single Responsibility Principle “Für die Änderung einer Klasse sollte es nur genau einen Grund geben.” Robert C. Martin
36. Single Responsibility auf allen Ebenen Class Package Service Application Method
37. Micro Service 37
38. Eigenschaften • Single Responsibility • Separate VCS Projekt • Exklusive Datenbank • Aufgaben-optimierter Tech-Stack • Unabhängig Deploybar • Unabhängig Skallierbar • Verantwortung eines Team
39. Grösse von Micro Services # Klassen 27 - 200 # Maven / Gradle Projekte 1
40. “It has to fit in my head” James Lewis
41. Makro Architektur
42. Teile Deine Anwendung in vertikale Domänen. ! Bilde jede Domäne in einem eigenen Micro Services ab! 42
43. Makro Architektur
44. Leitplanken Makro-Architektur Mikro-Architektur UI / UX Freie Technologiewahl Ab- & Vorwärtskompatible Schnittstellen Keine geteilten Bibliotheken HTTP / REST Shared Nothing Model Continuous Deployment Logging / Request Verfolgung Health Monitoring Controlling & Metriken Security
45. Technologie Stack
46. Schnell Fahrt aufnehmen ! 46
47. Lieblings Tech- Stack !•!Java 8! !•!Spring Boot ! ! ◦!Embedded Container! ! ◦!Executable Jar! ! ◦!Property-Management! ! ◦!HTTP Resourcen! !•!HAL + HAL Browser ! !•!Jersey-Http-Client! !•!Spring-Data-MongoDB! !•!TestNG! !•!Mockito! !•!FEST Assertions! !•!Gradle (Build & Deployment)! !•!MongoDB
48. Infrastructure • CI-Server (TeamCity Goals) • Database (MongoDB) • Host (ESX) / Co-location • Puppet template • Load balancer config • DNS • Consul / HA Proxy 48
49. Deployment Pipeline 49
50. Spring Boot > gradle build
 > java -jar hello.jar &
 > curl http://localhost:8080/ 50
51. Deployment Pipeline Vertrauen in Fehlerfreiheit Schnelles Feedback Laufzeit (ca. 5 min) 51
52. Build 10 second build ! 52
53. Test Pyramide 53
54. Testklassen EUROPACE 2 Testpyramide (Sept. 2013) System-Integration Modul-Integration Unit 0,00 500,00 1000,00 1500,00 2000,00 Test-Klassen 54
55. Unit Tests 5 sec. TDD cycle 55
56. Integration Tests 56
57. Standalone Mode • Mocked Dependencies • Golden test data
 (apply on startup) • Spring Profiles 57
58. MicroService in Isolation Test (Service Integration Test) Service Integration Test Suite 58
59. Continuous Integration Server (Random, free Network Port) Service Integration Test Suite Service Integration Test Suite Service Integration Test Suite 59
60. try { ServerSocket s = new ServerSocket(0); int port = s.getLocalPort(); s.close(); return port; } catch (IOException e) {// …} service.properties Service Integration Test Suite 60
62. Interoperability Tests 62
63. Multi-Pipeline Dependencies Production Rollout Service Integration T. Consumer Driven Tests Service Specific Pipeline (part) Service Specific Pipeline (part) 63
64. B A C Laufzeitabhängigkeiten zwischen 3 Micro Services 64
65. Consumer Driven Test Suites B A C CDTS! A->B CDTS! B->C Verantwortungsgrenze Provider Consumer Provider Consumer 65
66. Production Deployment 66
67. Rolling Update For each Host do 1. Remove from load balancer 2. Shutdown service 3. Copy new service artefact(s) 4. (Install new artefact) 5. Start service 6. Add to load balancer 67
69. Incident Manager Interface • service.sh restart • /etc/init.d/yourService (symlink) 69
70. Wichtiger Baustein Starte so schlank wie möglich 70
71. Support & Betrieb
72. Allgemeine Betriebsstrategie: ! Stabilität & Nachvollziehbarkeit 72
73. Logging Log Aggregator • Logstash & Kibana • (Splunk) log statement: • traceId! • service • user • use-case • entity 73
74. Monitoring • Self monitoring • Mem • Cpu • DB Connection • Business Metrics • Metrics + Graphite • Aalarming • pushover.net GET /health 74
75. Resilience n-tier headache Circuit Breaker Fail fast Fail silent Hysterix Load Shedder Totmannschalter Caching Fallback Strategy 75
76. Support Schnittstelle https://github.com/mikekelly/hal-browser
77. Zusammenfassung
78. Monolithen und deren Eigenschaften Architekturleitplanken Technologie Stack Deployment Pipeline Support & Betrieb Multi-Pipeline-Dependencies & Integrationstests Micro Service Fundament
80. Nie wieder Monolithen! Ein Praxisbericht über Micro Services. Timmo Freudl-Gierke @timmo_gierke 80 Micro Service User Group München 25. September 2014