Flexible Architekturen - Mit der Zeit gehen ... FALK SIPPACH - embarc
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Mit der Zeit gehen ...
Flexible Architekturen
FALK SIPPACH
Mainz, 09.09.2020
0
Falk Sippach
n Softwarearchitekt, Berater, Trainer bei embarc
n früher bei Orientation in Objects (OIO), Trivadis
fs@embarc.de
@sippsack
è xing.to/fsi
Flexible Architekturen embarc.de 2
Flexible Architekturen embarc.de 3
Mit der Zeit gehen - Flexible Architekturen In der agilen Softwareentwicklung gibt es die Rolle des Architekten eigentlich nicht mehr. Paradoxerweise sind die Herausforderungen an den Entwurf moderner Softwaresysteme höher als früher. Um die Digitalisierung voranzutreiben, sich von den Mitbewerbern abzuheben, sich möglichst auch einen Wettbewerbsvorteil zu erarbeiten und die sowohl technische als auch organisatorische Skalierbarkeit sicherzustellen, sind zu den altbekannten ganz neue Fragestellungen hinzugekommen: • Laufzeitmonolith oder irgendetwas Entkoppeltes? • DevOps oder klassischer Betrieb? • Serverless/Cloud oder On Premises? • Relationale Datenhaltung oder NoSQL bzw. sogar In-Memory? • Lang- oder Kurzlebigkeit? Je nach eingesetzten Architekturstilen und -mustern kommen heutzutage ganz neue Herausforderungen auf euch zu. Wir diskutieren in diesem Vortrag, wie agile Teams eine flexible und vor allem auch robuste Softwarearchitektur entwerfen, sie festhalten, kommunizieren und pflegen können. Und das auch, wenn von der grünen Wiese nach ein paar Monaten nicht mehr viel zu sehen ist. Flexible Architekturen embarc.de 4
Flexible Architekturen
Softwarearchitektur
embarc.de 5
Flexible Architekturen? Flexible Architekturen embarc.de 6
Expertenmeinungen
“… not all design is architecture. Architecture represents
the significant design decisions that shape a system,
where significant is measured by cost of change.”
(Grady Booch)
“Softwarearchitecture is about the important stuff,
whatever that is.”
(Ralph Johnson)
“Software architecture is the set of design decisions
which, if made incorrectly, may cause your project to be
cancelled.”
(Eoin Woods)
Flexible Architekturen embarc.de 7
Was ist Architektur für mich?
fundamentale Strukturen,
Konzepte,
Entscheidungen
und Lösungsansätze
... die man nicht mehr leicht los bekommt!
Flexible Architekturen embarc.de 8
Wer oder was ist ein Software-Architekt?
Architect is Latin for "Can’t code anymore".
(Ted Neward)
Das Leben von Software-Architekten besteht aus einer
langen und schnellen Abfolge suboptimaler
Entwurfsentscheidungen, die meist im Dunkel
getroffen werden.
(Philippe Kruchten)
Flexible Architekturen embarc.de
10
10Anforderungen
klären
Architektur Architektur
bewerten entwerfen
Architektur
kommunizieren
aus: Effektive Software-
architekturen (G. Starke)
Flexible Architekturen embarc.de 11 11Agenda
1 Anforderungen klären
2 Flexible Lösungsansätze
3 Dokumentation
4 Ausblick
Flexible Architekturen embarc.de 12Agenda
1 Anforderungen klären
2 Flexible Lösungsansätze
3 Dokumentation
1
4 Ausblick
Flexible Architekturen embarc.de 13Einflüsse auf Entscheidungen
Vorgaben/Rahmenbedingungen
Technisch (z.B. Datenbankprodukt)
Organisatorisch (z.B. Team)
- schränken die Lösung ein
- schließen Optionen aus
- prägen die Lösung
- nachher schwierig “einzubauen”
Qualitätsanforderungen
Benutzbarkeit, Effizienz,
Wartbarkeit, Sicherheit ...
Flexible Architekturen embarc.de 14Rahmenbedingungen … … wirken eher einschränkend auf die Optionen beim Entwurf einer Software und können im Gegensatz zu Qualitätsanforderungen oft nicht mit dem Kunden diskutiert werden. Außerdem werden solche Randbedingungen oft auf binäre Art und Weise erfüllt oder nicht, ohne dass es dazwischen Abstufungen gäbe. Flexible Architekturen embarc.de 15
Arten von Rahmenbedingungen
Technologisch
Hardware-Vorgaben
Software-Vorgaben
Vorgaben des Systembetriebs
Programmiervorgaben
Organisatorisch
Organisation und Struktur
Ressourcen (Zeit, Budget, Personal)
Organisatorische Standards
Juristische Faktoren
Flexible Architekturen embarc.de 16Qualitätsziele
Die wichtigsten geforderten Qualitätsmerkmale für ein
Softwaresystem (Synonym: Architekturziele).
Typischerweise werden als Qualitätsziele im Rahmen
eines Architekturüberblicks die Top-3 bis Top-5 genannt.
Flexible Architekturen embarc.de 17Beispiel: Qualitätsziele Netflix
(aka „Architekturziele“ oder „Architekturtreiber“)
Ziel Beschreibung
Die Lösung steht auch bei Lastspitzen
Verfügbarkeit
uneingeschränkt zur Verfügung.
Auf allen wichtigen Geräten eine optimale User
Benutzbarkeit
Experience.
Es ist leicht, neue Funktionalität zu bauen und
Modifizierbarkeit
hinzuzufügen.
Attraktivität Wir sind als Arbeitgeber für gute Entwickler attraktiv.
Wir haben gute Einblicke, was in unserer Umgebung
Betreibbarkeit
läuft.
Quelle: Stefan Toth, Stefan Zörner
“Gut das ist? Umgekehrte Architekturbewertung eines Internetgiganten”
Flexible Architekturen embarc.de 18Themen für Entscheidungen
Zerlegung
Module und Abhängigkeiten
Komponentenbildung
...
Technologie-Stack
Programmiersprache(n), Bibliotheken, Frameworks
Middleware (Kommunikation, Applikationsserver ...)
Querschnittsthemen (Persistenz, Oberfläche ...)
...
Zielumgebung
Wo läuft die Software? (Endanwender vs. RZ vs. Cloud)
Verteilungsaspekte (Redundanz, Clustering)
Virtualisierung
...
Flexible Architekturen embarc.de 19Agenda
1 Anforderungen klären
2 Flexible Lösungsansätze
3 Dokumentation
2
4 Ausblick
Flexible Architekturen embarc.de 20Flexible Architekturen embarc.de 21
High Level Lösungsstrategien
Laufzeitmonolith Microservices
Klassischer Betrieb DevOps
vs.
On Premises Serverless/Cloud
Relationale DBs NoSQL/In-Memory
Langlebigkeit Kurzlebigkeit
Flexible Architekturen embarc.de 22High Level Lösungsstrategien
Laufzeitmonolith Microservices
K on Betrieb
Klassischer DevOps
ser Mo
vat
On Premises de
Serverless/Cloud
iv? rn
Relationale DBs
?
NoSQL/In-Memory
Langlebigkeit Kurzlebigkeit
Flexible Architekturen embarc.de 23Vorteile/Herausforderungen/Ziele
Belastbar/hochverfügbar
“gediegen” widerstandsfähig
Gewohnheit komplex
zustandsbehaftet Hohe Lernkurve
Datensicherheit flexibel
automatisiert
Klassische
skalierbar
Organisationsstrukturen Neue
verstanden Herangehensweisen
Transaktionen Conway’s Law beachten
planungssicher Time-To-Market
Flexible Architekturen embarc.de 24Rahmenbedingungen
Cloudausrichtung/-guidelines
Klassische
Organisationsstrukturen (Public) Cloud first Ansatz
Lange Produktlaufzeiten und
Agile Prozesse etabliert
Kundenbindungen
Offene Mitarbeiter
Datenschutz-/sicherheit
Ausreichende
Unflexibler Inhouse-Betrieb
Entwicklungskapazitäten
Keine agilen Prozesse
Fortgeschrittene
Langlaufende Automatisierung und
Lizenzverträge Infrastruktur als Code
Flexible Architekturen embarc.de 25Qualitätsmerkmale
Benutzbarkeit Portabilität
Begriffe (Usability) (Portability)
nach Ist die Software intuitiv zu bedienen, Ist die Software leicht auf andere
Zielumgebungen (z.B. anderes OS)
ISO 25010 leicht zu erlernen, attraktiv?
übertragbar?
Funktionale Eignung Effizienz Kompatibilität
(Functional Suitability) (Performance) (Compatibility)
Sind die berechneten Ergebnisse Antwortet die Software schnell, hat Ist die Software konform zu
genau genug / exakt, ist die sie einen hohen Durchsatz, einen Standards, arbeitet sie gut mit
Funktionalität angemessen? ... geringen Ressourcenverbrauch? ... anderen zusammen?
Zuverlässigkeit Sicherheit Wartbarkeit
(Reliability) (Security) (Maintainability)
Ist das System verfügbar, tolerant Ist das System sicher vor Angriffen? Ist die Software leicht zu ändern,
gegenüber Fehlern, nach Abstürzen Sind Daten und Funktion vor erweitern, testen, verstehen? Lassen
schnell wieder hergestellt? ... unberechtigtem Zugriff geschützt? ... sich Teile wiederverwenden? ...
Flexible Architekturen embarc.de 26Qualitätsziele
Skalierbarer Durchsatz und
Antwortzeiten
Einheitliche
Bedienbarkeit Hohe Zuverlässigkeit
Effiziente Wartbarkeit
Korrekte Funktionalität
Gebotene Sicherheit
Einfacher und günstiger Leicht erweiter-/
Betrieb integrierbar
Flexible Architekturen embarc.de 27Lösungsstrategie
Stellt Qualitätsziele und zugeordnete high-level
Lösungsansätze in Beziehung zueinander dar.
Form: Tabelle ([ Ziele | Lösungsansätze ]).
Architektur-
/Lösungsansätze
Architektur-
/Qualitätsziele
Flexible Architekturen embarc.de 28Kompakte Darstellung
Lösungsstrategie
Qualitätsziel Architekturansatz
QZ 1 Ansatz a)
Prägende
Ansatz b) Entscheidungen,
QZ 2 Ansatz c) Konzepte, Muster,
Prinzipien ...
QZ 3 Ansatz d)
QZ 4 Ansatz e)
Ansatz f)
...
Top 3-5
Architekturziele
Flexible Architekturen embarc.de 29Typische Lösungsansätze Flexible Architekturen embarc.de 30
Wichtig ...
!
Die Lösungsstrategie schlägt die
Brücke zwischen
architekturrelevanten
Anforderungen und Eurer Lösung.
Flexible Architekturen embarc.de 31Beispiel
Ziel Passende Lösungsansätze
• Betrieb in Public Cloud
Verfügbarkeit
• Resilience Patterns
• Public API
Benutzbarkeit
• Asynchrone Verarbeitung und Messaging
Modifizierbarkeit • Microservices
Wartbarkeit • Komplette Automatisierung
• Einsatz modernster Technologien
Attraktivität
• Viele Lösungen sind Open Source
• Oauth und OpenID
Sicherheit
• Hoher Datenschutz durch private Cloud
Flexible Architekturen embarc.de 32High Level Lösungsstrategien
Laufzeitmonolith Microservices
Klassischer Betrieb DevOps
vs.
On Premises Serverless/Cloud
Relationale DBs NoSQL/In-Memory
Langlebigkeit Kurzlebigkeit
Flexible Architekturen embarc.de 33Monolith Flexible Architekturen embarc.de 34
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, often an
HTTP resource API.”
(James Lewis, Martin Fowler)
Charakteristische Eigenschaften
Zerlegung in relativ kleine (fachliche) Services
Services sehr lose gekoppelt
Services einzeln installierbar und upgradebar
Dezentrale Datenhaltung
Hoher Freiheitsgrad bei Technologieauswahl
è https://www.martinfowler.com/articles/microservices.html
Flexible Architekturen embarc.de 35Laufzeitmonolith vs. Microservices
q Effizienz (solange nicht zu groß) q Fördert Domänenorientierung und Fokussierung
q Erzwingt Modularisierung/saubere Schnittstellen
q Leichte Installier- und Betreibbarkeit
q Kleinere Arbeitspakete, funktionale Blöcke leicht
q Strukturierung möglich (Modulith) auszutauschen und zu ergänzen
q Technische Schulden einfacher kontrollierbar
q Separate Skalierung, unabhängiges Deployment
q Schwierige Wartbarkeit bei Big Ball of q Schnelle Anpassungen im laufenden Betrieb
Mud (Time-To-Market)
q Autonom arbeitende Teams
q Niedrige Strukturiertheit
q Elastisch auf Lastanforderungen reagieren
q Unkontrollierte Abhängigkeiten
q Pathologische Phänomene für q Hohe Komplexität beim Deployment und Betrieb
schlechtes Design (hohe Kopplung, q Netzwerk-Kommunikation
niedrige Kohäsion, zyklische q Steile Lernkurve, Org.struktur anpassen
Abhängigkeiten, Zerbrechlichkeit, q Hoher Automatisierungsgrad notwendig
Unbeweglichkeit, Starrheit)
Flexible Architekturen embarc.de 36Klassischer Betrieb vs. DevOps
q Jahrzehntelange Erfahrung q Crossfunktionale, autonome Teams
q Hoher Automatisierungsgrad
q Fokusierung des Betriebssystems
q Reproduzierbarkeit, Dokumentation
und Versionierung durch Infrastructure
as Code und GitOps
q Strikte Trennung zw. Betrieb und
q Kontinuierliche
Entwicklung Verbesserungsprozesse
q Aufwändige Fehlersuche q Zero-Downtime Deployments, Canary
Releases
q Unflexibel und starr
q Plattformunabhängigkeit durch
q meist kaum oder nur einfache Containerisierung und Kubernetes
Automatisierungen
q Lange Beschaffungsprozesse q Hohe Teamverantwortung
q Neue Komplexitätsstufe, steile
q Wartezeiten für die Entwicklung Lernkurve
Flexible Architekturen embarc.de 38On-Premises vs. Serverless/Cloud (Public)
q Daten und Software vor Ort q Elastisch, auf Lastspitzen reagieren
q Hoher Datenschutz und –sicherheit in q Infrastruktur up to date
eigener Hand q Großes Angebot an Diensten
q Unterstützung verschiedener q Bezahlung nur bei Nutzung
Deployment-Szenarien (Bare Metal, q Global verfügbar, regionsbasierte
VMs, Private Cloud) Lastverteilung, Verteilung geschenkt
q Zero-Downtime Deployments, Canary
Releases, selbst heilende Software
q Aufwändiger Betrieb (Patches, q Teuer bei großer Last
Bugfixes, Sicherstellen der
Datensicherheit) q Daten außerhalb der Organisation
q Alternative Deploymentartefakte
q Spezielles Personal, ggf. 24/7 Support (GraalVM, Go, …)
Flexible Architekturen embarc.de 39Relationale DBs vs. NoSQL/In-Memory
q Gut verstandene Konzepte q Hohe Verfügbarkeit
q Ausgereifte Datenbanken und Tools q Gute Skalierbarkeit, große
Datenmengen
q Viele verfügbare Entwickler
q Einfache Datenredundanz
q ACID Transaktionen (aber gar nicht
q An Usecase angepasste
immer notwendig!) Datenmodelle (Schemafreiheit)
q Datenbank-Schema q Einfacheres Programmiermodell
(Aggregatorientierung)
q Skalierung aufwändig/unmöglich q Polyglotte Persistenz
q Allgemeines Datenmodell (Schema)
q Eventually Consistency (BASE)
q Impedence Mismatch
(Objektrelationale Unverträglichkeit) q Technologie-Zoo, kaum Standards
q Andere Modelle - Mindchange
Flexible Architekturen embarc.de 40Langlebigkeit vs. Kurzlebigkeit
q Vorausschauende, planbare q Schnell mit Ideen am Markt (A/B-
Produktentwicklung Testing, Canary Releases)
q Zukunftssicherheit q Schnelles Reagieren auf Änderungen
q Integriert sich gut mit agilen
Methoden
q Automatisiertes Ausrollen durch
Deployment Pipelines (Continuous
Delivery)
q Langsame Entwicklungszyklen
q Automatisierte Regressions- und
q Schlecht bei häufigen Änderungen E2E-Tests
q Big-Bang Releases (Stop-The-World)
q Aufwändigere Qualitätskontrollen
q Ggf. Kundenunzufriedenheit in Kauf
nehmen
Flexible Architekturen embarc.de 41Agenda
1 Anforderungen klären
2 Flexible Lösungsansätze
3 Dokumentation
3
4 Ausblick
Flexible Architekturen embarc.de 42Dokumentation des Entwurfs
Architekturüberblick Lösungsansätze
- Mission Statement - Architekturstil
- Kontextabgrenzung - Technologie-Stack
- Konzepte
Einflüsse
- Prinzipien
- Vorgaben
- Zerlegung
- Architekturziele
- ....
Flexible Architekturen embarc.de 43Was ist ein Architekturüberblick?
Ein Architekturüberblick macht die zentralen Lösungsansätze Eurer
Softwarearchitektur für Außenstehende nachvollziehbar.
Neue Entscheider Teamfremde
Teammitglieder Stakeholder Kollegen
Flexible Architekturen embarc.de 44Mission Statement
Plakative Darstellung der
Aufgabenstellung
Wenige (2 – 3) Sätze
oder Stichpunkte
Metapher Produktkarton
Flexible Architekturen embarc.de 45Kontextabgrenzung
Abgrenzung des Systems und Visualisierung der Benutzer und
Fremdsysteme, mit denen es interagiert.
Form: Graphik, ergänzt um kurze Beschreibungen.
Fremdsysteme
Benutzer
System (Blackbox)
Flexible Architekturen embarc.de 46Systemkontext einer Online-Platform Flexible Architekturen embarc.de 47
Was sonst noch dokumentieren? Sichten auf das System • Bausteinsicht • Laufzeitsicht • Verteilungssicht Querschnittliche Konzepte erklären Entwurfsentscheidungen nachvollziehbar festhalten Qualitätsszenarien als Ausgangspunkt für quantitative Bewertungsmethoden (ATAM, …) Flexible Architekturen embarc.de 48
arc42 Vorschlag für ein Template (G. Starke, P. Hruschka) è http://arc42.org/ Flexible Architekturen embarc.de 49
„Abheften“ in arc42 Flexible Architekturen embarc.de 50
Agenda
1 Anforderungen klären
2 Flexible Lösungsansätze
3 Dokumentation
4
4 Ausblick
Flexible Architekturen embarc.de 51Anforderungen
klären
Architektur Architektur
bewerten entwerfen
Architektur
kommunizieren
aus: Effektive Software-
architekturen (G. Starke)
Flexible Architekturen embarc.de 52 52Beeinflussungen und Abhängigkeiten
Laufzeitmonolith Contin
uou s Deliv
ery
Microservices
Provi
sio
Klassischer Betrieb DevOps
Ti
Konfi inierung
m
gurat
e-
ion Persistenz
To
-M
ar
ke
t
On Premises
Provisionierung
Automatisiertes Deployment
Serverless/Cloud
Relationale DBs Installiert auf
NoSQL/In-Memory
Langlebigkeit Läuft auf
Kurzlebigkeit
Flexible Architekturen embarc.de 53Was bleibt/wird wichtig?
Schnelligkeit
Zügige Entwicklung und Ausrollen für schnelle Anpassung an den Markt
Fehler akzeptieren, daraus lernen
Flexibilität
Einfacher Austausch von Bausteinen und Technologien
Redundanzen in Kauf nehmen
Skalierbarkeit
Hohe Anpassbarkeit an wechselnde Bedürfnisse
Flexible Architekturen embarc.de 54Fazit
Es gibt nicht die eine flexible Softwarearchitektur
Alles hat seine Vorteile, aber auch Kompromisse/Herausforderungen
Stärken/Schwächen kennen, um gute Entscheidungen treffen zu können
Aber: Anforderungen ändern sich
Erfahrungen bauen sich auf
Flexible Architekturen embarc.de 55Schlusswort(e)
Softwarearchitekturarbeit bleibt weiterhin anspruchsvoll
Moderne Technologien, Architekturstile/-muster eröffnen neue Optionen,
machen es aber nicht per se einfacher
Flexible Architekturen embarc.de 56Vielen Dank.
Ich freue mich auf Eure Fragen!
fs@embarc.de
@sippsack
è xing.to/fsi
Falk Sippach
Flexible Architekturen embarc.de 57Sie können auch lesen
