Microservices Migration: Vom Monolithen zu Microservices
1 gefällt mir378 aufrufe
Das Dokument bietet einen umfassenden Leitfaden zur Migration von Monolithen zu Mikroservices, einschließlich Strategien wie 'Big Bang', 'Strangler Application' und verschiedene Stufen der Entkopplung. Es werden grundlegende Prinzipien wie Single Responsibility und hohe Kohäsion behandelt, sowie Herausforderungen und Lösungen im Zusammenhang mit Microservices, wie Service Discovery und Fehlertoleranz. Zudem wird die Bedeutung einer strukturierten Migrationsstrategie und des Designs von Mikroservices hervorgehoben.
Microservices Migration: Vom Monolithen zu Microservices
- 1. #WISSENTEILEN The MICROSERVICES SURVIVAL GUIDE #WISSENTEILEN THE PRACTICAL SKILLS YOU‘LL NEED TO MIGRATE A MONOLITH by Lars Röwekamp a.k.a @mobileLarson
- 2. #WISSENTEILEN ÜBER OPEN KNOWLEDGE Branchenneutrale Softwareentwicklung & IT-Beratung
- 3. #WISSENTEILEN ÜBER MICH Wer bin ich - und wenn ja, wie viele? • CIO New Technologies • Enterprise & Mobile • Autor, Speaker, Coach & Mentor • Snowboard & MTB Enthusiast Lars Röwekamp (a.k.a. @mobileLarson) LR
- 7. #WISSENTEILEN bekannte Architektur IDE freundlich DB als „Source of Truth“
- 8. #WISSENTEILEN einfach zu verteilen einfach zu testen einfach zu deployen
- 10. #WISSENTEILEN #SOC: #API: #DRY: #LOD: #DDD: #YAGNI: Separation of Concerns High Cohesion & Low Coupling Don‘t repeat yourself Law of Demeter Domain Driven Design You aren‘t going to need it
- 11. #WISSENTEILEN
- 12. #WISSENTEILEN
- 13. #WISSENTEILEN
- 14. #WISSENTEILEN
- 23. #WISSENTEILEN „Glaub mir, Microservices sind das ‚next big Thing‘!“
- 24. #WISSENTEILEN Microservices Charateristics(Things that make a Microservice a Microservice)
- 25. #WISSENTEILEN „Functional Decompensation“ „Single Responsibility Pattern“ „Explicitly Published Interfaces“ „Independently upgrade, ...“ „Lightweight Communication“
- 27. #WISSENTEILEN (c) Martin Fowler: https://www.martinfowler.com/bliki/MicroservicePremium.html
- 28. #WISSENTEILEN Microservices-basierte Architektur erfolgreiche Software Entwicklung Continuous Delivery / Deployment ermöglichtermöglicht kleine, agile, unabhängige, cross-functional Teams ermöglicht Services sind unabhängig testbar & deploybar Teams besitzen Services Prozesse ArchitekturOrganisation
- 30. #WISSENTEILEN Baustelle #1 Architektur „Was ist die richtige Größe für einen Service und wie sieht am Ende meine Service-Landkarte aus?“
- 32. #WISSENTEILEN Baustelle #2 Organisation „Wie stelle ich meine Teams auf agiles Vorgehen um und was bedeuten das für die restliche Organisation?“
- 34. #WISSENTEILEN Baustelle #3 Prozesse „Was muss ich tun, um CI/CD zu ermöglichen und welchen Grad der Automatisierung benötige ich dazu?“
- 35. #WISSENTEILEN Migration? Wir brauchen eine Strategie
- 41. #WISSENTEILEN Der „Big Bang“ Microservice-basierte Anwendung „from the scratch“ neu aufbauen pro: • keine Altlasten parallel zu pflegen contra: • sehr viele NEUE Baustellen gleichzeitig
- 42. #WISSENTEILEN Der „Big Bang“ „The only thing a Big Bang rewrite garantuees is a Big Bang!“ Martin Fowler
- 45. #WISSENTEILEN Die „Strangler Application“ Microservice-basierte Anwendung „parallel“ zu bestehendem Monolithen aufbauen pro: • geringeres Risiko dank inkrementeller Lernkurve contra: • parallele Pflege von zwei Systemen
- 47. #WISSENTEILEN Die „Stop Digging“ Strategie „Whenever you find yourself in a hole, you should stop digging!“ The Law of Hole
- 48. #WISSENTEILEN Die „Stop Digging“ Strategie Neue Funktionalität nicht im Monolithen implementieren sondern in einem eigenen Microservice • vorgeschalteter Router als Logik-Dispatcher • Glue-Code zur Data-Integration
- 49. #WISSENTEILEN Die „Stop Digging“ Strategie Glue-Code als Anti-Corruption Layer, zur sauberen Trennung der Domain Modelle von Microservice und Monolith. Datenintegration? • Aufruf einer Remote API des Monolithen • direkter Zugriff auf DB des Monolithen • Halten einer eigenen Daten-Kopie inkl. Sync.
- 52. #WISSENTEILEN Die „Stop Digging“ Strategie pro: • Monolith wird nicht noch unwartbarer • Service ist „unabhängig“ vom Monolithen • Microservices-Erfahrung kann langsam wachsen contra: • Probleme des Monolithen bleiben bestehen!
- 54. #WISSENTEILEN Die „Split Front/Back“ Strategie Trennen des Frontends von Business-Logik und Persistenz. • aus eins mach zwei • „natürliche“ Trennung zwischen Presentation- Logik und Business-Logik nutzen • Zugriff auf Backend via coarse-grained API
- 55. #WISSENTEILEN Die „Split Front/Back“ Strategie
- 56. #WISSENTEILEN Die „Split Front/Back“ Strategie
- 57. #WISSENTEILEN Die „Split Front/Back“ Strategie pro: • Möglichkeit, beide „Welten“ getrennt zu entwickeln, deployen und skalieren • Remote API, z.B. REST, für zukünftige Microservices als positives Abfallprodukt contra: • keine finale Lösung sondern eher ein Übergang
- 59. #WISSENTEILEN Die „Extract Services“ Strategie Bestehende Module des Monolithen extrahieren und in „standalone“ Microservices überführen • Monolith schrumpft mit jedem Service • am Ende bleibt kein/ein extrem kleiner Monolith • Feature Toggles als „Weiche“ nutzen
- 60. #WISSENTEILEN Die „Extract Services“ Strategie Vorgehen beim Herauslösen von Modulen in eigene Microservices: • Coarse-grained Interface definieren • Module standalone lauffähig machen • ggf. Features in Monolithen “deaktivieren“* *Achtung: kann teure Rückbaumaßnahmen bedeuten
- 61. #WISSENTEILEN Die „Extract Services“ Strategie
- 62. #WISSENTEILEN Die „Extract Services“ Strategie
- 63. #WISSENTEILEN Die „Extract Services“ Strategie
- 64. #WISSENTEILEN Die „Extract Services“ Strategie pro: • Step-by-Step Migration • Monolith verschwindet im Laufe der Zeit contra: • Auslagern von Services bedeutet Aufwand in beiden Welten
- 66. #WISSENTEILEN FAQs • Wie komme ich zu den richtigen Services? • Was ist die richtige Anzahl an Services? • Was ist die richtige Migrationsreihenfolge? • Wie migriere ich die DB richtig? • Welcher Herausforderungen erwarten mich? • Und der Monolith? Den gibt es doch auch noch!
- 68. #WISSENTEILEN
- 69. #WISSENTEILEN
- 70. #WISSENTEILEN
- 71. #WISSENTEILEN
- 72. #WISSENTEILEN Der goldene Schnitt „Wie schneide ich Microservices richtig?“ (DI 9:00 – 12:30 Uhr)Speaker Arne Limburg
- 73. #WISSENTEILEN Guter Service, schlechter Service Single Responsibility • Service deckt genau eine Fachlichkeit ab • Bounded Context
- 74. #WISSENTEILEN Guter Service, schlechter Service Share Nothing • „private“ Implementierung • „private“ Datenbank • Kommunikation ausschließlich via APIs
- 75. #WISSENTEILEN Guter Service, schlechter Service Idependence • planen • entwickeln • bauen • testen • “live“ stellen
- 76. #WISSENTEILEN Guter Service, schlechter Service Polyglot • “best X for the job“ mit dem Ziel der Skalierung • Technology • Data Management • Business Logic • Skalierung
- 77. #WISSENTEILEN Guter Service, schlechter Service • hohe Cohesion innerhalb des Service • lose Koppelung zwischen Services • Änderungshäufigkeit ähnlich • businesskritische Prozesse nah beisammen • Eventual Consistency akzeptabel • Designe for Failure
- 78. #WISSENTEILEN Wie groß ist Klein
- 79. #WISSENTEILEN Wie groß ist klein „Don‘t make services as small as possible.“ (Stefan Tilkov)
- 80. #WISSENTEILEN Wie groß ist klein „Small enough and not smaller“ (Sam Newmann)
- 81. #WISSENTEILEN Wie groß ist klein „Created by no more than a handful of people“ (Michael Feathers)
- 82. #WISSENTEILEN Wie groß ist klein „Microservices is a label, not a description.“ (Martin Fowler)
- 83. #WISSENTEILEN Wie groß ist klein „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)
- 84. #WISSENTEILEN Wie groß ist klein Size of microservice „guter“ Microservice Modularisierung Teamgröße Austauschbarkeit Infrastruktur Verteilte Kommunikation Transaktionen & Konsistenz
- 85. #WISSENTEILEN Wie groß ist klein Team Size
- 86. #WISSENTEILEN Wie groß ist klein Team Size
- 87. #WISSENTEILEN Size of microservice Number of microservices
- 89. #WISSENTEILEN
- 90. #WISSENTEILEN Motivation für Microservices* • Agilität? • Robustheit? • Kosten? • Innovationen? *es kann nur eine höchste Priorität geben
- 91. #WISSENTEILEN Einflussfaktoren für die Migration • Lernkurve? • Risikominimierung? • Sichtbarkeit / Business Mehrwert? • Aufwand? • Bindung von Kapazitäten? • Abhängigkeiten?
- 92. #WISSENTEILEN Phase 1: Warm up Starten mit einem möglichst einfachen Service*, der wenig Kopplung zur restlichen Anwendung hat. • Fokus auf Operational Readiness (CI/CD) • Fokus auf Microservices Infrastruktur* • Fokus auf verteilter Architektur* • Fokus auf Organizational Change *(e.g. Service Mesh)
- 93. #WISSENTEILEN Phase 1: Warm up *(Martin Fowler: Microservices Prerequisites) • Rapid Provisioning • Basic Monitoring • Rapid App Deployment
- 94. #WISSENTEILEN Phase 1: Warm up „alter“ Monolith mit Funktionalität Authentication „neuer“ Monolith neuer Authentication Service Migration neue Delivery Infrastructure
- 95. #WISSENTEILEN Phase 2: Minimize Dependencies Wähle Services ohne/mit wenig Rückkoppelungen zum Monolithen. • Rückkoppelungen forcieren Abhängigkeiten in der Entwicklung und der Release-Planung • minimiere bestehende Abhängigkeiten durch Anti-Corruption Layer
- 96. #WISSENTEILEN Phase 2: Minimize Dependencies „alter“ Monolith mit Abhängigkeiten „neuer“ Monolith ohne Abhängigkeiten ausgelagerter Service mit unidirektionalen Abhängigkeiten MigrationMigration
- 97. #WISSENTEILEN Phase 2: Minimize Dependencies „alter“ Monolith mit Abhängigkeiten „neuer“ Monolith ohne Abhängigkeiten ausgelagerter Service mit bidirektionalen Abhängigkeiten und ACL Migration ACL Migration
- 98. #WISSENTEILEN Phase 3: Sticky first Wähle stark verwobene Fachlichkeit und löse diese sauber auf („DDD ist dein Freund“) • oft hindern einen unsaubere, historisch gewachsene Domänenmodelle daran, weitere sinnvolle Services herauszulösen
- 99. #WISSENTEILEN Phase 3: Sticky first „alter“ Monolith mit sticky Session „neuer“ Monolith ohne sticky Session ausgelagerte Services Migration Customer Session Customer Profile Customer Payment Method Customer Wishlist
- 100. #WISSENTEILEN Phase 4: Decouple vertically Löse Services komplett inklusive „user facing“ Komponenten und DB heraus. • Bereitstellung von entwicklerfreundlichen APIs für moderne UIs via Facade Service bringt lediglich Quick-Wins. • erst ein Aufsplitten inkl. Trennung der Daten bringt echten Mehrwert
- 101. #WISSENTEILEN Phase 4: Decouple vertically „alter“ Monolith Services Migration „neuer“ Monolith user facing backend logic data / comms neue UI / UX neue API
- 102. #WISSENTEILEN Phase 5: Decouple important stuff Löse Services mit höchstem Mehrwert heraus. • Es gilt Kosten gegen Nutzen abzuwägen. • Was ist wichtig? • Was ändert sich häufig? • Was muss unabhängig skalieren können?
- 103. #WISSENTEILEN Phase 5: Decouple important stuff „alter“ Monolith mit wichtigster Komponente „neuer“ Monolith ohne wichtigste Komponente ausgelagerte wichtigste Komponente Migration
- 104. #WISSENTEILEN Phase 6: Decouple capabilities* Wäge sinnvoll zwischen Reuse und Rewrite ab. • nicht blind altem Code übernehmen • alter Code beinhaltet oft Boilerplate und berücksichtigt keine Domänengrenzen • retire and rewrite als Alternative • IKEA Effekt lässt uns wachsen *(… and not code!)
- 105. #WISSENTEILEN Phase 6: Decouple capabilities „alter“ Monolith „neuer“ Monolith Customer Profile Service Migration Pricing Service reuse rewrite extract? retire? neue Services via reuse oder rewrite
- 106. #WISSENTEILEN Phase 6: Go Marco first, then Micro Starte mit Bounded Contexts (DDD) als Servicegrenzen und verfeinere später bei Bedarf. • kleine Service bringen oft neue Abhängigkeiten • kleine Services spiegeln meist DB Sicht wieder* Distributed Monolith vs. Microservices *(Anemic Services)
- 107. #WISSENTEILEN Phase 6: Go Marco first, than Micro Migration Step 1 Migration Step 2 „alter“ Monolith „neuer“ Monolith Buy Service Checkout Service Shopping Cart Service Hyperlink
- 108. #WISSENTEILEN Phase 7: Atomic Evolutionary Steps Plane die Migration in „atomaren“ Schritten. Schaffe dabei stabile Zwischenstände. • Migration kann aus verschiedensten Gründen gestoppt werden. Rückbau? Chaos? • Short Term Plans vs. Long Term Plans
- 109. #WISSENTEILEN Phase 7: Atomic Evolutionary Steps (Quelle: Thoughtworks)
- 110. #WISSENTEILEN Migration RoadmapW arm Up Minimizedependencies Stickyfirst Decouplevertically Decoupleimportantstuff Decouplecapabilities GoMacro,thanMicro Atomicsteps Step 1 Step 2 Step 3 Step N
- 112. #WISSENTEILEN Es könnte alles sooo einfach sein!
- 113. #WISSENTEILEN
- 114. #WISSENTEILEN
- 116. #WISSENTEILEN Microservices Q&A(Things you better care about!)
- 117. #WISSENTEILEN „Welche Services laufen?“ „Sind die Routing-Infos aktuell?“ „Gibt es ‚Chains of Failure‘?“ „Message-Typen im System?“ „Sind die Services sicher?“ „Sind die Daten konsistent?“
- 119. #WISSENTEILEN Wo ist mein Service ... • Anzahl der Service-Instanzen variiert • Adressen werden dynamisch zugewiesen • Client muss den „richtigen“ Service finden • Services registrieren sich bei Registry • Client fragt bei Registry nach
- 120. #WISSENTEILEN
- 121. #WISSENTEILEN
- 122. #WISSENTEILEN Service Registry/Discovery PLUS • Load Balancing • Failure Detection & Health Checks • Cluster Replication • Key/Value Storage
- 123. #WISSENTEILEN Wo ist mein Service ... Client-Side Service Discovery • Netflix Eureka / Consul + Ribbon Client • Apache Zookeeper + Zookeeper Client Server-Side Service Discovery • AWS Elastic Load Balancer • Consul / NGNIX Plus + Consul Templating
- 124. #WISSENTEILEN Wo ist mein Service ... Client-Side Service Discovery • Netflix Eureka / Consul + Ribbon Client • Apache Zookeeper + Zookeeper Client Server-Side Service Discovery • AWS Elastic Load Balancer • Consul / NGNIX Plus + Consul Templating Und was ist mit Kubernetes?
- 126. #WISSENTEILEN
- 127. #WISSENTEILEN
- 129. #WISSENTEILEN
- 130. #WISSENTEILEN
- 132. #WISSENTEILEN
- 133. #WISSENTEILEN Not available, please call later ... Ziel ist es, ein „elastisches“, sich selbst regenerierendes System zu schaffen, um so eine bestmögliche Verfügbarkeit zu gewährleisten.
- 134. #WISSENTEILEN Not available, please call later ... Das System sollte jederzeit fachlich sauber funktionieren.
- 135. #WISSENTEILEN Im Fokus stehen ... Verfügbarkeit Fehlertoleranz
- 136. #WISSENTEILEN Pattern: Traffic Avoidance • Traffic minimieren via Caching • Traffic optimieren via Batching
- 137. #WISSENTEILEN Pattern: Design for Failure • Fehler als Normalfall nicht als Ausnahme • Automatische Fehlerbehandlung • Netflix stellt regelmäßig Systeme ab
- 138. #WISSENTEILEN Pattern: Fail sooner than later • Probleme frühzeitig erkennen • Fehler gar nicht erst entstehen lassen • Monitoring von Metrics & Response Times • Monitoring von Buisness KPIs
- 139. #WISSENTEILEN Pattern: Meaningful Responses • liefern von Fallbacks / Defaults • Services-Consumer fehlertolerant • wie beeinflusst ein Fehler die UX?
- 140. #WISSENTEILEN
- 141. #WISSENTEILEN Not available, please call later ... • Load Balancing (als Basis von „SLAs“) • Retry on Failure (Temporary Failures) • Timeouts (Poor Mans Circuit Breaker) • Circuit Breaker („Sicherung“ für Fail Fast ) • Bulkheads (Dedicated Threadpools)
- 147. #WISSENTEILEN Not available, please call later ... • DIY Pattern? No way! • Hystrix, the one and only! Not anymore. • MicroProfile Fault Tolerance • Istio Service Mesh • Traefik Gateway • …
- 149. #WISSENTEILEN
- 150. #WISSENTEILEN
- 151. #WISSENTEILEN
- 152. #WISSENTEILEN
- 153. #WISSENTEILEN
- 154. #WISSENTEILEN
- 155. #WISSENTEILEN
- 157. #WISSENTEILEN Sicher ist sicher! Sicher? • Application Level (Authentication) • User Level (Authorization) • Network Level (Ports, OS, Protocols, ...)
- 158. #WISSENTEILEN Sicher ist sicher! Sicher? • Single Sign On? Single Sign Off? • Security Context Propagation / Delegation? • „Deep“ Auth vs. Border Access Control?
- 159. #WISSENTEILEN Sicher ist sicher! Sicher? • Authentication a.k.a. Hotelrezeption • Authorization a.k.a. Zimmerschlüssel
- 160. #WISSENTEILEN Sicher ist sicher! Sicher? • 401 „Unauthorized“ meint eigentlich “Unauthenticated“ • 403 „Forbidden“ meint eigentlich „Unauthorized“
- 161. #WISSENTEILEN Sicher ist sicher! Sicher? • Server based Security via Session auf dem Server • Token based Security via Austausch von Token
- 164. #WISSENTEILEN Sicher ist sicher! Sicher? JWT (JSON Web Token) • neue, einfache und kompakte Specs • Token plus public & private „Claims“ • digitale Signatur und/oder Encryption • als Bearer Token und für SSO
- 165. #WISSENTEILEN
- 166. #WISSENTEILEN Warum JWT? • ... vs. SWT • ... vs. SAML • public/private Keys • extrem kompakt • JSON
- 167. #WISSENTEILEN Sicher ist sicher! Sicher? JWT & API Goals • Authorize Request • Verify Sender • Avoid Man in the Middle • Expiration • Request Cloning
- 169. #WISSENTEILEN
- 170. #WISSENTEILEN
- 171. #WISSENTEILEN
- 172. #WISSENTEILEN
- 174. #WISSENTEILEN Alles im Blick • tech. Komponenten (e.g. Request/s in DB) • Business Metrics (Orders/min) • semantisches Monitoring als Frühwarnsystem • Team kann vor dem Fehler einschreiten • Team kann System permanent verbessern
- 175. #WISSENTEILEN
- 176. #WISSENTEILEN
- 177. #WISSENTEILEN Log Aggregation & Monitoring • Elastic Stack (Elastic Search, Logstash, Kibana) • via Log Appender (Socket Appender) • in Echtzeit • Logstash / Beats - collect • Elastic Search - store & search • Kibana - analyze & visualize
- 178. #WISSENTEILEN
- 179. #WISSENTEILEN Log Aggregation & Monitoring Alternativen? • Splunk • App Dynamics • New Relic • GreyLog (open source)
- 180. #WISSENTEILEN
- 181. #WISSENTEILEN
- 182. #WISSENTEILEN
- 183. #WISSENTEILEN
- 184. #WISSENTEILEN
- 186. #WISSENTEILEN
- 188. #WISSENTEILEN Sorry, configuration changed! • viele Service • viele Service Teams • viele Konfigurationen • viele Konfigurationsänderungen • Willkommen im Chaos!
- 189. #WISSENTEILEN
- 190. #WISSENTEILEN
- 191. #WISSENTEILEN Sorry, configuration changed! • Self-made • Configuration Manager (Netflix Archaius) • Service Discovery Server (Consul, …) • Automation Server (Puppet, Chef, …) • Vault „Secrets“ Server
- 193. #WISSENTEILEN
- 194. #WISSENTEILEN
- 196. #WISSENTEILEN Lessons Learned Priorisierung, welches Modul zu welchem Zeitpunkt als Microservice rausgelöst werden soll: • z.B. „einfache“ Module zuerst (Erfahrung sammeln), „Problemkinder“ danach (Mehrwerte schaffen) • Ranking: Change-Frequenz, Ressourcen- Verbrauch, Skalierung, Kommunikation, ...
- 197. #WISSENTEILEN Lessons Learned Ist das schon alles? • Zeitpunkt für DB-Migration will gut überlegt sein • Microservice-Infrastruktur Step-by-Step mit wachsender Anzahl an Services aufbauen (Registry, Gateway, Resilience ...)
- 198. #WISSENTEILEN Lessons Learned • Ohne Domain Driven Design geht es nicht • Ports & Adapter für einfachere Extraktion • explizite Service/Endpoint Ownership • Source-Versionierung statt toter Code • Monitoring ist die Basis für ALLES • Env-Var Dokumentation ist PFLICHT
- 199. #WISSENTEILEN Lessons Learned • Domäne vor Technologie • vermeide „Shared Data“ • nutze Events zur Synchronisation von Daten • nutze Events zur Kompensation (Business-TX) • gebe Async den Vorzug über Sync • Testing via Consumer-driven Contracts
- 200. #WISSENTEILEN Are u ready to Take-off?
- 201. #WISSENTEILEN
- 202. #WISSENTEILEN Martin sagt ... • Rapid Provisionierung • Basic Monitoring • Rapid App Deployment (Quelle: http://martinfowler.com/bliki/MicroservicePrerequisites.html)
- 203. #WISSENTEILEN Martin sagt ... (Quelle: http://martinfowler.com/bliki/MicroservicePrerequisites.html)
- 204. #WISSENTEILEN Are u ready for this ... powered by
- 205. #WISSENTEILEN Are u ready for this ... powered by
- 206. #WISSENTEILEN Are u ready for this ...
- 212. #WISSENTEILEN ? ? ?
- 213. #WISSENTEILEN Kontakt LARS RÖWEKAMP CIO NEW TECHNOLOGIES lars.roewekamp@openknowledge.de +49 (0)441 4082 – 0 @mobileLarson @_openknowledge OFFENKUNDIGGUT
- 214. #WISSENTEILEN Bildnachweise 1/3 #1: © fabrikaSimf – shutterstock.com #5: © Daniel Steger for openphoto.net #91: © marekuliasz – shutterstock.com #131: © Freedomz – shutterstock.com #141: © print10 – istockphoto.com #223: © RichVintage - istockphoto.com
- 215. #WISSENTEILEN Bildnachweise 2/3 #225: https://www.thoughtworks.com/insights/blog/microservices- how-large-enterprise-grew-doing-it #227: © embarc (mit freundlicher Genehmigung) #231: © marekuliasz - istockphoto.com #232: © alphaspirit - istockphoto.com #232: © newafrica - istockphoto.com
- 216. #WISSENTEILEN Bildnachweise 3/3 All other pictures inside this presentation orginate from pixabay.com or were created by my own.