Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Microservice-Architektur in der Praxis
Ähnlich wie Microservice-Architektur in der Praxis (20)
Microservice-Architektur in der Praxis
- 1. Primelephants Microservice-Architektur in der Praxis 2018-09-20 Expertenkreis Bielefeld
- 2. Über Primelephants 2 ● Softwarehaus mit 150 Entwickler ● Schwerpunkte Technik: ○ Java, Javascript, Mobile und PHP ○ Alle Java-Entwickler sind zertifiziert ● Schwerpunkte Existenz: ○ Qualität steht nicht zu Diskussion ○ Wir lieben Technik ○ Eigene Fehler akzeptieren ○ Langfristige Win-Win
- 3. - Georges Simenon Microservices? 3 “Sex ist sehr unkompliziert, wenn man von keinem Komplex, sondern von einem Bedürfnis geleitet wird.”
- 4. Sehr schnell und elegant angefangen Eine Geschichte 4 Coole Applikation
- 5. Sehr schnell und elegant angefangen Eine Geschichte 5 Persistenz Coole Applikation
- 6. Sehr schnell und elegant angefangen Eine Geschichte 6 Persistenz Coole Applikation Table 1 Table 2 Table 3
- 7. Sehr schnell und elegant angefangen Eine Geschichte 7 Persistenz Coole Applikation Table 1 Table 2 Table 3
- 8. Dann kam aber der Kollege ... Eine Geschichte 8 Persistenz Coole Applikation Table 1 Table 2 Table 3
- 9. Er muss eine neue coole App bauen Eine Geschichte 9 Persistenz Coole Applikation Table 1 Table 2 Table 3 Andere Coole Applikation
- 10. und bräuchte schnell nur ein paar Daten … also keine große Geschichte Eine Geschichte 10 Persistenz Coole Applikation Table 1 Table 2 Table 3 Andere Coole Applikation
- 11. und etwas später noch ein paar Daten … also auch keine große Geschichte Eine Geschichte 11 Persistenz Coole Applikation Table 1 Table 2 Table 3 Andere Coole Applikation
- 12. und fürs Call Center soll eine Backoffice-Applikation her Eine Geschichte 12 Persistenz Coole Applikation Table 1 Table 2 Table 3 Andere Coole Applikation Backoffice Applikation
- 13. … die ja logischerweise auf viele Daten zugreifen sollte, und einiges mitbringt Eine Geschichte 13 Persistenz Coole Applikation Table 1 Table 2 Table 3 Andere Coole Applikation Backoffice Applikation LDAP
- 14. ein neues Feld für die Coole Applikation ? Eine Geschichte 14 Persistenz Coole Applikation Table 1 Table 2 Table 3 Andere Coole Applikation Backoffice Applikation LDAP
- 15. Eine Geschichte
- 16. Mit einem Workaround ... Eine Geschichte 16 Persistenz Coole Applikation Table 1 Table 2 Table 3 Andere Coole Applikation Backoffice Applikation Table Workaroun d Work- around LDAP
- 17. … ist die Applikation, naja, nicht mehr Cool Eine Geschichte 17 Persistenz Historisch gewachsene Applikation = LEGACY Table 1 Table 2 Table 3 Andere Coole Applikation Backoffice Applikation Table Workaroun d LDAP
- 18. Folgen - Abbremsen der Innovation - Verteuerung der Weiterentwicklung - Legacy - Frustration der Entwickler - Verschlechterung der User Experience 18
- 19. Business ist durch IT behindert 19
- 20. Was tun? Historisch gewachsenes nicht pflegbares System Entwickler müssen besser entwickeln! - Tony Robbins Wir sollen besser und vor allem alles dokumentieren Version 1 Version 2 Version 2 kommentiert Version 3 abgeleitet von v.1Enterprise Architektur projektübergreifend dokumentieren 20
- 21. Was tun? Reicht das aus? … Wir müssen an unsere Architektur dran 21
- 23. Microservice Architecture Prinzipen (Martin Fowler, 2014): - Divide et impera (teile und herrsche) - Services bilden Fachlichkeiten ab - Services kommunizieren über leichtgewichtige Protokolle - Services sind zur Entwicklungs-, Build und Laufzeit unabhängig - Deployment ist voll automatisiert 23
- 24. Divide et impera System of Engagement System of Record Mitarbeiter Partner Dienstleiste r Kunden Communities Influencer 24
- 26. API Die allerschwierigste Baustelle bei der Microservice Orientierung ist ... API “Handeln ist leicht, Denken schwer, nach dem Gedanken handeln unbequem.” - Johann Wolfgang von Goethe 26
- 27. API - typische Fragestellungen - Identität des Kunden => Enterprise Identity Provider - Servicename => Capability- / Produktmodel, Namenskonvention - Granularität => Nach jeder Operation soll das Modell konsistent bleiben - Domänenübergreifend => Atomic vs. Komposite einführen 27 - Wem gehört der Service => siehe die Geschichte
- 28. Ein Partnerprodukt musste integriert werden Eine Geschichte 28 Unternehmen Partner Fremdprodukt Service Terms & Conditions Service ?
- 29. Service 29 Ein Service kann genutzt werden! - Tony Robbins
- 30. API Richtlinien - Dokumentationspflicht - Mit Beispielen versehen - Namespaces nach Capability Map - Namenskonvention - Versionierung - Paginierung - etc. 30
- 31. API Richtlinien einhalten? API Polizist vs. API Economy 31
- 33. API Gateway * Loadbalancing in API Gateway wird i.d.R. nicht empfohlen, stattdessen sollen die Services darum selber kümmern App Store für Services: - API Registry & Discovery - Subscription - Nutzungsabrechnung Routing: - zu den Service-Endpoints - Throttling - SSL Terminierung - Loadbalancing* - Nutzungsstatistik Weiterentwicklung: - Kenne deine Konsumenten (Versionierung) Betrieb: - Deployment Workflow (Dev -> UAT -> Prod) - Firewall ist bereits freigeschaltet ! 33
- 34. API Gateway - Beispiel 34
- 35. Wer konsumiert die Services ? 35
- 36. Glaubenskrieg 36 API Kanäle Services Mobile 3rd Party vs. API Backend for Frontend Backend for Frontend Mobile 3rd Party Backend for Frontend
- 37. Backend for Frontend 37 API Backend for Frontend Frontend Aggregation & Business Logik APIAPI Feingranulare API Security Token Caching
- 38. 38 Big Picture
- 39. Big Picture Front End (Browser, Mobile) Web Application (Backend for Frontend) API Gateway Service 1 Service 2 ReST ... Persistenz SOR UI BfF API Service System Of Record ReST, GraphQL, WebSocket, ... 39
- 40. Was ist mit Security? 40
- 41. Big Picture UI BfF API Service System Of Record 41 Front End (Browser, Mobile) Web Application (Backend for Frontend) API Gateway Service 1 Service 2 ReST ... Persistenz SOR ReST, GraphQL, WebSocket, ... Security Logging&Monitoring PAAS
- 42. wird jetzt alles besser? “Das Gegenteil von schlecht muss nicht gut sein - es kann noch schlechter sein.” Paul Watzlawick 42
- 43. Was bringt die Microservice-Architektur? - Wird die Komplexität reduziert? - Weniger Abhängigkeiten - Design time? - Runtime? - Von Wiederverwendung profitieren? - API Design Albtraum - Wem gehört ein Service? - Konsumenten sind ja … ➔ Nein, aber umstrukturiert und kann einzeln bekämpft werden ➔ Nein, aber durch API standardisiert, nachvollziehbar und kontrollierbar gemacht ➔ Nein, aber von der Infrastruktur unabhängig und durch Automatisierung steuerbar gemacht ➔ Vielleicht, muss mit Vernunft eingegangen werden ➔ Ja, jetzt ist es noch transparenter, dass es um Engineering und nicht Coding geht :) ➔ Eigentlich demjenigen der den Service gebaut hat, muss aber durch API-Economy motiviert werden ➔ Kunden. Und IT soll Mehrwert für Business erzeugen
- 44. Soll ich die Microservice-Architektur einsetzen? - Startup - Mittelstand - Eine völlig neue Applikation - Erweiterung - Konzern mit mehreren Systemen ➔ Eher Nein, es sei denn sie sind doch kein Startup mehr :) ➔ Überlegen, wahrscheinlich Nein ➔ Überlegen, eventuell Ja ➔ Höchstwahrscheinlich Ja, es sei denn es geht doch um ein Startup :)
- 46. Primelephants GmbH a: Leopoldstraße 2-8 32051 Herford e: contact@primelephants.com t : +49 (0) 5221 5793887 m : +49 (0) 175 2457099
Hinweis der Redaktion
- Als ich mit einem Business Analyst 3 Stunden über eine Linie zwischen 2 Kästchen diskutiert habe
- Identität des Kunden: Bei Telekom ein Vertrag zweimal angelegt, Bei SPK muss man seine Mastercard fürs Online Baking im eigenen Online Banking für sich selber freischalten. Viele Unternehmen haben mehrere Identitäten – bei einer Bank habe ich 5 Identitäten gesehen Lösung: Enterprise Identity Provider. Eigener im Haus oder externer wie WebId, Verimi, obwohl hier versuchen Sie mal den Nutzern zu erklären was das Verknüpfen von Identitäten bedeutet - WAF (Women Acceptance Faktor) Granularität - (schon in SOA eine der häufigsten Fragen) wie viele Daten sollen in die Operationen rein? Soll ein Handling durch ein oder mehrere Aufrufe abgebildet werden?
- Wie? unseren Service Nutzen? Ihr wollt ihn aufrufen und bei uns eure Daten speichern?
- API Polizist - Ich habe es tatsächlich erlebt - allerdings war der Service Architekt sehr schnell ziemlich unzufrieden
- Ich persönlich präferiere diesen Ansatz, statt eine API für alle Kanäle
- PAAS – Container basierte Lösungen wie etwa Docker mit Kubernetes oben drauf Logging, Monitoring – ELK – Elastic Search, Log Stash, Kibana Für ein konkretes Unternehmen würde man weitere Details definieren wie bspw. Distributed State, Secrets, Protokolle, Netzwerke sprich Firewalls, Man würde zu jedem Baukästchen detaillierte Beschreibungen mit ggf. Referenzimplementierungen vorsehen.
- Wie ist die Situation bei Ihnen? Haben Sie API Richtlinien, API Gateway? Serverless? Abhängigkeit vom Anbieter Daten Sync - Service “Kunden”, Service “Aufträge” -> Lager braucht Auftrag+Kunden Info nd zwar massenhaft Security, Identity Provider. Wie ändert sich die Security wenn wir vom Monolith zu Microservices wecheln API für Kündigung eines vertrages