2. Warum sind monolithische Systeme ‘evil’?
Wegen ihrer Abhängigkeiten!
Warum sind Abhängigkeiten ‘evil’?
• Software ist schwer zu testen!
• Auswirkungen von Änderungen lassen sich nicht sicher begrenzen!
• Arbeiten mit mehreren Teams ist schwierig!
• Systeme lassen sich nicht unabhängig skalieren!
• Individuelle Deploymentzyklen für Features sind aufwändig!
• Unabhängige Skalierung ist nicht möglich!
• Wiederverwendung von fachlichen Teilen ist unmöglich!
Monolithische Software
3. Monolithen entstehen durch schlechtes Design und den falschen
Umgang mit Abhängigkeiten.
Unabhängig von der Technologie:
• Auch mit Micro Service Frameworks lassen sich Monolithen bauen.
• Auch verteilte Systeme können zu einem Monolithen werden.
• Auch große Systeme mit einem einzelnen .ear können eine interne
gute Architektur haben (filigran und zerlegbar).
Monolithen vermeiden
4. • Design der fachlichen Anwendung in
unabhängigen Säulen
• Vertikale Teams (End-to-End)
• Maximale Reduktion von Abhängigkeiten
Vertikal denken!
7. The micro service way ...
GUI
Service
DB
GUI
Service
DB
GUI
Service
DB
GUI
Service
DB
8. Small with a single responsibility
• Each application only does one thing
• Small enough to fit in your head
– “If a service is bigger than your head, than it is too big”
• Small enough that you can throw them away
– Rewrite or Maintain
Micro-Service-Prinzipien
nach James Lewis:
9. Located in different VCS roots
• Each application is completelty seperate
• Domain Driven Design / Conway’s law
– Domains in different bounded contexts shoud be distinct - and it is ok
to have duplication
– Use physical separation to enforce this
• There will be common code, but it should be library and
infrastructure code
– Treat it as you would any other open source library
– Stick it in a nexus repo somewhere and treat it as a binary
dependency
Micro-Service-Prinzipien
nach James Lewis:
11. Keine App-Server
• Service bringt Environment mit
Wenig Code
• “Wegwerf-Services”
• Refactoring = neu Schreiben
Der richtige Stack für die Anforderung
• 1 Monolith -> 1 Stack, 100 Micro Services -> 100 Stacks
• Freie Wahl: OS, Sprache, Framework, Datenbank
Implementierung
12. Exklusive Datenbank
• Sonst keine lose Kopplung!
• Kann Duplizierung von Daten verursachen
Source Code Management
• 1 Repo für jeden Service
Neues Feature, neuer Service
• Erst prüfen, ob es eine neue fachliche Säule ist
• Dann erst vorhandenen Service erweitern
Implementierung
13. Alles erlaubt
• Am besten: wenige Standards im gesamtem System
Lose Kopplung
• Services sollten nicht viel voneinander wissen
• Am besten: auch nichts über deren Existenz
Smart Endpoints, Dumb Pipes
• Kommunikationskanal hat keine Intelligenz
• Kein ESB (Verstoß gegen Micro-Services-Prinzipien)
Bevorzugt: Web-Standards
• REST, kein SOAP
Kommunikation
14. Asynchronous Messaging
• Leichtgewichtig: ØMQ, RabbitMQ
• High Performance: Apache Kafka, Vert.x Event Bus
Resilience
• Toleranz gegenüber Ausfällen, Wiederherstellung nach Fehlern
• Fehlerkaskaden vermeiden
• Testen!
• Tools: Hystrix, JRugged, Netflix Simian Army
API-Versionierung vermeiden
• Schafft mehr Probleme als es löst
• Besser: tolerant bei Annahme von Daten, konservativ beim Senden
Kommunikation
15. Unit-Tests
• Integrationstests ausreichend, weil Service sehr klein
• Micro Service selbst ist Unit under Test
• In Isolation: Abhängigkeiten (andere Services) mocken
Consumer Driven Tests
• Gut: Service definiert Tests, die API verifizieren
• Besser: API-Konsumenten definieren Tests des Services
• Tests gegen erwartete API, nicht nur behauptete
Testen
16. Continous Deployment
• Deployment-Pipeline
Alles automatisieren!
• 1 Monolith leicht manuell deploybar, 100 Micro Services nicht
Paketierung
• Auf etablierte Standards setzen
• Init Skripte!
• Tools: DEB, RPM, ...
Installation
• Tools: Puppet, Chef, etc.
Deployment
17. Docker
• LXC basierte Virtualisierungslösung
• Ähnlich chroot (aber viel besser)
• Schlank und schnell
• Inhalte mit Git versioniert -> Änderungen an ‘VMs’ über git
Gilliam
• Management Plattform für Micro Services
• Basiert auf docker
• Vereinfacht Deklaration und Management
• Portverwaltung, Api-Mapping
• Deklarative Skalierung
Deployment als Plattformen
1 Linux-System <-> 1 Micro Service
19. Echtzeit-Metriken
• Wichtig ist, was jetzt passiert
• Auf Fehler schnell und automatisch reagieren
• Tools: Coda Hale Metrics, Spring Boot Actuator
Logging
• Logs von 100 Services manuell durchforsten nicht möglich
• Logging zentral aggregieren
• Filterung, Echtzeit-Auswertung möglich
• Historie sichtbar, Trends erkennbar
• Tools: Logstash, Apache Flume, fluentd
Visualisierung
Monitoring
20. Problem: Security-Context über 100 Services
• Security ist auch ein Service
Lösung: IAMs
• Zentrale Verwaltung von Identitäten und Berechtigungen
• Credentials: Tokens, Assertions,
• OAuth, SAML
• OSIAM, Shibboleth
Security
21. • Inventarisierung vieler Services
• Hohe Anforderungen an Deployment-Prozess
• Hohe Anforderungen an Operations
• Netzwerklast
• Neue Art zu Denken und zu entwickeln
• Freiheit der Technologiewahl darf nicht zu Wildwuchs führen
Risiken und Probleme
29. Einfaches, schlankes Java Micro Service Framework
Integration von
• Jetty
• Jackson/Jersey
• Metrics
• Hibernate
• Liquibase
Haupt Features
• Single-jar deplyoment
• Einfache Konfiguration
• REST Support
• Health Checks
• SSL out of the box
• Absicherung von Ressourcen
Dropwizard