Microservices & Makro-Architektur (OOP 2020)

Folien zum Vortrag auf der OOP-Konferenz
München, 5. Februar 2020

Abstract

Microservices & Makro-Architektur
Drei zentrale Entwurfsfragen

Zeitgemäße Architekturstile wie Microservices oder Self Contained Systems lassen Teams, die einzelne Teile entwickeln, viel Freiheit beim Treffen von Technologieentscheidungen.

Drei Fragestellungen entpuppen sich jedoch regelmäßig als Kandidaten, um in der Makro-Architektur (also übergreifend) adressiert zu werden, zumindest zu einem gewissen Grad. Sonst wirkt die Anwendung nicht aus einem Guss oder verfehlt andere Architekturziele (z.B. flexibel reagieren zu können auf Veränderungen).

In diesem Vortrag stelle ich die drei Themen entlang eines durchgängigen Beispiels vor. Ich zeige gängige Lösungsoptionen und Einflussfaktoren, die Ihnen eine informierte Auswahl für Ihre Vorhaben ermöglichen. Wechselseitige Beeinflussungen, Kompromisse und Real World-Entscheidungen eingeschlossen.

Weitere Infos
https://www.embarc.de/microservices-makro-architektur-oop-2020/

Transcript

1. Drei zentrale Entwurfsfragen bei vertikalen Anwendungsarchitekturen STEFAN ZÖRNER // EMBARC OOP-Konferenz, München Mittwoch, 05.02.2020 Microservices & Makro-Architektur
2. 2 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Stefan Zörner n Softwareentwickler + -architekt bei embarc in Hamburg n Vorher oose, IBM, Mummert + Partner, Bayer AG, … Schwerpunkte: n Softwarearchitektur (Entwurf, Bewertung, Dokumentation) n Java Technologien Stefan.Zoerner@embarc.de @StefanZoerner è xing.to/szr
3. 3 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Microservices & Makro-Architektur Drei zentrale Entwurfsfragen Zusammenfassung: Zeitgemäße Architekturstile wie Microservices oder Self Contained Systems lassen Teams, die einzelne Teile entwickeln, viel Freiheit beim Treffen von Technologieentscheidungen. Drei Fragestellungen entpuppen sich jedoch regelmäßig als Kandidaten, um in der Makro-Architektur (also übergreifend) adressiert zu werden, zumindest zu einem gewissen Grad. Sonst wirkt die Anwendung nicht aus einem Guss oder verfehlt andere Architekturziele (z.B. flexibel reagieren zu können auf Veränderungen). In diesem Vortrag stelle ich die drei Themen entlang eines durchgängigen Beispiels vor. Ich zeige gängige Lösungsoptionen und Einflussfaktoren, die Ihnen eine informierte Auswahl für Ihre Vorhaben ermöglichen. Wechselseitige Beeinflussungen, Kompromisse und Real World-Entscheidungen eingeschlossen.
4. 4 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Agenda 1 Heilsversprechen reloaded 2 Themen für die Makro-Architektur? 3 Thema I 4 Thema II 5 Thema III 6 Weitere Informationen und Fazit
5. 5 S. Zörner: “Microservices & Makro-Architektur“ embarc.de 1 Agenda 1 Heilsversprechen reloaded 2 Themen für die Makro-Architektur? 3 Thema I 4 Thema II 5 Thema III 6 Weitere Informationen und Fazit
6. 6 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Trends im Zeitstrahl 1990 1995 2000 2005 2010 2015 OO (Objektorientierung) SOA (Service-oriented Architecture) MDA (Model Driven Architecture) Cloud Computing Microservices Große Trends der IT. (unvollständige Auswahl) 2-Speed /Bimodal 2020 AI / Machine Learning Agile Software- Entwicklung CASE Tools
7. 7 S. Zörner: “Microservices & Makro-Architektur“ embarc.de 1. Zwei Heilsversprechen Diese Trends versprechen zwei Formen des Glücks ... 2. Kosten sparen in Entwicklung und Betrieb, z.B. durch ... effizientere Werkzeuge und Methoden Wiederverwendung Einsparungen in Personal, Lizenzen, ... Kosteneffizien z Flexibilität Schnell auf Veränderungen reagieren können, z.B. auf ... neue fachliche Anforderungen technologische Trends Schwankungen in der Last
8. 8 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Microservices in kurz … “In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms…” (James Lewis, Martin Fowler, 2014) ➔ https://martinfowler.com/articles/microservices.html Charakteristische Eigenschaften Zerlegung in relativ kleine (fachliche) Services Services sehr lose gekoppelt Services einzeln installierbar und upgradebar Dezentrale Datenhaltung Hoher Freiheitsgrad bei Technologieauswahl
9. 9 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Das Versprechen einhalten ... Wie versuchen Microservices leicht auf Änderungen zu reagieren? Neue fachliche Anforderungen schnell umsetzen Kleinteiligkeit („Micro“), als Gegenmodell zum Monolith Lose Kopplung der Services, leichte Austauschbarkeit Technologische Trends schnell aufgreifen Hoher Freiheitsgrad bei Technologieauswahl Services mit unterschiedlichem Technologie-Stack möglich Schwankungen in der Last auffangen Einzelne Services einzeln skalierbar Services schnell start- und wegwerfbar
10. 10 S. Zörner: “Microservices & Makro-Architektur“ embarc.de *Eine* Anwendung So sollte es sich für den Benutzer auch anfühlen. Ein Spannungsfeld Technologische Vielfalt in den “Vertikalen” Paradigmen Programmiersprachen Bibliotheken und Frameworks ... z.B. in der Persistenz (polyglott)
11. 11 S. Zörner: “Microservices & Makro-Architektur“ embarc.de FLEXess – Ein Beispiel
12. 12 S. Zörner: “Microservices & Makro-Architektur“ embarc.de FLEXess – Ein Beispiel Erste Context Map für die Domäne einer Online-Schachplattform.
13. 13 S. Zörner: “Microservices & Makro-Architektur“ embarc.de FLEXess – Ein Beispiel Daraus Kandidaten ableiten für Vertikalen (Services) ... Spieler Laufende Partien Spielregeln Diagramme Computer-Gegner
14. 14 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Agenda 1 Heilsversprechen reloaded 2 Themen für die Makro-Architektur? 3 Thema I 4 Thema II 5 Thema III 6 Weitere Informationen und Fazit 2
15. 15 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Zu allererst: Den Kontext festlegen n Ganzes «system» UnsereAnwendung
16. 16 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Einsatzgebiete Makro vs. Mikro Worüber reden wir? Eine Anwendung, die in Module, Services, Komponenten ... zerfällt? (Self-contained Systems, Microservices …) Eine Produktfamilie oder -linie, die in Varianten oder Ausprägungen zerfällt? Eine Systemlandschaft, die in Anwendungen zerfällt? ... n Ganzes n Bestandteile Farb-Code:
17. 17 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Makro- vs. Mikroarchitektur Entscheidungen ... Welche Aspekte sind für alle Bestandteile gleich? (Makro, Standardisierung) Wo ist Spielraum? (Mikro, Individualisierung)
18. 18 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Vorteile von Standardisierung Entwickler wechseln leicht zwischen Teams und Projekten Konzentration auf Applikationsspezifika (z.B. Fachlichkeit) leichter möglich Wiederverwendung von technischen Lösungen Vermeidung von Fehlern in kritischen Bereichen durch erprobte Konzepte
19. 19 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Vorteile von Individualisierung Einsatz optimaler Lösungen für spezifische Probleme möglich Neue Trends lassen sich schneller aufgreifen Fehlentscheidungen haben geringere Relevanz Geringere Abhängigkeit von einzelnen Lieferanten ...
20. 20 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Übergreifende Themen (Kandidaten) Benutzer und Fremdsysteme 1 "Unter der Haube“ 2 Entwicklung und Weiterentwicklung 3 Zielumgebung und Betrieb 4
21. 21 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Themenkomplex: Benutzer und Fremdsysteme
22. 22 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Themenkomplex: „Unter der Haube“
23. 23 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Themenkomplex: Entwicklung + Weiterentwicklung
24. 24 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Themenkomplex: Zielumgebung und Betrieb
25. 25 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Und jetzt?
26. 26 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Und jetzt? Entscheidungen ... Zu bestimmten Themen gibt es Best Practices, Industrie-Standards, … Zu einigen Themen gibt es meiner Erfahrung nach regelmäßig Diskussionen „ob und wenn ja wie man das zentral macht ...“ Drei dieser Themen habe ich jetzt mal rausgepickt, um genau das zu diskutieren ...
27. 27 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Agenda 1 Heilsversprechen reloaded 2 Themen für die Makro-Architektur? 3 Thema I: Die UI-Frage 4 Thema II 5 Thema III 6 Weitere Informationen und Fazit 3
28. 28 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Die UI-Frage Frage: Wie realisieren wir mit mehreren Teilen *ein* UI? Anforderung: Trotz mehrerer Teile präsentiert sich die Anwendung dem Benutzer “aus einem Guss“.
29. 29 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Antworten: (Extreme) Option A Microservices (allgemeiner: Vertikalen) haben keinen UI-Anteil, sondern nur eine (z.B. REST)-Schnittstelle. Ein gemeinsamer Client greift auf alle Services zu. Client Microservices Integration im Client, z.B. SPA mit Angular
30. 30 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Beispiel: Netflix Quelle: Stefan Toth, Stefan Zörner “Gut das ist? Umgekehrte Architekturbewertung eines Internetgiganten”
31. 31 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Antworten: (Extreme) Option B Vertikalen (z.B. Microservices) bringen jeweils die komplette UI für „ihr Thema“ mit. Die Integration erfolgt z.B. über Links im Browser. Microservices Eine Vertikale ist für die gesamte Seite im Browser verantwortlich.
32. 32 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Beispiel: Xing
33. 33 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Besondere Stärken der Ansätze Gemeinsames UI für UI-lose Vertikalen Inhalte und Funktionen aus verschiedenen Themen lassen sich nahtlos integrieren – keine Brüche Einheitliches User Interface ist leicht erreichbar Spezialisiertes Team für eine optimale UX denkbar Separate UIs für die Vertikalen Teams vollumfänglich für Thema verantwortlich (Cross-funktionale Teams) Technologische Freiheiten im UI-Bereich Unabhängiges Arbeiten der Teams leichter möglich
34. 34 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Kompromisse ... Funktionale Eignung (Functional Suitability) Sind die berechneten Ergebnisse genau genug / exakt, ist die Funktionalität angemessen? ... Effizienz (Performance) Antwortet die Software schnell, hat sie einen hohen Durchsatz, einen geringen Ressourcenverbrauch? ... Kompatibilität (Compatibility) Ist die Software konform zu Standards, arbeitet sie gut mit anderen zusammen? Benutzbarkeit (Usability) Ist die Software intuitiv zu bedienen, leicht zu erlernen, attraktiv? Zuverlässigkeit (Reliability) Ist das System verfügbar, tolerant gegenüber Fehlern, nach Abstürzen schnell wieder hergestellt? ... Sicherheit (Security) Ist das System sicher vor Angriffen? Sind Daten und Funktion vor unberechtigtem Zugriff geschützt? ... Wartbarkeit (Maintainability) Ist die Software leicht zu ändern, erweitern, testen, verstehen? Lassen sich Teile wiederverwenden? ... Portabilität (Portability) Ist die Software leicht auf andere Zielumgebungen (z.B. anderes OS) übertragbar? Begriffe nach ISO 25010
35. 35 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Eine Frage der Balance Benutzbarkeit (Usability) Ist die Software intuitiv zu bedienen, leicht zu erlernen, attraktiv? Wartbarkeit (Maintainability) Ist die Software leicht zu ändern, erweitern, testen, verstehen? Lassen sich Teile wiederverwenden? ... Mit dem Beantworten der UI-Frage balancieren Sie vor allem Benutzbarkeit und Wartbarkeit aus. Die beiden Antworten entsprechen Extrem-Ausschlägen.
36. 36 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Realisierung in “FLEXess”
37. 37 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Architektur-Spicker zu Frontend-Architektur PDF, 4 Seiten. Kostenloser Download. è https://www.architektur-spicker.de Spicker Nr. 9: „Moderne Frontend-Architektur“ In dieser Ausgabe: Typische Anforderungen für SPAs Große Anwendungen in Teile schneiden SPA-Framework-Auswahl Strickmuster für Anwendungsteile ç Unsere Architektur-Spicker beleuchten die konzeptionelle Seite der Softwareentwicklung.
38. 38 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Agenda 1 Heilsversprechen reloaded 2 Themen für die Makro-Architektur? 3 Thema I: Die UI-Frage 4 Thema II: Kommunikation 5 Thema III 6 Weitere Informationen und Fazit 4
39. 39 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Die Kommunikationsfrage Frage: Dürfen Services miteinander reden, und wenn ja wie? (Und wenn nein – wie realisieren wir dann obige Anforderung?) Anforderung: Ein Service benötigt Funktionalität und/oder Daten eines anderen Services, um seine Aufgabe zu erledigen.
40. 40 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Beispiel in FLEXess Nutzung der Spielregeln aus den laufenden Partien, um eingehende Züge zu prüfen. Spieler Laufende Partien Spielregeln Diagramme Computer-Gegner
41. 41 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Beispiel in FLEXess Nutzung der Spielregeln aus den laufenden Partien, um eingehende Züge zu prüfen. Laufende Partien Spielregeln Diagramme Computer-Gegner eingehender Zug, z.B. über REST API “d1e8” ? Spieler
42. 42 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Beispiel in FLEXess
43. 43 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Die Frage im Detail (1) Direkt Der Client „kennt“ den Service und spricht ihn direkt an. direkt vs. indirekt Indirekt Der Client kommuniziert über eine Middleware, die ihn vom Service entkoppelt. Client und Server „kennen“ sich nicht.
44. 44 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Die Frage im Detail (2) Synchron Der Client wartet auf die Antwort des Service und blockiert. synchron vs. asynchron Asynchron Der Client wartet nicht auf die Antwort. Er erhält diese falls nötig später, ggf. über einen anderen Kanal.
45. 45 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Eine Option: direkt + synchron Top-Herausforderung aus „direkt“ Der Client muss den (ggf. redundanten) Service auffinden. (Typische Lösung: Service Registry) Top-Herausforderung aus „synchron“ Wenn der Service nicht verfügbar ist oder fehlerhaft bzw. langsam antwortet, zieht das weitere Systemteile runter. (Typische Lösung: Circuit Breaker, Bulk Heads ...)
46. 46 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Microservices Patterns è https://microservices.io/patterns/ Chris Richardson “Microservice Patterns” Manning, Oktober 2018
47. 47 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Implementierung FLEXess
48. 48 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Weitere Kommunikationsaspekte Spieler Laufende Partien Spielregeln Diagramme Computer-Gegner z.B. Anbindung von Computer-Gegners als Integrationsaufgabe.
49. 49 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Agenda 1 Heilsversprechen reloaded 2 Themen für die Makro-Architektur? 3 Thema I: Die UI-Frage 4 Thema II: Kommunikation 5 Thema III: Security 6 Weitere Informationen und Fazit 5
50. 50 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Die Security-Frage Frage: Welche Themen rund um Security adressieren wir in der Makro-Architektur? (und wie?) Anforderung: „Security sollte niemals ein nachträglicher Einfall bei Deiner Anwendungsentwicklung sein.“ (aus „Beyond the Twelve Factor App“)
51. 51 S. Zörner: “Microservices & Makro-Architektur“ embarc.de “Beyond the Twelve-Factor App” Kevin Hoffman Beyond the Twelve-Factor App Exploring the DNA of Highly Scalable, Resilient Cloud Applications O’Reilly Media 2016 ISBN 978-1-491-94401-1 72 Seiten (PDF)
52. 52 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Security unter der Lupe Anwender authentifizieren und autorisieren, ggf. Verschlüsselung 1. Andere Clients über eine API, analog zu Anwendern, aber ggf. anderes Thema 2. Wenn Services einander nutzen – auch hier: Authentifizierung, Autorisierung, ggf. Verschlüsselung 3. Services nutzen Persistenz- oder andere Backend-Services, Credentials? 4.
53. 53 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Eine häufige Antwort für (1) Authentifizierung zentral (Makro-Architektur) Gemeinsamer Service, Single Sign-on Einzelne Services erhalten Token z.B. via JWT (JSON Web Token) Die Anwender der Services authentifizieren und autorisieren ... Autorisierung obliegt den einzelnen Services Service erhält Identität des Aufrufers und ggf. weitere Eigenschaften (z.B. globale Rollen) Die Überprüfung der Berechtigung verantwortet der Service
54. 54 S. Zörner: “Microservices & Makro-Architektur“ embarc.de FLEXess – Ein Beispiel Der „Laufende Partien“-Service entscheidet, ob ein Spieler einen Zug machen darf. Spieler Laufende Partien Spielregeln Diagramme Computer-Gegner
55. 55 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Service Mesh. Ein Lösungsansatz? “Grundsätzlich kann ein Service Mesh Features in vier Bereichen bieten: Monitoring, Routing, Resilienz, Sicherheit ...” ➔ informatik-aktuell.de/entwicklung/methoden/service-mesh-fuer-microservices-unverzichtbar.html
56. 56 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Agenda 1 Heilsversprechen reloaded 2 Themen für die Makro-Architektur? 3 Thema I: Die UI-Frage 4 Thema II: Kommunikation 5 Thema III: Security 6 Weitere Informationen und Fazit 6
57. 57 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Self-contained Systems (SCS) “The Self-contained System (SCS) approach is an architecture that focuses on a separation of the functionality into many independent systems, making the complete logical system a collaboration of many smaller software systems. This avoids the problem of large monoliths that grow constantly and eventually become unmaintainable.” è http://scs-architecture.org
58. 58 S. Zörner: “Microservices & Makro-Architektur“ embarc.de SCS – Charakteristika Der Architekturstil Self-contained Systems ist klarer definiert als Microservices bei Fowler et. al n Jedes SCS ist eine autonome Web-Applikation. n Für jedes SCS ist ein Team verantwortlich n Wo immer möglich erfolgt die Kommunikation zwischen verschiedenen SCS asynchron. n Ein SCS kann eine Service API besitzen (zusätzlich zum UI) n Jedes SCS beinhaltet Datenhaltung und Geschäftslogik n Ein SCS stellt seine Funktionalität über sein eigenes UI bereit. n Eine SCS teilt keine Geschäftslogik mit einer anderen SCS. n Geteilte Infrastruktur sollte wo immer möglich vermieden werden. ➔ http://scs-architecture.org
59. 59 S. Zörner: “Microservices & Makro-Architektur“ embarc.de SCS – Charakteristika Der Architekturstil Self-contained Systems ist klarer definiert als Microservices bei Fowler et. al n Jedes SCS ist eine autonome Web-Applikation. n Für jedes SCS ist ein Team verantwortlich n Wo immer möglich erfolgt die Kommunikation zwischen verschiedenen SCS asynchron. n Ein SCS kann eine Service API besitzen (zusätzlich zum UI) n Jedes SCS beinhaltet Datenhaltung und Geschäftslogik n Ein SCS stellt seine Funktionalität über sein eigenes UI bereit. n Eine SCS teilt keine Geschäftslogik mit einer anderen SCS. n Geteilte Infrastruktur sollte wo immer möglich vermieden werden. ➔ http://scs-architecture.org
60. 60 S. Zörner: “Microservices & Makro-Architektur“ embarc.de SCS – Charakteristika Der Architekturstil Self-contained Systems ist klarer definiert als Microservices bei Fowler et. al n Jedes SCS ist eine autonome Web-Applikation. n Für jedes SCS ist ein Team verantwortlich n Wo immer möglich erfolgt die Kommunikation zwischen verschiedenen SCS asynchron. n Ein SCS kann eine Service API besitzen (zusätzlich zum UI) n Jedes SCS beinhaltet Datenhaltung und Geschäftslogik n Ein SCS stellt seine Funktionalität über sein eigenes UI bereit. n Eine SCS teilt keine Geschäftslogik mit einer anderen SCS. n Geteilte Infrastruktur sollte wo immer möglich vermieden werden. ➔ http://scs-architecture.org
61. 61 S. Zörner: “Microservices & Makro-Architektur“ embarc.de SCS – Charakteristika Der Architekturstil Self-contained Systems ist klarer definiert als Microservices bei Fowler et. al n Jedes SCS ist eine autonome Web-Applikation. n Für jedes SCS ist ein Team verantwortlich n Wo immer möglich erfolgt die Kommunikation zwischen verschiedenen SCS asynchron. n Ein SCS kann eine Service API besitzen (zusätzlich zum UI) n Jedes SCS beinhaltet Datenhaltung und Geschäftslogik n Ein SCS stellt seine Funktionalität über sein eigenes UI bereit. n Eine SCS teilt keine Geschäftslogik mit einer anderen SCS. n Geteilte Infrastruktur sollte wo immer möglich vermieden werden. ➔ http://scs-architecture.org
62. 62 S. Zörner: “Microservices & Makro-Architektur“ embarc.de ISA Principles è http://isa-principles.org ISA (Independent Systems Architecture) is a collection of best practices based on experience in particular with microservices and Self-contained Systems and the challenges faced in those projects. ...
63. 63 S. Zörner: “Microservices & Makro-Architektur“ embarc.de ISA Principle 3 (/9) “ … 3. The system must have two clearly separated levels of architectural decisions: The Macro Architecture comprises decisions that cover all modules. All further principles are part of the Macro Architecture. The Micro Architecture considers decisions which may be taken individually for each module. …” ➔ http://isa-principles.org
64. 64 S. Zörner: “Microservices & Makro-Architektur“ embarc.de tl;dr (too long; didn’t read) UI-, Kommunikations-, und Security-Themen sind häufige Brennpunkte für eine frühe initiale Bearbeitung in der Makro- Architektur. Ein gutes Verständnis von Makro- und Mikroarchitektur ist zentral für den Einsatz moderner Architekturstile wie Microservices und Self-contained Systems. Entscheidungen dort bergen oftmals Kompromisse, die entlang der Qualitätsziele ausbalanciert gehören. Dazu muss man diese kennen.
65. 65 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Blog-Serie: Micro Moves è embarc.de/micro-moves/ Zeitgenössische Softwarearchitektur als Bausatz.
66. 66 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Makro-Architektur auf einem Bierdeckel?
67. 67 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Architekturüberblick auf einer DVD-Hülle
68. 68 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Zum Mitnehmen bei uns am Stand. wir sind ca. hier
69. 69 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Spicken erlaubt! Unsere Architektur-Spicker beleuchten die konzeptionelle Seite der Softwareentwicklung. è embarc.de/architektur-spicker/
70. 70 S. Zörner: “Microservices & Makro-Architektur“ embarc.de Spicker #3: „Microservices“ In dieser Ausgabe: Was ist bei Microservices entscheidend? Wie nutzen Sie die Ansätze? Welche Kompromisse gehen Sie dabei ein? PDF, 4 Seiten Kostenloser Download. ç è embarc.de/architektur-spicker/
71. Vielen Dank. Ich freue mich auf Eure Fragen! DOWNLOAD FOLIEN: https://www.embarc.de/blog/ sz@embarc.de @StefanZoerner è xing.to/szr