Test 1 Flashcards
Gibt es eine gute Architektur?
Jedes System hat eien Software-Architektur
(welche dokumentiert oder verbreitet sein kann)
Nein gute oder schlechte Architektur, entweder mehr oder weniger funktional für Ziel
Architekturen können anhand spezifisch gestetzter Ziele evaluiert werden
Komponentisierung und Abstraktion
Komponentiesierung versteckt Komplexität
- Abstraktion erlaubt lokale Veränderung
- verkürzt Zeit zum einschätzen
- Layering = wiederholte Abstraktion
Wert ist vertikal abgeleitet
Layers eines Information System
Client: jeder Benutzer oder Programm welches eine Operation über das System ausführen will
Presentation Layer: Clients interagieren mit System über PL
application logic layer: bestimmt was das System eigentlich macht
ressource management layer: kümmert sich um die Organisation der Daten um die application layer zu unterstützen (typischerweise Datenbank)
Pfeile und Boxen
Box als Teil des Systems
Pfeil als Verbindung
je mehr Boxen desto modularer -> mehr Möglichkeiten für Verteilung und Parallelisierung
je mehr Pfeile desto mehr sessions (Verbindungen) -> müssen gewartet, koordiniert werden. -> System komplexer
-> schlechtere Permormance
System Designer versuchen die flexibilität von modularem Design mit dem performance Ansprüchen von realen applications zu balancieren
Kein Problem kann nicht durch hinzufügen einer weiteren Stufe gelöst werden
Kein Performance Problem kann nicht gelöst werden indem eine Stufe entfernt wird
Software Components
- unit of composition
- spezifiziertes Interface
- explizite Abhängigkeiten
- kein spezifisches execution environment
- verschiedene Realisierunge möglich (Sprache, Code strucuture)
- zusammensetzbar aus anderen Software Components
Von Software Components zu Services
über:
- inter-process communication
- Netzwerk Protokolle
- Web Protokolle
Service als virtuelle Komponente
Impact of Software Architecture
hindert oder ermöglicht quality attributes eines systems
- Performance, Modifiability, security, Scalability, Reusability
Konsequenzen für change management
ermöglicht Kommunikation unter stakeholders
- verständlichkeit für alle (auch nicht IT-Menschen)
Trägt fundamentale Design Entscheidungen und Einschränkungen
Bottom-Up Design
- definiere access-channel und client platform
- Untersuche esistierende Ressourcen und deren Funktionalität
- verpacke existierende Ressourcen und integriere deren Funktionalität in einheitliches Interface
- passe output der application logic so an, das es von benötigten access-channel und client protocols benutzt werden kann
Hauptkosten bei wrappers und interfaces zu alten anwendungen
Top-Down Desing
- definiere access-channel und client-platform
- definiere presentation formats und protocols für den Client
- definiere die Funktionalität um content und format an die presentation layer zu liefern
- definiere date sources und data organization die für implementierung der application logic benötigt wird
Wrapper
adapter design pattern erlaubt inkompatible Klassen (Client und Adaptee) mitenander zu arbeiten indem das interface des Adaptee in ein vom Client erwartetes Interface konvertiert wird
One-tier
Vollzenetralisierte Architektur
User/Programs greifen auf das System durch display terminals zu, was gezeigt wird ist vom Server kontrolliert(“dumb terminals”).
höchst optimierbar
Two-tier
presentation layer bei Client
- Clients sind unabhägnig voneinander
- Zugriff über API
- ressource manager sieht nur einen client -> application logic
- server muss sich um alle möglichen Clients connections kümmern (maximale Anzahl an Verbindungen)
- Konkurrenz zwischen Clients
- Client als point of integration zwischen Systemen (fat clients)
- Sehr ineffizient
3-tier
komplett separierte Tiers
layers in der Regel verteilt
middleware als umweg zwischen client und anderen layers des system, zusätzliche layer die alle unterliegendenlayers umfasst
- redurziert anzahl der client interfaces
- transparenter zugriff auf untere systeme
- platform für inter-sytem funktionaitä
- übernimmt finden, zugriff und sammeln von ressourcen
N-tier
verbundene 3-tier systeme
web-server als zusätzliche layer für den zugriff von clients
web layer als presentation layer auf server seite
client greift durch web browser auf presentation layer zu
services
ein oder mehrere deployed, runnig (“always-on”) software programme, geräten und netzwerken die zusammenarbeiten um eine für den end-user zusammenhängende applikation zu liefern
Service oriented Computing (SOC)
deployed software einheiten die über ein netzwerk verteilt sind, welche benutzt werden können um business prozesse und - applikationen zu erstellen
Service oriented Architecture (SOA)
- Wiederverwendbarkeit
- geringer Aufwand beim - erstellen neuer Funktionen
- Bessere Skalierbarkeit
- Hohes Maß an Komplexität
- Höherere Initialaufwand
- Hohe Wiederverwendung kann zu zentraler Abhängigkeit führen
Reliability
Wahrscheinlichkeit R(t) das ein System in einem Intervall [0:t] zufriedenstellend funktionioniert. Wenn es in t=0 funktioniert hat.
R(t) = 1 - F(t)
R(t) = [f(tau) d tau]t-inf.
= 1 - [f(tau) d tau]0-t
Availability
A(t) Wahrscheinlichkeit das das System zu einem Zeitpunkt t zufreidenstellend funktioniert.
steady-state Availability:
As = MTTF/MTBF
Fault Intolerance vs Fault Tolerance
Intolerance -> Fehler vermeiden
- sehr zuverlässige Komponenten
- ausgearbeitete Design Techniken
- ausgearbeitete Herstellungs Techniken
- viele Tests
Tolerance -> Fehler tolerieren
- höhere Reliability
- manchaml niedrigere Gesamtkosten
- Kundenvertrauen
- Kosten für Redundanz
- manchmal höhere Komplexität
Redundancy
Duplizierung kritischer Komponenten
static -> alle Komponenten laufen kontinuierlich
dynamic -> Komponenten werden nach Bedarf dazu geschaltet
Triple Modular Redundancy
- mehrheit der Module muss funktionieren (2/3)
- Voter als kritische Komponente muss immer funktionieren
- Voter gibt richtiges Result wenn Mehrheit der Komponenten funktionieren
Structural vs. Time Redundancy
Structural -> Mehrere Ressourcen um redundancy
herzustellen
Time -> Eine Ressource wird länger benutzt um redundancy herzustellen
Performance
Ziel der performance hängt von spezifischen System Anforderungen ab
kann durch Benchmark bestimmt werde:
- Reales Programm
- Komponenten
- synthetische Benchmarks
Scalability
Horizontal:
- zusätzliche nodes
- software muss angepasst werden
Vertical
- zusätliche ressourcen zu node hinzufügen
- limitiert durch vornhanene technologie
Speedup
S = Ta/Tb relative Performance zwischen 2 Systemen die das gleiche Problem bearbeiten
S(p) = T(1)/T(p) performnace zwischen seriellen und parallelen System
E(p) = S(p)/p Parallele Effizienz, misst den Zeitanteil indem ein Prozessor genutzt wird
Amdahls Law
T(p) = Ts + Tp / p S(p) = Ts / Tp
Elasticity vs. Scalability
Scalability
- misst wie effizient und wie groß ein System werden kann
- wenn ich soviel X% Ressorce hinzufüge, wieviel Y% höhere Performance wird erreicht
Elasticity -> speziell für Cloud Services
- beschreibt was passiert wenn während der Laufzeit skaliert wird
- Wie lange?
- side-effects?
Strict Consistency
Alle geschriebene Daten sind sofort da
Sequential Consistency
Jeder prozess führt die Befehle in genau der Reihenfolge aus, in der sie im Programm festgelegt sind
Causal Consistency
Writes, welche Abhängig sind müssen von allen Prozessen in der gleichen Reihenfolge gesehen werden
FIFO Consistency
Writes von einem prozess wernde von anderen Prozessen in de gleichen Reiehnfolge gesehen
Security
- Interception
- Interruption
- Modification
- Fabrication
Static Process Models
- lange Release Zyklen
- keine Veränderung möglich
- keine kontinuirliche Lieferung möglich
Core Values of the Agile Manifesto
- Individuen und Interaktionen über Prozess und Werkzeugen
- Funktionierende Software über ausführlicher Dokumentation
- Kunden zusammenarbeit über Vertragsverhandlung
- auf Veränderung reagieren über folgen eines Plans
Agile Software Development
- frühe und stetige Auslieferung
- schnelle Iteration um Änderung zu ermöglichen
- Selbstorganisierende Teams
- nachhaltige Entwicklung
- weniger strikte Struktur
SCRUM 3-3-4
Artifacts:
- Product Backlog
- Sprint Backlog
- Burndown Chart
Roles:
- Product Owner
- Scrum Master
- Team
Ceremonies:
- Sprint Planning
- Daily Scrum 3 Fragen
- Sprint Review
- Sprint Retroperspective
Kanban
- Limit Work-In-Progress
- Visualize production (Kanban board)
- Measure time cycle and improve
DevOps
Requirements Development Build Testing Deployment Execution
Beschleunigung des Deploymentprozesses duch geringeren Synchronisationsaufwand, kleine Teams (schnellere Entscheidungen), weniger Koordination.
Jedes Team kümmert sich um nur eine Funktion -> Microservices
Implikation vo DevOps
- Hohe Code Qualität
- Hohe Qualität der build & delivery Mechanismen
- geteilte Zeit
- Ziel-orientierte Definition
Version Control Systems
Weil Software meistens in Teams entwickelt wird
- es sollte gleichzeitig gearbeitet werden
- Veränderung sollte icht zu Konflikt führen
- Jede Version soll archiviert werden
- Wer?
Testing
kann Fehler aufzeigen, aber nie deren Fehlen
- Unit testing
- Smoke testing
- Integration testing
- Acceptance testing
Microservices
Applikation besteht aus kleienen autonomen Services die jewils eine Funktion besitzen und ein klares Interface haben
Characteristics of Microservices
Componization via Sevices -> eine Funktion, klares Interface
Organized around business capabilities -> Microservices den Anforderungen anpassen
Design for failure
Products, not projects
Smart endpoints dum pipes -> SQS
SOA vs Microservices
Maximiere application service reusability Fokus auf decoupling
shared data storage Each microservice can have an independent data storage
A systematic change requires modifying the monolith A systematic change is to create a new service
Cloud Platform
Globaler, always-on Zugriff
- gesammelte, virtualisierte Ressourcen
- On-demand self service
- Bezahle nur für das was du benötigst
- web als universelle middleware
- Elastizität
Cloud Ownership
Public Cloud:
- Security expertise
- unendliche Scalability
- lock-in Effekte
- third-party pricing
Private Cloud
- keine “noisey neighbours” erhöht performance
- spezifizierte Interfaces können benutzt werden
- hohe Anfangskosten
- Security Probleme müssen individuell behoben werden
Middleware als Programming Abstraction
Set von programming bstractions entwickelt um entwicklung von komplexen verteilten Systemen zu ermöglichen
- versteckt Details der Hardware, Netzwerke und Verteilung
- Evolution abhängig von Trends in Programmiersprachen
Middleware as Infrastructure
Wenn programminc abstractions sich immer weiter entwickeln, die zugrundeliegende Infrastruktur wird dementsprechend größer
Infrastruktur unterstützt zusätziche funktionalität, welche Entwicklung und Intstandhaltung einfacher macht
Nachteile Synchron
Session muss aufrecht erhalten werden -> teuer
Höhere Fehlerwahrscheinlichkeit
Schwierig fehler zu erkennen
RPC
- versteckt Verteilung
- liefert IDL zur Komponenten Beschreibung
- generiert allen notwendigen code selbstständig
- Stub and Skeleton als proxies, anfrage über broker
Messaging
- nicht über Interface
- Message über common message channel ausliefern, andere Apps können Message später lesen
- asynchron
Loose Coupling
- Technology Dependency
- Location Dependancy
- Temporal Dependancy
- Data Format dependancy
