Als PDF, PPTX herunterladen
Hochgeladen vonOPEN KNOWLEDGE GmbH
Microservices Architecture: Architektur und Patterns
Der Workshop von Lars Röwekamp befasst sich mit der Architektur von Microservices und ihren kommunikativen Mustern, einschließlich REST und Messaging, sowie Herausforderungen bei der Datenintegration und Transaktionsmanagement. Er betont die Bedeutung von losen Kopplungen, Skalierbarkeit und Agilität, während er auch auf praktische Probleme im Vergleich zur Theorie hinweist. Zudem werden Strategien wie die 'Saga'-Muster zur Gewährleistung der Konsistenz über Servicegrenzen hinweg behandelt.
Weitere ähnliche Inhalte
Ähnlich wie Microservices Architecture: Architektur und Patterns
Microservices Architecture: Architektur und Patterns
- 1. #WISSENTEILEN #WISSENTEILEN Microservices Architecture Lars Röwekamp CIO NewTechnologies @mobileLarson @_openknowledge
- 2. #WISSENTEILEN ÜBER OPEN KNOWLEDGE BranchenneutraleSoftwareentwicklung & IT-Beratung
- 3. #WISSENTEILEN ÜBER MICH Wer binich - und wenn ja, wie viele? • CIO New Technologies • Enterprise & Mobile • Autor, Speaker, Coach & Mentor • Snowboard & MTB Enthusiast (a.k.a. “stets bemüht“) Lars Röwekamp (a.k.a. @mobileLarson) LR
- 4.
- 5.
- 6. #WISSENTEILEN DISCLAIMEREs folgt sehrviel Text. Und der ist auch noch „geklaut“!
- 7. #WISSENTEILEN Wie groß istklein „A microservices ecosystem (ME) is a platform of services each encapsulating a business capability. Developers can build, test and release each microservice independently. ME enforces an organizational structure of autonomous long standing teams, each responsible for one or multiple services.“ (Zhamak Dehghani, ThoughtWorks)
- 8.
- 9.
- 10. #WISSENTEILEN Share nothing* *a.k.a. shareas little as possible
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17. #WISSENTEILEN Easier to develop, understand& maintain.
- 18.
- 19. #WISSENTEILEN Local changes can beeasily deployed
- 20. #WISSENTEILEN Scaling indepentent from allother services
- 21.
- 22. #WISSENTEILEN Stack isolation no longterm commitment to any stack
- 23.
- 24.
- 25. #WISSENTEILEN In der Theorie istalles ganz einfach
- 26.
- 27. #WISSENTEILEN In der Praxis siehtes leider etwas anders aus.
- 28.
- 29.
- 30. #WISSENTEILEN#WISSENTEILEN Hilfe, wir brauchendringend Architetkur & Pattern
- 31.
- 32. #WISSENTEILEN „Wie kommunizieren Services untereinander?“ „Weroder was ist für die UI zuständig?“ „Wie gehen wir mit Cross-Cutting Themen wie Logging, Tracing, Profiling oder Security um?“ „Database per Service Pattern, wie soll das bitte gehen?“ „Und welche Bedeutung spielt die Versionierung der Services und ihrer Schnittstellen?“
- 33.
- 34. #WISSENTEILEN Wie kommunizieren Servicesuntereinander?
- 35. #WISSENTEILEN Communication Pattern • RESTful(z.B. via JAX-RS 2.0) • Messaging (z.B. via JMS 2.0)
- 36. #WISSENTEILEN Communication via REST •Ressourcen basiert • eindeutige Identifikation via URI • State Transfer via HTTP Methoden • Caching via ETag, Last-Modified, … • Request/Response Modell • synchrone Kommunikation
- 37. #WISSENTEILEN RESTful Step 1:Create order A: POST /orders/ {order} B: CREATED 201 Location /orders/123 Step 2: Update order A: PUT /orders/123 {order} B: OK 200 {order}
- 38. #WISSENTEILEN Communication via REST HTTPMethoden korrekt verwendet: POST „creates a child resource at a server defined URL“ PUT „creates/replaces the resource as a whole at the client defined URL“ PATCH „updates part of the resource at that client defined URL“
- 39. #WISSENTEILEN RESTful • Verbindungsprobleme? • Fehler? •Call wiederholen? • Seiteneffekte? • Status Codes nutzen! • Payload nutzen!
- 40. #WISSENTEILEN Communication via REST HTTPMethoden korrekt verwendet: SAFE „No changes to resources at all*“ IDEMPOTENT „No changes to resources when called repeatedly**“ *GET, HEAD, OPTIONS ** GET, HEAD, OPTIONS, PUT, DELETE
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49. #WISSENTEILEN RESTful Aber was istmit … • Fire & Forget? • Broadcast? • Async? Passt nicht so richtig ins (REST) Konzept, oder?
- 50. #WISSENTEILEN Communication via Messaging •Messages zur Kommunikation • lose Kopplung durch Queues & Topics • ein Sender, 0 bis N Receiver • asynchrone Kommunikation • garantierte Auslieferung möglich
- 51. #WISSENTEILEN Communication via Messaging •plattformspezifische Formate (z.B. JMS, MSMQ) • plattformneutrale Formate (z.B. AMQP)
- 52. #WISSENTEILEN Msg Step: Sendmessage A: Send to topic X { msg } B: Register to topic X Step: Receive message T: ACK T: New Message in X B: Read X
- 53. #WISSENTEILEN Msg Und was beiProblemen? • Retry durch Sender • Reliable Msg (Ack) • evtl. Duplikate • evtl. Seiteneffekte
- 54. #WISSENTEILEN Msg ... und Broadcast •bei Topics sind mehrere parallele Empfänger möglich
- 55. #WISSENTEILEN Msg ... und Transaktionen •via Transactional Request* *ACHTUNG: gilt nur bis zum Message Broker
- 56. #WISSENTEILEN Msg ... und synchron •2x Async == Sync ;-) • Correlation ID • Latenz beachten
- 57. #WISSENTEILEN Msg ... und synchron •2x Async == Sync ;-) • Correlation ID • Latenz beachten
- 58. #WISSENTEILEN Msg ... und synchron •2x Async == Sync ;-) • Correlation ID • Latenz beachten
- 59. #WISSENTEILEN Msg ... und synchron •2x Async == Sync ;-) • Correlation ID • Latenz beachten
- 60. #WISSENTEILEN Msg ... und synchron •2x Async == Sync ;-) • Correlation ID • Latenz beachten
- 61. #WISSENTEILEN Msg ... und synchron •2x Async == Sync ;-) • Correlation ID • Latenz beachten
- 62.
- 63.
- 64.
- 65.
- 66.
- 67.
- 68.
- 69.
- 70. #WISSENTEILEN Database per ServicePattern, wie soll das gehen?
- 71. #WISSENTEILEN Data Integration via... • gemeinsame Datenquelle • getrennte Datenquellen • Datenreplikation
- 72. #WISSENTEILEN Data Integration via... gemeinsame Datenquelle Unabhängig entwickeln, pflegen, deployen, skalieren?
- 73. #WISSENTEILEN Data Integration via... • gemeinsame Datenquelle • getrennte Datenquelle • Datenreplikation
- 74. #WISSENTEILEN Data Integration via... getrennte Datenquellen
- 75. #WISSENTEILEN Data Integration via... getrennte Datenquellen (lesend via Owner, schreibend via Owner)
- 76. #WISSENTEILEN Data Integration via... Replikation von Daten
- 77. #WISSENTEILEN Data Integration via... Replikation von Daten (lesend via Replikation, schreibend via Owner)
- 78. #WISSENTEILEN Data Integration via... Domain A Domain A‘ Domain B
- 79. #WISSENTEILEN Data Integration via... Domain A Domain A‘ Domain B POST new „A“
- 80. #WISSENTEILEN Data Integration via... Domain A Domain A‘ Domain B
- 81. #WISSENTEILEN Data Integration via... Domain A Domain A‘ Domain B
- 82. #WISSENTEILEN Data Integration via... Domain A Domain A‘ Domain B
- 83. #WISSENTEILEN Data Integration via... Domain A Domain A‘ Domain B
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91.
- 92.
- 93.
- 94. #WISSENTEILEN Das klappt nieim Leben! (Anonymous, DB Admin)
- 95.
- 96.
- 97. #WISSENTEILEN#WISSENTEILEN „Benötigen wir wirklicheine Transaktion oder gibt es einen fachlich sinnvollen Plan B?“
- 98. #WISSENTEILEN „Starbucks does notknow Two-Phase-Commit“ http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html
- 99. #WISSENTEILEN The Real Worldis not transactional!
- 100. #WISSENTEILEN The Online Worldis not transactional!
- 101.
- 102. #WISSENTEILEN Der “Plan B“ Produktim Warenkorb 8
- 103. #WISSENTEILEN Plan B: LazyEvaluation a.k.a. die „es wird schon gutgehen“ Strategie • TX fachlich aufsplitten, sequentiell durchführen und schauen, ob es klappt • im Problemfall alternative Logik ausführen
- 104. #WISSENTEILEN Plan B: LazyEvaluation Produkt im Warenkorb 8
- 105. #WISSENTEILEN Plan B: LazyEvaluation Produkt im Warenkorb 8
- 106. #WISSENTEILEN Plan B: LazyEvaluation Produkt im Warenkorb decrement 8
- 107. #WISSENTEILEN Plan B: LazyEvaluation Produkt im Warenkorb decrement 8 – 1 = 7
- 108. #WISSENTEILEN Plan B: LazyEvaluation eXtended Produkt im Warenkorb letzter bekannter Bestand = 10 decrement 8 – 1 = 7 if stock > 0 else …
- 109. #WISSENTEILEN Plan B: LazyEvaluation eXtended+ Produkt im Warenkorb letzter bekannter Bestand = 10 1. stock? 8 – 1 = 7 2. decrement!
- 110. #WISSENTEILEN#WISSENTEILEN Plan B? Schön& gut, aber ich brauche meine Transaktionen! Was aber, wenn …?
- 111. #WISSENTEILEN Plan B -Strategy #3: Beeing Optimistic Produkt im Warenkorb, letzter bekannter Bestand = 1 0
- 112. #WISSENTEILEN#WISSENTEILEN Plan B? Schön& gut, aber ich brauche meine Transaktionen!
- 113.
- 114.
- 115. #WISSENTEILEN Fachliche TX überServicegrenzen hinweg
- 116. #WISSENTEILEN (Quelle: Microservices Pattern,Chris Richardson)
- 117. #WISSENTEILEN (Quelle: Microservices Pattern,Chris Richardson)
- 118. #WISSENTEILEN (Quelle: Microservices Pattern,Chris Richardson) „Sichtbarkeit" Order Service „Sichtbarkeit“ Customer Service
- 119.
- 120. #WISSENTEILEN Wie garantiere ichdie Konsistent der Daten über Servicegrenzen hinweg?
- 121.
- 122.
- 123.
- 124. #WISSENTEILEN Geänderte Servicegrenzen • technologischeine super Lösung, aber … • Problem der Verantwortlichkeiten • Problem Bounded Context / Domänen Modell • Vorteile der Microservices gehen verloren • „Big Ball of Mud“ lässt grüßen
- 125.
- 126.
- 127. #WISSENTEILEN Die „XA“ Strategie Btw: DB locks Btw:Chatty O(4n) mit Retries = (n^2) Btw: CAP Theorem
- 128. #WISSENTEILEN Verteilte Transaktionen viaXA • aus Developer-Sicht wie lokale TX, aber … • Verlust der losen Kopplung, da synchrone IPC • kein Support durch „moderne Plattformen“* * Cloud-Komponenten, noSQL, MQs
- 129.
- 130. #WISSENTEILEN Die „DIY 2PC“ Strategie* *Nein, daswillst du nicht. Glaube mir!
- 131. #WISSENTEILEN Strategie #4 Business TXvia SAGA Pattern
- 132. #WISSENTEILEN Quelle: SAGAS, Hector Garcia-Molina &Kenneth Salem, January 1987 Die „Saga“ Strategie
- 133. #WISSENTEILEN Verteilte Transaktionen viaSAGAs SAGA Idee: Abbilden einer verteilten fachlichen Transaktion durch eine Abfolge lokaler Transitionen / Transaktionen
- 134.
- 135. #WISSENTEILEN Verteilte Transaktionen viaSAGAs • Konsistenz von Daten zwischen Services wird durch eine wohldefinierte Abfolge lokaler Transitionen/Transaktionen erreicht. • Service kommuniziert „erfolgreiche“ lokale Transition/Transaktion an den nächsten beteiligten Service*. *mehr dazu später
- 136.
- 137.
- 138.
- 139.
- 140.
- 141.
- 142. #WISSENTEILEN Wow, that is simple! Whatcan go wrong?
- 143.
- 144.
- 145. #WISSENTEILEN Die „Saga“ Strategie CA = CompensationAlgorith a.k.a. Compensation Transaction
- 146. #WISSENTEILEN Die „Saga“ Strategie CA = CompensationAlgorith a.k.a. Compensation Transaction „Every Ti has its Ci“
- 147. #WISSENTEILEN Verteilte Transaktionen viaSAGAs • wohldefinierte Abfolge von Compensation Algorithms realisieren verteiltes Rollback • Compensation Algorithms sind fachlicher Code und somit Applikationslogik • Abfolge von lokalen TX & CAs kann beliebig komplex werden!
- 148.
- 149. #WISSENTEILEN Steuerung von SAGAs TX1 TX 2 TX 3 TX 4 TX 5 TX 6 order = PENDING item = PENDINGAPPORVED APPORVED
- 150. #WISSENTEILEN Steuerung von SAGAs •Choreographie • Orchestrierung
- 151. #WISSENTEILEN Steuerung von SAGAs •Choreographie • Orchestrierung
- 152. #WISSENTEILEN Choreographie von SAGAs •implizite Sequenzsteuerung • verteilte Koordination durch Eventfluss • „Wissen“ liegt bei den beteiligten Services
- 153.
- 154.
- 155.
- 156.
- 157.
- 158.
- 159. #WISSENTEILEN Choreographie von SAGAs •pro lose gekoppelt (Teilnehmer kennen sich nicht) relativ einfach zu implementieren • contra i.d.R. zyklische Abhängigkeiten erhöhte Komplexität im Domänen-Modell kein zentraler Business-Code (wann valide?)
- 160. #WISSENTEILEN Choreographie von SAGAs •btw lose Kopplung Teilnehmer kennen sich zwar nicht, wissen aber genau, was bei einem Event zu tun und wie im Anschluss – durch ein eigenes Event – zu antworten ist (a.k.a. pseudo lose Kopplung)
- 161. #WISSENTEILEN Steuerung von SAGAs •Choreographie • Orchestrierung
- 162. #WISSENTEILEN Orchestrierung von SAGAs •explizite Sequenzsteuerung • zentraler SAGA-Koordinator im Service • Command / Handler Pattern • beteiligte Services haben kein „Wissen“
- 163.
- 164.
- 165.
- 166.
- 167.
- 168.
- 169.
- 170.
- 171.
- 172.
- 173.
- 174. #WISSENTEILEN Orchestration von SAGAs •pro Logik ist einfach(er) zu verstehen fachliche Kopplung nur unidirektional keine zyklischen Abhängigkeiten Separation of Concerns (Domain Logic vs. TX)
- 175. #WISSENTEILEN Orchestration von SAGAs •contra „Smart Orchestrator & Dump Services“ Pattern, d.h. Risiko, zu viel Business Logic im Orchestrator zu zentralisieren
- 176. #WISSENTEILEN Orchestration von SAGAs •btw Orchestrator Will man den wirklich selber bauen? Nein! Alternative 1: Saga Framework Alternative 2: Lightweight Workflow Engine
- 177.
- 178. #WISSENTEILEN Konsistenz von Datenund Nachrichten • Services veröffentlichen „Erfolgs“-Nachricht direkt nach lokaler TX • lokale TX und „Erfolgs“-Nachricht sind atomare Einheit aus Sicht des Services • garantierte Beendigung der Business TX* *Message Broker buffered bei Bedarf die Message
- 179. #WISSENTEILEN Konsistenz von Datenund Nachrichten
- 180. #WISSENTEILEN Konsistenz von Datenund Nachrichten
- 181. #WISSENTEILEN Konsistenz von Datenund Nachrichten
- 182. #WISSENTEILEN Konsistenz von Datenund Nachrichten
- 183. #WISSENTEILEN Konsistenz von Datenund Nachrichten
- 184. #WISSENTEILEN Fehlende Isolation • SAGA= ACD (ACID ohne Isolation) • fehlende Isolation kann zu Anomalien führen (lost updates, dirty reads, event race condition) • Anomalien müssen soweit minimiert bzw. verhindert werden, dass sie fachlich vertretbar sind!
- 185.
- 186. #WISSENTEILEN Wer oder wasist eigentlich für die UI zuständig?
- 187. #WISSENTEILEN UI Integration Meins, deins,unser? • Wer liefert die UI? • Wo baue ich die UI zusammen? • Wie baue ich die UI zusammen?
- 188. #WISSENTEILEN Client Side viaBrowser • Hyperlinks (je eine Seite pro Service) • Client Side Composition (e.g. Angular, Node) • iFrame („fake“ Document Component Model) • AJAX (CORS Problem, „blank“ Page) • JavaScript Voodoo (via „myLib“) • HTML Imports (Teil der WebComponts Spec)
- 189.
- 190.
- 191. #WISSENTEILEN Server Side • ServerSide Include (SSI) • Edge Side Include (ESI) • UI Gateway
- 192. #WISSENTEILEN Server Side (SSI) •Page Composition auf Web Server Level • Server Side Scripting Language • einfach Syntax inkl. Kontroll-Direktiven (if, …) • erlaubt u.a. <!--#include file|virtual=„…“ --> • Apache httpd, LiteSpeed, nginx, lighttpd, IIS
- 193. #WISSENTEILEN Server Side (ESI) •Page Composition auf Edge Server Level • XML basierte Syntax • erlaubt u.a. <esi:include src=„…“ onerror=„…“ /> • CDN (Akamai) • Proxy Caching Server (Varnish, Squid, Mongrel)
- 194. #WISSENTEILEN UI Gateway • PageComposition auf App (Server) Level • Single Point of Entry ruft Service auf, baut aus Ergebnissen UI zusammen und liefert sie aus Achtung: Web UI / API Monolith! Achtung : Kein Platz für Logik(!?)
- 195.
- 196.
- 197.
- 198. #WISSENTEILEN Warum ein APIGateway? • Clients mit unterschiedlichsten Anforderungen kommunizieren mit dem Backend. • Client ruft mehrere Services auf und aggregiert intern das Ergebnis (Chatty Communication). • Direkte Kommunikation führt zu starker Abhängigkeit zwischen Clients und Services.
- 199.
- 200.
- 201.
- 202. #WISSENTEILEN Was genau istein API Gateway? • „Haupteingang“ für Anwendungen, um auf Daten, Geschäftslogik oder Funktionen der Backend-Services zuzugreifen. • Zusätzlicher Layer zur Entkoppelung von Client(s) und Backend-Services.
- 203.
- 204.
- 205. #WISSENTEILEN Aufgaben des APIGateway • „Entkopplung (Client / Services) • Transformation (Payload, Header, …) • Routing (Registry, Discovery) • Orchestration (Aggregation, Fallback) • …
- 206. #WISSENTEILEN Aufgaben des APIGateway • Security (DDoS, Authorization, Tokens, …) • Caching (Response, CDN, …) • Resilience (Timeout, Bandwidth, Throtteling, …) • Staging & Versioning (dev, test, prod, mocks, …) • Analytics (Performance, Traces, …) • …
- 207. #WISSENTEILEN Aufgaben des APIGateway • SLAs (Bandwith, Response Time, …) • Contracts (API-Keys, …) • Mocking
- 208. #WISSENTEILEN DIY vs. Out-of-the-Box •Was genau möchte man erreichen? • DIY macht nur selten Sinn! • Netflix Zuul • AWS Gateway • Kong, Treafik, … • viele, viele mehr …
- 209.
- 210.
- 211.
- 212.
- 213.
- 214.
- 215.
- 216.
- 217.
- 218.
- 219. #WISSENTEILEN Best Practices: strategisch •solange wie möglich hinauszögern • starre Kopplung vermeiden • Consumer-Driven Contracts • Semantic Versioning (Major.Minor.Patch) • Koexistenz mehrerer Endpoints • Konkurrierende Service Versionen
- 220.
- 221. #WISSENTEILEN Ver 0.6.0 { "id": 1, "fullName":"Max Mustermann", "emailAdress": "max.mustermann@openknowledge.de" } Change request: add gender
- 222. #WISSENTEILEN Ver 0.7.0 { "id": 1, "fullName":"Max Mustermann", "gender": true, "emailAdress": "max.mustermann@openknowledge.de" }
- 223. #WISSENTEILEN Ver 0.7.0 { "id": 1, "fullName":"Max Mustermann", "gender": true, "emailAdress": "max.mustermann@openknowledge.de" } Change request: split „fullName“
- 224. #WISSENTEILEN Ver 0.8.0 { "id": 1, "firstName": "Max", "lastName" : "Mustermann", "gender": true, "emailAdress": "max.mustermann@openknowledge.de" }
- 225. #WISSENTEILEN Ver 0.8.0 { "id": 1, "firstName": "Max", "lastName" : "Mustermann", "gender": true, "emailAdress": "max.mustermann@openknowledge.de" } Missing fullName!
- 226. #WISSENTEILEN Ver 0.8.0 { "id": 1, "fullName":"Max Mustermann", "firstName" : "Max", "lastName" : "Mustermann", "gender": true, "emailAdress": "max.mustermann@openknowledge.de" } Change request: structure for „name/fullName“
- 227. #WISSENTEILEN Ver 0.9.0 { "id": 1, "fullName"{ "firstName" : "Max", "lastName" : "Mustermann", } "gender": true, "emailAdress": "max.mustermann@openknowledge.de" }
- 228. #WISSENTEILEN Ver 0.9.0 { "id": 1, "fullName"{ "firstName" : "Max", "lastName" : "Mustermann", } "gender": true, "emailAdress": "max.mustermann@openknowledge.de" } Semantic of fullName!
- 229. #WISSENTEILEN Ver 0.9.0 { "id": 1, "fullName":"Max Mustermann", "name" { "firstName" : "Max", "lastName" : "Mustermann", } "gender": true, "emailAdress": "max.mustermann@openknowledge.de" }
- 230. #WISSENTEILEN Ver 1.0.0 { "id": 1, "fullName":"Max Mustermann", “name" { "firstName" : "Max", "lastName" : "Mustermann", } "gender": "male", "emailAddress": "max.mustermann@openknowledge.de" }
- 231. #WISSENTEILEN Ver 1.0.0 { "id": 1, "fullName":"Max Mustermann", “name" { "firstName" : "Max", "lastName" : "Mustermann", } "gender": "male", "emailAddress": "max.mustermann@openknowledge.de" }
- 232. #WISSENTEILEN „Be conservative inwhat you do, be liberal in what you accept.“ Postel’s Law (a.k.a. robustness principle)
- 233. #WISSENTEILEN Best Practices: technisch •gar nicht (via „ignore“) • gar nicht (via zusätzlicher Ressourcen) • gar nicht (via erweiterbarer Datenformate) • Versionsnummer in URL • Versionsnummer in Header (via Custom-Header) • Content Negotiation (via Accept-Header)
- 234.
- 235.
- 236.
- 237.
- 238. #WISSENTEILEN via Services Service V1 Service V2 Versioning OldEndpoint New Endpoint
- 239.
- 240. #WISSENTEILEN „Wo bitte istdas Problem? Dann habe ich eben X Versionen!“ (naiver Entwickler)
- 241.
- 242.
- 243. #WISSENTEILEN Evolution: Microservices Wie istdie Anzahl der möglicher Konstellationen?
- 244. #WISSENTEILEN Evolution: Microservices fixe Reihenfolge:N-1 Kombinationen (N=4; 3)
- 245. #WISSENTEILEN Evolution: Microservices Beliebige Reihenfolge:2N-2 Kombinationen (N=4; 14)
- 246. #WISSENTEILEN „REST APIs don‘tneed a versioning strategy – they need a change strategy!“ Ben Morris (Ben Morris Blog)
- 247.
- 248.
- 249.
- 250.
- 251.
- 252.
- 253.
- 254.
- 255. #WISSENTEILEN Are u readyfor Microservices?
- 256. #WISSENTEILEN „Ein Microservice kommt seltenallein!“ Lars Röwekamp
- 257.
- 258.
- 259.
- 260.
- 261.
- 262.
- 263.
- 264. #WISSENTEILEN Kontakt LARS RÖWEKAMP CIO NEWTECHNOLOGIES lars.roewekamp@openknowledge.de +49 (0)441 4082 – 0 @mobileLarson @_openknowledge OFFENKUNDIGGUT
- 265. #WISSENTEILEN Bildnachweise 1/2 #25: ©marekukiasz– shutterstock.com #42: © print10 – istockphoto.com #90: © vasakna – fotolia.com #113: © vadymvdrobot – fotolia.com t #223: © Rawpixel.com – shutterstock.com #260: © RichVintage - istockphoto.com
- 266. #WISSENTEILEN Bildnachweise 2/2 All otherpictures inside this presentation orginate from pixabay.com or were created by my own.