Wie wir mit Microservices beinahe gescheitert wären.

code.talks 2017, 28.09.2017
Rainer Elias, Guido Zockoll

Transcript

1. Wie wir mit Microservices beinahe gescheitert wären Rainer Elias, Hermes Germany GmbH Guido Zockoll, Iteratec GmbH code.talks Hamburg, 28.09.2017
2. Wer sind wir Rainer Elias • 43 Jahre • Softwareentwickler bei Hermes Germany GmbH Guido Zockoll • 54 Jahre • Senior Software Architect bei Iteratec GmbH • JVM Entwickler, DevOps Coder und Docker Enthusiast
3. Ausrichtung auf digitale Geschäftsmodelle Hermes Germany ist ein Unternehmen im Wandel • Gegründet 1972 • Wir stellen derzeit etwa 400 Millionen Pakete pro Jahr zu • Wir stellen uns mit 200 IT-Spezialisten den Herausforderungen der Logistik • Wir sind Teil des Otto-Konzerns • Wir suchen Mitdenker, Mitgestalter und Möglichmacher
4. Komplexität braucht kluge Köpfe Der IT-Dienstleister mit der höchsten Kompetenzdichte • Gegründet 1996 • Etwa 300 Mitarbeiter • München, Hamburg, Frankfurt, Stuttgart, Düsseldorf, Paris, Wien • unabhängig und gründergeführt • Technologie- und Managementberatung
5. Ablösung der alten Fassung basierend auf IBM WebSphere Portal Server durch eine Microservice-Architektur Zahlen: • 15 Millionen Sendungen/ Jahr • 300 Millionen Seitenaufrufe/ Jahr Grundprinzipien für die Neuentwicklung: • Kürzere Entwicklungszyklen • Intuitive Nutzbarkeit • Flexiblere Weiterentwicklung auch in der Gestaltung der Oberfläche • Bereit für Wachstum des Geschäfts myHermes.de 5
6. Inhalt 01 Service Schnitt 02 Resilienz 03 UI Integration 04 Fazit Fragen gerne jederzeit zwischendurch.
7. Der Weg nach vorne für Hermes: Alles Commodity? Ort, Datum 01 Service Schnitt
8. Experten Check https://jaxenter.de/microservices-im-experten- check-wie-gross-sollte-ein-microservice-sein- 36763 Jörg Müller: [...] Ein Microservice sollte eine Verantwortlichkeit haben und er sollte eben nicht zu groß sein, damit er auch mal eben in ein paar Tagen neu erstellt werden kann. Eberhard Wolff: Die fachliche Aufteilung ist wichtig, wenn es um die unabhängige Entwicklung geht. Dazu sollte ein Microservice ein Bounded Context im Sinne von Domain- driven Design sein. [...] Stefan Tilkov: [...] Auf oberster Ebene habe ich die besten Erfahrungen damit gemacht, die Organisation und ihre Anwendungsfälle als Kriterien für einen Schnitt zu nehmen. Stefan Toth: So groß, dass es in einen Entwicklerkopf passt. Eine genaue Aussage dazu ist schwierig und wird oft zu religiös beantwortet.
9. Bounded Context im Sinne des Domain-Driven-Design
10. Use Case getrieben – „Verticals“ 10
11. Live Demo
12. Der Weg nach vorne für Hermes: Alles Commodity? Ort, Datum 02 Resilienz
13. Circuit Breaker • Langsame Ressourcen sind der Killer für jedes verteilte System • Anfragen stauen sich auf und fressen alle Systemressourcen • Circuit Breaker Pattern • Selbstschutz des Systems • Spring Cloud Hystrix
14. Health Endpoint • Spring Boot Actuator stellt unter „/health“ Status Informationen über den „Gesundheitszustand“ der App zur Verfügung • Im Body stehen detaillierte Status Informationen als JSON Struktur • Der Response Code ist entweder 200 oder 503 • Die Seite steuert die Service Discovery bzw. den Loadbalancer
15. Brauchen wir Gürtel und Hosenträger? • Vorbereitung auf Ausnahmesituationen • Risikomanagement • Eintrittswahrscheinlichkeit? • Kosten bei Eintritt? • Kosten / Nutzen • Augenmaß • Gürtel und Hosenträger • Adam Bien „Plötzlich glaubt jede Firma, sie sei Netflix“
16. 03 UI Integration
17. Herausforderungen Layout • Das Altsystem ist nicht „responsive“ • Im alten Layout wird viel mit JQuery gemacht • Es existiert ein Prototyp auf Basis von Twitter Bootstrap • UI Komponenten und Module im Pattern-Lab bereitgestellt Content-Management-System • Layout/Content-Auslieferung durch Redakteure
18. Fragen denen wir uns stellen mussten • Welche Architektur verfolgen wir ? • Single Page Applikation oder Multi Page Applikation ? • Wie integrieren wir das CMS (die statischen Seiten) in unsere Pipeline ? • Welche Frontend Tools wollen wir verwenden ? • Wie stellen wir Assets bereit und integrieren diese in die Microservices ? • Kommen die Assets aus dem CMS oder soll jeder Microservice ein Asset haben ?
19. Theoretische Ansätze Web UI mit Microservices • Literatur z.B. Microservices von Eberhard Wolff • Spring Cloud / Netflix Zuul • Varnish • NGINX • …
20. Theoretische Ansätze Web UI mit Microservices • SPA pro Microservice • Eine SPA für alle Microservices • HTML-Anwendungen • Frontend-Server • Rich Client Application Quelle: Microservices von Eberhard Wolff
21. Integration des Content Management System Quelle: https://www.thoughtworks.com/de/radar/platforms • Redakteure umgehen damit die Prozesse • Die Zusammenarbeit des Content aus dem CMS und Mircoservices können kaputt gehen ThoughtWorks Technology Radar
22. Historie Altsystem Lösung 1 Lösung 2 Aktuell Zukunft Monolith Microservices Thymeleaf ESI Varnish Asset Service Vue.js NGINX Asset Service NGINX Asset Service Thymeleaf SSI
23. Warum Vue.js? • sehr leicht erlernbar • gute Dokumentation • leichtgewichtig • HTML-basierte Templates passen gut zu den Vorgaben im Pattern Lab • UI-Komponenten können einfach ins CMS eingebunden werden sehr gute Erfahrung am "Forschertag" Umsetzung der Kundenregistrierung an einem Tag
24. Javascript Frameworks – Github stars Quelle: https://risingstars2016.js.org/#framework
25. Wie Vue.js Vue.js CMS CMS CMS CMS • Statische Inhalte und das Seitengerüst werden durch das CMS generiert • Dynamische Inhalte werden clientseitig über Vue.js Komponenten gerendert • ein Microservice beinhaltet Vue.js Komponenten und REST-Interface
26. Docker UI Komposition Nginx-Container Reverse Proxy Microservice UI REST Nginx-Container CMS Content Microservice UI REST CMS
27. Der Weg nach vorne für Hermes: Alles Commodity? Ort, Datum 04 Fazit und Ausblick
28. Fazit: Wir sind live! • Widersprüchliche „Best Practice“ Empfehlungen • Endlose, wiederkehrende Diskussionen • Holzwege, Fehlentscheidungen • Wann ist das Projekt fertig? • Sehr lange Einarbeitungszeit • Sehr viele Tools, Frameworks, Prozesse zu lernen (Spring Boot, Spring Cloud, Vue.js, Docker, Kubernetes, Openshift, Prometheus, Grafana, NGINX, ...) • 95% Infrastruktur Code • Redundanz und Uneinheitlichkeit aushalten • Hoffentlich bessere Wartbarkeit (Bsp.: Java 9 Migration) • Jederzeit wieder!
29. Kontakt Guido Zockoll Guido.zockoll@iteratec.de Am Sandtorkai 75| 20457 Hamburg Kontakt Rainer Elias Rainer.Elias@hermesworld.com Essener Str 89 | 22419 Hamburg