OPEN KNOWLEDGE GmbH, profile picture
Hochgeladen vonOPEN KNOWLEDGE GmbH
321 aufrufe

Hands-On Microservices mit Java

Das Dokument erörtert die wichtigsten Aspekte des Service-Designs für Microservices, einschließlich Prinzipien wie das Single Responsibility Principle und die Notwendigkeit einer losen Kopplung. Es wird hervorgehoben, dass Microservices nach Geschäftsdomänen und begrenzten Kontexten gestaltet werden sollten, um inkonsistente Daten und enge Kopplungen zu vermeiden. Zudem wird die Rolle von Services wie dem Checkout-Service in einem Webshop und die Herausforderungen bei der Datenkonsistenz und Kommunikation zwischen den Services diskutiert.

Präsentation einbetten

Downloaden Sie, um offline zu lesen
1 / 174
2 / 174
3 / 174
4 / 174
5 / 174
6 / 174
7 / 174
8 / 174
9 / 174
10 / 174
11 / 174
12 / 174
13 / 174
14 / 174
15 / 174
16 / 174
17 / 174
18 / 174
19 / 174
20 / 174
21 / 174
22 / 174
23 / 174
24 / 174
25 / 174
26 / 174
27 / 174
28 / 174
29 / 174
30 / 174
31 / 174
32 / 174
33 / 174
34 / 174
35 / 174
36 / 174
37 / 174
38 / 174
39 / 174
40 / 174
41 / 174
42 / 174
43 / 174
44 / 174
45 / 174
46 / 174
47 / 174
48 / 174
49 / 174
50 / 174
51 / 174
52 / 174
53 / 174
54 / 174
55 / 174
56 / 174
57 / 174
58 / 174
59 / 174
60 / 174
61 / 174
62 / 174
63 / 174
64 / 174
65 / 174
66 / 174
67 / 174
68 / 174
69 / 174
70 / 174
71 / 174
72 / 174
73 / 174
74 / 174
75 / 174
76 / 174
77 / 174
78 / 174
79 / 174
80 / 174
81 / 174
82 / 174
83 / 174
84 / 174
85 / 174
86 / 174
87 / 174
88 / 174
89 / 174
90 / 174
91 / 174
92 / 174
93 / 174
94 / 174
95 / 174
96 / 174
97 / 174
98 / 174
99 / 174
100 / 174
101 / 174
102 / 174
103 / 174
104 / 174
105 / 174
106 / 174
107 / 174
108 / 174
109 / 174
110 / 174
111 / 174
112 / 174
113 / 174
114 / 174
115 / 174
116 / 174
117 / 174
118 / 174
119 / 174
120 / 174
121 / 174
122 / 174
123 / 174
124 / 174
125 / 174
126 / 174
127 / 174
128 / 174
129 / 174
130 / 174
131 / 174
132 / 174
133 / 174
134 / 174
135 / 174
136 / 174
137 / 174
138 / 174
139 / 174
140 / 174
141 / 174
142 / 174
143 / 174
144 / 174
145 / 174
146 / 174
147 / 174
148 / 174
149 / 174
150 / 174
151 / 174
152 / 174
153 / 174
154 / 174
155 / 174
156 / 174
157 / 174
158 / 174
159 / 174
160 / 174
161 / 174
162 / 174
163 / 174
164 / 174
165 / 174
166 / 174
167 / 174
168 / 174
169 / 174
170 / 174
171 / 174
172 / 174
173 / 174
174 / 174
#WISSENTEILEN Hands-On Microservices Arne Limburg & Lars Röwekamp @arneLimburg | @mobileLarson | @_openknowledge
#WISSENTEILEN Was genau ist eigentlich ein guter Microservice?
#WISSENTEILEN Functional Decompensation Single Responsibility Principle Share nothing* Consumer Contracts (a.k.a. Interfaces) Lightweight Communication Independently develop, test, deploy, run Heterogeneous (a.k.a. Polyglot) *share as little as possible
#WISSENTEILEN Bussiness Focused *time-to-market
#WISSENTEILEN
#WISSENTEILEN <set-up />
#WISSENTEILEN Service Design
#WISSENTEILEN Aufteilen nach Domänen Objekten Service Design
#WISSENTEILEN Aufteilen nach Domänen Objekten Service Design
#WISSENTEILEN „If every service has to be updated at the same time it’s not loosely coupled.“ Adiran Cockcroft
#WISSENTEILEN „If you have to know to much about surrounding services you don‘t have a bounded context.“ Adiran Cockcroft
#WISSENTEILEN Aufteilen nach Domänen Objekten Service Design
#WISSENTEILEN „Loosely coupled service oriented architecture with bounded contexts.“ Adiran Cockcroft
#WISSENTEILEN Bounded Context? • Klare Grenzen • Business-Prozesse • Inkonsistenzen vermeiden • e.g. „check out“ • e.g. „search products“ • e.g. „my recommendations“
#WISSENTEILEN Aufteilen nach Bounded Contexts Service Design
#WISSENTEILEN Aufteilen nach Bounded Contexts Service Design Was ist mit gemeinsam benutzen Objekten?
#WISSENTEILEN Aufteilen nach Bounded Contexts Service Design Sind die Objekte wirklich identisch oder heißen sie nur (zufällig) gleich?
#WISSENTEILEN Aufteilen nach Bounded Contexts Service Design Auch syntaktisch identische Objekte können zu unterschiedlichen Services gehören
#WISSENTEILEN Service Design Herausforderung: Daten konsistent?
#WISSENTEILEN Service Design Herausforderung: Daten konsistent • einen Data-Owner definieren • schreibend nur via Data-Owner
#WISSENTEILEN Web Shop
#WISSENTEILEN
#WISSENTEILEN Communication
#WISSENTEILEN Wie kommunizieren Services untereinander?
#WISSENTEILEN
#WISSENTEILEN Search Idee: Ein Search-Service liefert Suchergebnisse
#WISSENTEILEN Search Idee: Ein Search-Service liefert Suchergebnisse RESTfull • Resources via URI • State Transfer via http Methods • Headers, Caches, Status-Codes …
#WISSENTEILEN Search https://ok-shop.de/search?query= … Idee: Ein Search-Service
#WISSENTEILEN Search ok 200 [ … „list of products“ … ] Idee: Ein Search-Service
#WISSENTEILEN Search no content 204 [ ] Idee: Ein Search-Service
#WISSENTEILEN Search Super Search ? Herausforderung: Der aktuelle Search-Service soll um einen zweiten SuperSearch-Service ergänzt werden.
#WISSENTEILEN Search Super Search search?query= … supersearch?query= … Koordination der Aufrufe Aggregation der Ergebnisse Resilience im “Fall des Falles“ btw: starre Kopplung Neue Idee: zwei Search-Services
#WISSENTEILEN Simple Search Super Search simplesearch?query= … supersearch?query= … Search API search?query= … Koordination der Aufrufe Aggregation der Ergebnisse Resilience im “Fall des Falles“ btw: starre Kopplung Neue Idee: zwei Search-Services
#WISSENTEILEN Simple Search Super Search search?query= … Search API Aggregation der Ergebnisse Koordination der Aufrufe Resilience im “Fall des Falles“Search MQ Result MQ Neue Idee: zwei Search-Services
#WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ User gibt Suchbegriff ein … Neue Idee: zwei Search-Services
#WISSENTEILEN Simple Search Super Search search?query= … Search API Search MQ Result MQ Neue Idee: zwei Search-Services
#WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ „Search“ Msg Neue Idee: zwei Search-Services
#WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ Neue Idee: zwei Search-Services
#WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ „Simple Search“ Result Msg Neue Idee: zwei Search-Services
#WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ „Super Search“ Result Msg Neue Idee: zwei Search-Services
#WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ Neue Idee: zwei Search-Services
#WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ ok 200 [ … „merged list of products“ … ] Neue Idee: zwei Search-Services
#WISSENTEILEN <coding-time />
#WISSENTEILEN Versioning
#WISSENTEILEN TOLERANT READER PATTERN http://www.example.com/addresses/42 àLiefert Adresse { street: { "name": "Poststraße", "number": "1", }, "city": "26122 Oldenburg" }
#WISSENTEILEN TOLERANT READER PATTERN http://www.example.com/addresses/42 Attribut hinzufügen { street: { "name": "Poststraße", "number": "1", "additionalAdressLine": "2. Obergeschoss" }, "city": "26122 Oldenburg" }
#WISSENTEILEN http://www.example.com/addresses/42 Client erwartet { street: { "name": "Poststraße", "number": "1", }... } TOLERANT READER PATTERN Server schickt { street: { "name": "Poststraße", "number": "1", "additionalAdressLine": "2. Obergeschoss" }... }
#WISSENTEILEN TOLERANT READER PATTERN http://www.example.com/addresses/42 Attribut-Umbenennung { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1", }, "city": "26122 Oldenburg" }
#WISSENTEILEN TOLERANT READER PATTERN http://www.example.com/addresses/42 àAbwärtskompatible Änderungen: Umbenennen durch Kopieren { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1", }, "city": "26122 Oldenburg" }
#WISSENTEILEN Photo by Irene Fertik, USC News Service. Copyright 1994, USC. „Be conservative in what you do, Be liberal in what you accept from others“ RFC 793, Robustness Principal (John Postel)
#WISSENTEILEN Es darf nichts entfernt werden Keine Veränderung von Verarbeitungsregel Optionales darf nie Required werden http://zalando.github.io/restful-api-guidelines Alles was hinzugefügt wird, muss optional sein
#WISSENTEILEN http://www.example.com/addresses/42 Client erwartet { street: { "name": "Poststraße", "number": "1", }... } MAGNANIMOUS WRITER PATTERN Server schickt { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1“ }... } http://tenderware.blogspot.de/2011/05/magnanimous-writer.html
#WISSENTEILEN http://www.example.com/addresses/42 Client erwartet { street: { "streetName": "Poststraße", "houseNumber": "1", }... } MAGNANIMOUS WRITER PATTERN Server schickt { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1“ }... } http://tenderware.blogspot.de/2011/05/magnanimous-writer.html
#WISSENTEILEN PUT http://www.example.com/addresses/42 Client schickt { street: { "name": "Poststraße", "number": "1", }... } MAGNANIMOUS WRITER PATTERN Server erwartet http://tenderware.blogspot.de/2011/05/magnanimous-writer.html
#WISSENTEILEN MAGNANIMOUS WRITER PATTERN PUT http://www.example.com/addresses/42 Client schickt { street: { "name": "Poststraße", "number": "1", }... } http://tenderware.blogspot.de/2011/05/magnanimous-writer.html Server erwartet { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1“ }... } oder oder
#WISSENTEILEN MAGNANIMOUS WRITER PATTERN PUT http://www.example.com/addresses/42 Client schickt { street: { "streetName": "Poststraße", "houseNumber": "1", }... } http://tenderware.blogspot.de/2011/05/magnanimous-writer.html Server erwartet { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1“ }... } oder oder
#WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àAbwärtskompatible Änderungen: Umbenennen durch Kopieren { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1", }, "city": "26122 Oldenburg" } Geht da noch mehr?
#WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àZusammenführen und Teilen von Attributen { street: { ... "streetName": "Poststraße", "houseNumber": "1", "addressLine1": "Poststraße 1", } ... }
#WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àHerausforderungen: Zusammenführen von Attributen { street: { ... "streetName": "Poststraße", "houseNumber": "1", "addressLine1": "Poststraße 1", } ... }
#WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àHerausforderungen: Teilen von Attributen { street: { ... "addressLine1": "Poststraße 1", } "city": "26122 Oldenburg", "zipCode": "26122", "cityName": "Oldenburg" }
#WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àHerausforderungen: Ebene von Attributen ändern { street: { ... "addressLine1": "Poststraße 1" } "addressLine1": "Poststraße 1", ... }
#WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àHerausforderungen: Ebene von Attributen ändern { ... "zipCode": "26122", "cityName": "Oldenburg", "location": { "zipCode": "26122", "cityName": "Oldenburg" } }
#WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àHerausforderungen: Ebene von Attributen ändern { ... "zipCode": "26122", "cityName": "Oldenburg", "location": { "zipCode": "26122", "cityName": "Oldenburg" } } Bei jeder Modelländerung muss eine Migrationsstrategie einbezogen werden!
#WISSENTEILEN <coding-time />
#WISSENTEILEN ABWÄRTSKOMPATIBILITÄT { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1", "addressLine1": "Post... 1", "addressLine2": "" } "addressLine1": "Poststraße 1", "addressLine2": "", "city": "26122 Oldenburg", "zipCode": "26122", "cityName": "Oldenburg", "location": { "zipCode": "26122", "cityName": "Oldenburg" } } http://www.example.com/v1/addresses/42 àBisher nur abwärtskompatible Änderungen
#WISSENTEILEN ABWÄRTSKOMPATIBILITÄT { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1", "addressLine1": "Post... 1", "addressLine2": "" } "addressLine1": "Poststraße 1", "addressLine2": "", "city": "26122 Oldenburg", "zipCode": "26122", "cityName": "Oldenburg", "location": { "zipCode": "26122", "cityName": "Oldenburg" } } http://www.example.com/v1/addresses/42 àViele Attribute deprecated
#WISSENTEILEN WEITERENTWICKLUNG { "street": { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1", "addressLine1": "Post... 1", "addressLine2": "" }, "addressLine1": "Poststraße 1", "addressLine2": "", "city": "26122 Oldenburg", "zipCode": "26122", "cityName": "Oldenburg", "location": { "zipCode": "26122", "cityName": "Oldenburg" } } Schnittstelle Schnittstelle { "addressLine1": "Poststraße 1", "addressLine2": "", "location": { "zipCode": "26122", "cityName": "Oldenburg" } } V1 V2-SNAPSHOT
#WISSENTEILEN Data Consistency
#WISSENTEILEN
#WISSENTEILEN Checkout Idee: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Orders
#WISSENTEILEN Checkout Idee: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Orders Herausforderung: Wie kommen die notwendigen Daten zum Checkout-Service?
#WISSENTEILEN Checkout Idee: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Datenversorgung: Zu dem Zweck hält der Checkout-Service ein Replikat der notwendigen Daten*. Orders Preferred Delivery Address Preferred Payment Method*ggf. als eigene Domänen-Repräsentation
#WISSENTEILEN Checkout Orders Preferred Delivery Address Preferred Payment Method Idee: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Herausforderung: Aber was ist, wenn die bevorzugte Lieferadresse bzw. Zahlungsmethode nicht zur Anwendung kommen soll?
#WISSENTEILEN Checkout Orders Preferred Delivery Address Preferred Payment Method Idee: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Alternative Adresse: … im „Ausnahmefall“ wird der Address-Service zur Auswahl einer anderen Adresse heran- gezogen.
#WISSENTEILEN Checkout Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. POST https://ok-shop.de/orders Orders Preferred Delivery Address Preferred Payment Method
#WISSENTEILEN Checkout Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. 201 created Location: …/orders/1234 Orders Preferred Delivery Address Preferred Payment Method
#WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address
#WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address GET …/addresses (list all addresses)
#WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address 200 ok [ „list of addresses“ ]
#WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address PUT …/addresses/123 (change pref. delivery address)
#WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address 204 no content [ ]
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
#WISSENTEILEN Checkout Orders Preferred Delivery Address Preffered Payment Method Idee: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Herausforderung: Was ist, wenn eine neue Adresse verwendet werden soll?
#WISSENTEILEN Checkout Orders Preferred Delivery Address Preferred Payment Method Idee: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Neue Adresse anlegen: … neue Adressen werden über den Address-Service angelegt und im Anschluss repliziert.
#WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address POST …/addresses/ (add new pref. delivery address)
#WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address 201 created Location ...
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service Herausforderung: Und was ist, wenn der Address-Service nicht verfügbar ist?
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service Fachlicher Workaround : z.B. durch Setzen der Adresse nur für die aktuelle Bestellung via UI.
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address POST …/orders/ (with typed in address) Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service Fachlicher Workaround : z.B. durch Setzen der Adresse nur für die aktuelle Bestellung via UI.
#WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address 201 created Location … Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service Fachlicher Workaround : z.B. durch Setzen der Adresse nur für die aktuelle Bestellung via UI.
#WISSENTEILEN <coding-time />
#WISSENTEILEN Security
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN Product Idee: Ein Product-Service liefert zu empfehlende Produkte oder alternativ die Liste der Bestseller. Product nicht eingeloggt eingeloggt gutes Service Design: Ein Service hat genau eine fachlich Verantwortlichkeit und ein dazu passendes Domänen Modell
#WISSENTEILEN Neue Idee: Wenn nicht eingeloggt, liefert ein Bestseller-Service die Liste der Top-10. Wenn eingeloggt, liefert ein Recommendation-Service zu empfehlende Produkte. Bestseller Recomm nicht eingeloggt eingeloggt
#WISSENTEILEN Herausforderungen: Wer stellt fest, ob eingeloggt oder nicht (UI vs. Services)? Wie kommen die Login- Informationen zum Recommendation-Service? Wie werden „Session“ Info verteilt, wenn mehrere Services in einen Call involviert sind (Context Propagation)? Bestseller Recomm nicht eingeloggt eingeloggt
#WISSENTEILEN Exkurs: Sicher ist sicher! Sicher? • Server based Security via Session auf dem Server • Token based Security via Austausch von Token
#WISSENTEILEN Server based Security
#WISSENTEILEN Token based Security
#WISSENTEILEN Exkurs: 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
#WISSENTEILEN
#WISSENTEILEN Herausforderungen: Wer stellt fest, ob eingeloggt oder nicht (UI vs. Services)? Wie kommen die Login- Informationen zum Recommendation-Service? Wie werden „Session“ Info verteilt, wenn mehrere Services in einen Call involviert sind (Context Propagation)? Bestseller Recomm nicht eingeloggt eingeloggt
#WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API
#WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Eingeloggt? Nein. Recommendations?
#WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Bestseller
#WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Auth Provider login
#WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Auth Provider ok & Token
#WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Auth Provider Recommendations? Eingeloggt? Ja.
#WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Auth Provider User? Role?
#WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Auth Provider Recommendations für User
#WISSENTEILEN <coding-time />
#WISSENTEILEN Monitoring
#WISSENTEILEN
#WISSENTEILEN Search Idee: Bei einer Suche durch den Search-Service wird neben den Treffern auch deren Verfügbarkeit angezeigt. gutes Service Design: Ein Service hat genau eine fachlich Verantwortlichkeit und ein dazu passendes Domänen Modell
#WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Bei einer Suche wird neben den Treffern auch deren Verfügbarkeit angezeigt. Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit.
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Herausforderung: Performance ist deutlich schlechter als erwartet! Wo liegt das Problem? Und was ist eigentlich „passiert“?
#WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
#WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
#WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
#WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
#WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
#WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
#WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
#WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
#WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN <coding-time />
#WISSENTEILEN
#WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Herausforderung: Service liefert nicht das erwartete Ergebnis. Wo genau liegt das Problem? Und was ist eigentlich im Detail passiert?
#WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Logging: Die Logs der einzelnen Services werden in einem „Topf“ aggregiert und ausgewertet.
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN <coding-time />
#WISSENTEILEN Resilience
#WISSENTEILEN
#WISSENTEILEN Recomm Idee: Ein Recomm*-Service liefert zu empfehlende Produkte. *PPT-kompatible Version von „Recommendations-Service“
#WISSENTEILEN Recomm Idee: Ein Recomm*-Service liefert zu empfehlende Produkte. *PPT-kompatible Version von „Recommendations-Service“ Herausforderung: Aber was ist, wenn der Recomm-Service einmal ausfällt?
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN Recomm Idee: Ein Recomm-Service liefert zu empfehlende Produkte. Bestseller Resilience: Im Falles eines Ausfalls wird auf einen Bestseller-Service ausgewichen.
#WISSENTEILEN Bestseller Recomm Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback. Recomm API
#WISSENTEILEN Bestseller Personal Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Ja. Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback. Recommendations?
#WISSENTEILEN Bestseller Personal Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Ja. Recommendations für User X? Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
#WISSENTEILEN Bestseller Personal Recomm API Recommendations für User X Eingeloggt? Ja. „Personal“ verfügbar? Ja. Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
#WISSENTEILEN Bestseller Personal Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Nein. Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback. Recommendations?
#WISSENTEILEN Bestseller Personal Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Nein. Bestseller? Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
#WISSENTEILEN Bestseller Personal Recomm API Bestseller Eingeloggt? Ja. „Personal“ verfügbar? Nein. Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
#WISSENTEILEN Bestseller Recomm Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Nein. „Bestseller“verfügbar? Nein. Recommendations? Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN Bestseller Recomm Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Nein. „Bestseller“verfügbar? Nein. Recommendations? Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
#WISSENTEILEN Bestseller Recomm Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Nein. „Bestseller“verfügbar? Nein. Static Content Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
#WISSENTEILEN <coding-time />
#WISSENTEILEN Lessons Learned
#WISSENTEILEN Ein Microservice kommt selten allein!
#WISSENTEILEN Microservices-Projekte scheitern nicht an Technologie.
#WISSENTEILEN Viele Probleme lassen sich fachlich lösen.
#WISSENTEILEN Automatisierung ist Pflicht nicht Kür.
#WISSENTEILEN Arne Limburg, @arneLimburg Lars Röwekamp, @mobileLarson Kontakt: lars.roewekamp@openknowledge.de arne.limburg@openknowledge.de kontakt@openknowledge.de Besten Dank! #WISSENTEILEN

Weitere ähnliche Inhalte

PDF
Der goldene Schnitt – Wie schneide ich Microservices richtig?
vonOPEN KNOWLEDGE GmbH
 
PDF
Microservices Architecture: Architektur und Patterns
vonOPEN KNOWLEDGE GmbH
 
PDF
Microservices Migration: Vom Monolithen zu Microservices
vonOPEN KNOWLEDGE GmbH
 
PDF
Aus der Rubrik "Spaß mit Microservices": Transaktionen
vonOPEN KNOWLEDGE GmbH
 
PDF
Shared Data in verteilten Systemen
vonOPEN KNOWLEDGE GmbH
 
PDF
Spaß mit Microservices: Transaktionen
vonOPEN KNOWLEDGE GmbH
 
PDF
Das passende Backend für meine Apps
vonOPEN KNOWLEDGE GmbH
 
PDF
Die Matrix: Enterprise-Architekturen jenseits von Microservices
vonOPEN KNOWLEDGE GmbH
 
Der goldene Schnitt – Wie schneide ich Microservices richtig?
vonOPEN KNOWLEDGE GmbH
 
Microservices Architecture: Architektur und Patterns
vonOPEN KNOWLEDGE GmbH
 
Microservices Migration: Vom Monolithen zu Microservices
vonOPEN KNOWLEDGE GmbH
 
Aus der Rubrik "Spaß mit Microservices": Transaktionen
vonOPEN KNOWLEDGE GmbH
 
Shared Data in verteilten Systemen
vonOPEN KNOWLEDGE GmbH
 
Spaß mit Microservices: Transaktionen
vonOPEN KNOWLEDGE GmbH
 
Das passende Backend für meine Apps
vonOPEN KNOWLEDGE GmbH
 
Die Matrix: Enterprise-Architekturen jenseits von Microservices
vonOPEN KNOWLEDGE GmbH
 

Was ist angesagt?

PDF
Zukunftssichere Architekturen mit Microservices
vonOPEN KNOWLEDGE GmbH
 
PDF
Herausforderung „Multi-Channel Architecture”
vonOPEN KNOWLEDGE GmbH
 
PDF
Less Server vs. Serverless?
vonOPEN KNOWLEDGE GmbH
 
PDF
CQRS, der etwas andere Architekturansatz
vonOPEN KNOWLEDGE GmbH
 
PDF
Modern Lightweight Enterprise Architectures mit Java
vonOPEN KNOWLEDGE GmbH
 
PDF
Web APIs jenseits von REST & Request/Response
vonOPEN KNOWLEDGE GmbH
 
PDF
Microservices mit dem MicroProfile
vonOPEN KNOWLEDGE GmbH
 
PDF
Cloud Architekturen - von "less Server" zu Serverless
vonOPEN KNOWLEDGE GmbH
 
PDF
API Design Strategy
vonOPEN KNOWLEDGE GmbH
 
PDF
Herausforderung „Multi-Channel“-Architektur
vonOPEN KNOWLEDGE GmbH
 
PDF
Java EE goes Microservices. Are you serious?
vonOPEN KNOWLEDGE GmbH
 
PDF
Von „less Server“ bis „Serverless“: Wie viel Cloud soll es sein?
vonOPEN KNOWLEDGE GmbH
 
PDF
Business-Mehrwert durch KI
vonOPEN KNOWLEDGE GmbH
 
PDF
App-Delivery-Pipeline
vonOPEN KNOWLEDGE GmbH
 
PDF
KI und Architektur
vonOPEN KNOWLEDGE GmbH
 
PDF
Mittendrin statt nur dabei: Microservices und Transaktionen
vonOPEN KNOWLEDGE GmbH
 
PDF
App war gestern: Mobile Engagement als Teil der Enterprise-Strategie
vonOPEN KNOWLEDGE GmbH
 
PDF
The Day after – nach dem Release ist vor dem Release
vonOPEN KNOWLEDGE GmbH
 
PDF
Mobile Ideation – der sanfte Weg zum mobilen Mehrwert
vonOPEN KNOWLEDGE GmbH
 
Zukunftssichere Architekturen mit Microservices
vonOPEN KNOWLEDGE GmbH
 
Herausforderung „Multi-Channel Architecture”
vonOPEN KNOWLEDGE GmbH
 
Less Server vs. Serverless?
vonOPEN KNOWLEDGE GmbH
 
CQRS, der etwas andere Architekturansatz
vonOPEN KNOWLEDGE GmbH
 
Modern Lightweight Enterprise Architectures mit Java
vonOPEN KNOWLEDGE GmbH
 
Web APIs jenseits von REST & Request/Response
vonOPEN KNOWLEDGE GmbH
 
Microservices mit dem MicroProfile
vonOPEN KNOWLEDGE GmbH
 
Cloud Architekturen - von "less Server" zu Serverless
vonOPEN KNOWLEDGE GmbH
 
API Design Strategy
vonOPEN KNOWLEDGE GmbH
 
Herausforderung „Multi-Channel“-Architektur
vonOPEN KNOWLEDGE GmbH
 
Java EE goes Microservices. Are you serious?
vonOPEN KNOWLEDGE GmbH
 
Von „less Server“ bis „Serverless“: Wie viel Cloud soll es sein?
vonOPEN KNOWLEDGE GmbH
 
Business-Mehrwert durch KI
vonOPEN KNOWLEDGE GmbH
 
App-Delivery-Pipeline
vonOPEN KNOWLEDGE GmbH
 
KI und Architektur
vonOPEN KNOWLEDGE GmbH
 
Mittendrin statt nur dabei: Microservices und Transaktionen
vonOPEN KNOWLEDGE GmbH
 
App war gestern: Mobile Engagement als Teil der Enterprise-Strategie
vonOPEN KNOWLEDGE GmbH
 
The Day after – nach dem Release ist vor dem Release
vonOPEN KNOWLEDGE GmbH
 
Mobile Ideation – der sanfte Weg zum mobilen Mehrwert
vonOPEN KNOWLEDGE GmbH
 

Ähnlich wie Hands-On Microservices mit Java

PDF
Microservices - Do one thing well
vonmyposter GmbH
 
PDF
Shared Data in verteilten Architekturen
vonOPEN KNOWLEDGE GmbH
 
PDF
API-Versionierung im Projektalltag
vonOPEN KNOWLEDGE GmbH
 
PDF
API-Design, Microarchitecture und Testing
vonOPEN KNOWLEDGE GmbH
 
PDF
Service-orientierte Architekturen
vonpscheir
 
PDF
Microservices und das Entity Control Boundary Pattern
vonBrockhaus Consulting GmbH
 
PDF
DWX Developer Week 2015 - Microservice architecture applied
vonRamon Anger
 
PPT
Anbindung von Silverlight an RESTful Web Services
vonAndré Wussow
 
PDF
Web-API-Design in Java
vonOPEN KNOWLEDGE GmbH
 
PDF
Web-API Design in Java
vonOPEN KNOWLEDGE GmbH
 
PDF
Der perfekte Microservice
vonOPEN KNOWLEDGE GmbH
 
PPTX
Vorlesung SOA - DIS AG.pptx
vonCommunity ITmitte.de
 
PDF
API Expand Contract
vonOPEN KNOWLEDGE GmbH
 
Microservices - Do one thing well
vonmyposter GmbH
 
Shared Data in verteilten Architekturen
vonOPEN KNOWLEDGE GmbH
 
API-Versionierung im Projektalltag
vonOPEN KNOWLEDGE GmbH
 
API-Design, Microarchitecture und Testing
vonOPEN KNOWLEDGE GmbH
 
Service-orientierte Architekturen
vonpscheir
 
Microservices und das Entity Control Boundary Pattern
vonBrockhaus Consulting GmbH
 
DWX Developer Week 2015 - Microservice architecture applied
vonRamon Anger
 
Anbindung von Silverlight an RESTful Web Services
vonAndré Wussow
 
Web-API-Design in Java
vonOPEN KNOWLEDGE GmbH
 
Web-API Design in Java
vonOPEN KNOWLEDGE GmbH
 
Der perfekte Microservice
vonOPEN KNOWLEDGE GmbH
 
Vorlesung SOA - DIS AG.pptx
vonCommunity ITmitte.de
 
API Expand Contract
vonOPEN KNOWLEDGE GmbH
 

Mehr von OPEN KNOWLEDGE GmbH

PPTX
Warum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AI
vonOPEN KNOWLEDGE GmbH
 
PDF
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...
vonOPEN KNOWLEDGE GmbH
 
PDF
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
vonOPEN KNOWLEDGE GmbH
 
PDF
Der Spagat zwischen BIAS und FAIRNESS (2024)
vonOPEN KNOWLEDGE GmbH
 
PDF
FEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data Imputation
vonOPEN KNOWLEDGE GmbH
 
PPTX
Nie wieder Log-Files!
vonOPEN KNOWLEDGE GmbH
 
PDF
Cloud-native and Enterprise Java? Hold my beer!
vonOPEN KNOWLEDGE GmbH
 
PPTX
From Zero to still Zero: The most beautiful mistakes going into the cloud.
vonOPEN KNOWLEDGE GmbH
 
PDF
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & Co
vonOPEN KNOWLEDGE GmbH
 
PDF
Machine Learning mit TensorFlow.js
vonOPEN KNOWLEDGE GmbH
 
PDF
It's not Rocket Science: Neuronale Netze
vonOPEN KNOWLEDGE GmbH
 
PDF
Mehr Sicherheit durch Automatisierung
vonOPEN KNOWLEDGE GmbH
 
PDF
Supersonic Java für die Cloud: Quarkus
vonOPEN KNOWLEDGE GmbH
 
PDF
Hilfe, ich will meinen Monolithen zurück!
vonOPEN KNOWLEDGE GmbH
 
PDF
Das ist doch alles nur Frontend - Wer braucht da schon Architektur?
vonOPEN KNOWLEDGE GmbH
 
PDF
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
vonOPEN KNOWLEDGE GmbH
 
PDF
Das Product Goal oder "Ohne Ziele laufen eben alle in die Richtung, die ihnen...
vonOPEN KNOWLEDGE GmbH
 
PDF
Serverless Survival Guide
vonOPEN KNOWLEDGE GmbH
 
PDF
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
vonOPEN KNOWLEDGE GmbH
 
PDF
Maschinen ohne Gewissen: wenn KI auf Ethik trifft
vonOPEN KNOWLEDGE GmbH
 
Warum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AI
vonOPEN KNOWLEDGE GmbH
 
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...
vonOPEN KNOWLEDGE GmbH
 
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
vonOPEN KNOWLEDGE GmbH
 
Der Spagat zwischen BIAS und FAIRNESS (2024)
vonOPEN KNOWLEDGE GmbH
 
FEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data Imputation
vonOPEN KNOWLEDGE GmbH
 
Nie wieder Log-Files!
vonOPEN KNOWLEDGE GmbH
 
Cloud-native and Enterprise Java? Hold my beer!
vonOPEN KNOWLEDGE GmbH
 
From Zero to still Zero: The most beautiful mistakes going into the cloud.
vonOPEN KNOWLEDGE GmbH
 
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & Co
vonOPEN KNOWLEDGE GmbH
 
Machine Learning mit TensorFlow.js
vonOPEN KNOWLEDGE GmbH
 
It's not Rocket Science: Neuronale Netze
vonOPEN KNOWLEDGE GmbH
 
Mehr Sicherheit durch Automatisierung
vonOPEN KNOWLEDGE GmbH
 
Supersonic Java für die Cloud: Quarkus
vonOPEN KNOWLEDGE GmbH
 
Hilfe, ich will meinen Monolithen zurück!
vonOPEN KNOWLEDGE GmbH
 
Das ist doch alles nur Frontend - Wer braucht da schon Architektur?
vonOPEN KNOWLEDGE GmbH
 
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
vonOPEN KNOWLEDGE GmbH
 
Das Product Goal oder "Ohne Ziele laufen eben alle in die Richtung, die ihnen...
vonOPEN KNOWLEDGE GmbH
 
Serverless Survival Guide
vonOPEN KNOWLEDGE GmbH
 
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
vonOPEN KNOWLEDGE GmbH
 
Maschinen ohne Gewissen: wenn KI auf Ethik trifft
vonOPEN KNOWLEDGE GmbH
 

Hands-On Microservices mit Java