TU Wien:Distributed Systems Engineering VU (Weidl-Rektenwald)/Prüfungsquiz

DSE Prüfungsfragen

Pluspunkt für eine richtige Antwort:
Punkte für eine falsche Antwort:
Ignoriere die Fragen-Koeffizienten:

	Auflösung der Organisation
	Anpassung der Organisation, um eine bessere Software-Architektur zu erzielen
	Entwickler und Tester sind gleichberechtigt im Daily Scrum
	Auflösung der Architektur-Abteilung

	Single Responsibility Principle (SRP)
	Minimierung der Verteilung über Server/Netzwerke
	"Best tool for the job"
	Bounded Context als Grundlage der Modularisierung

	Das Sidecar verändert den Source Code der primären Applikation
	Das Sidecar bietet ein homogenes Interface für Plattform Services (z.B. Logging)
	Das Sidecar übernimmt zwingend die persistente Datenspeicherung lokaler Daten
	Das Sidecar läuft neben der primären Applikation (eigener Prozess bzw. Container)

	Je mehr Microservices desto höher ist die Performance
	Software-Architektur spiegelt die Organisations-Architektur wider
	Organisations-Architektur spiegelt die Software-Architektur wider
	Anzahl der Microservices ist direkt proportional zur Anzahl der Testfälle

	Höhere Robustheit gegenüber System-Ausfällen
	Reduktion der Kommunikation zwischen einzelnen Services
	Erhöhung der Autonomie einzelner Entwicklungsteams
	Bessere Kapselung einzelner Services

	Microfrontends erweitern das Konzept von Microservices auf die Welt der Frontends
	Das GUI von Micropayment Services wird als Microfrontend bezeichnet
	Den Begriff Microfrontends gibt es seit ca. 2016
	Microfrontends betrachten das GUI als Komposition von Einzel-Features

	So groß, dass der Code "in den Kopf des Entwicklers passt"
	Größer als ein Monolith
	So groß, dass ein Microservice "in zwei Wochen neu geschrieben werden kann"
	Alle Microservices sollen exakt gleich groß sein (in Lines of Code gemessen)

	n über 2
	n über n
	n hoch n
	Keine der angeführten Wahlmöglichkeiten

	BASE Architekturen skalieren besser
	BASE unterstützt die System-Eigenschaft "Isolation"
	BASE ist atomar, aber nur solange notwendig
	BASE unterstützt alle ACID Eigenschaften plus die Integration von Microservices

	Typischerweise hochkomplex
	Typischerweise über viele Jahre gewachsen
	Hohes Risiko bei Änderungen, Funktionalität auch außerhalb des Bereiches der Änderung zu beschädigen
	Stets freie Technologieauswahl bei Adaptionen möglich

	Bestehen aus kleinen und verteilten unabhängigen Services
	Slow time-to-market
	Benötigen Kubernetes als Runtime Plattform
	Vertikale Silo Architektur

	Ein Team, das alle Tätigkeiten in der Entwicklung eines Microservices abdeckt
	Ein Team, dessen Teammitglieder auf verschiedene Gebäudeebenen verteilt werden
	Ein Team, das gemeinsam für die Entwicklung eines Microservices verantwortlich ist
	Ein Team, das für die Wartung der zentralen Micro-Datenbank zuständig ist

	ACID-like
	BASE-like
	1 monolithic application - 1 database
	Evolution by Revolution (i.e. recreation of services)

	Greift auf mehrere Datenbanken zu
	Besteht aus mehreren Modulen
	Greift immer ausschließlich auf eine einzelne Datenbank zu
	Folgt dem Architektur-Stil "Service-Oriented Architecture (SOA)"

	Stabilere Umgebung durch unveränderliche Bausteine der Infrastruktur
	Ist immun gegen Hacker
	Änderungen werden automatisch detektiert und das System heruntergefahren
	Änderungen erfolgen immer über neue Versionen der Bausteine der Infrastruktur

	Rückgabe eines Fehlers
	Rückgabe des letzten gültigen Wertes vor Eintritt eines Fehlers
	Einheitliche Zugriffsschnittstelle auf unterschiedliche persistente Datenspeicher
	Rückgabe eines vorkonfigurierten Standardwerts

	Software Bausteine sind semi-mutable
	Kommunikationsendpunkte müssen vollständig autark sein
	Bausteine der Infrastruktur sind mutable (veränderlich)
	Bausteine der Infrastruktur sind immutable (unveränderlich)

	Server-Side Integration (e.g. using Server Side Includes)
	Integration-less Integration
	Client-Side Integration (e.g. using Custom Elements)
	Shared-Nothing Integration

	Das Message Relay kann Events öfters als einmal senden
	Docker Container in der Outbox werden ständig neu gestartet
	Ein Message Relay sendet Events aus der outbox table an den Message Broker
	Als Teil der lokalen Transaktion werden Events in den outbox table eingefügt

	Alle Microservices laufen auf einem einzigen Server
	Einfacherer schrittweiser Wechsel der Technologie
	Höhere Wandelbarkeit der Software
	Einfachere horizontale Skalierbarkeit

	Einzelne Microservices können rasch vollständig neu implementiert werden
	Microservices unterstützen einfache horizontale Skalierung
	Microservices unterstützen eine hohe Evolvierbarkeit (=Evolutionsfähigkeit) der Software
	Für jedes Service kann die geeignetste Technologie zur Anwendung kommen

	Security (Sicherheit)
	Reliability (Zuverlässigkeit)
	Observability (Beobachtbarkeit)
	Accounting of service usage (Verrechenbarkeit der Servicenutzung)

	Teamcode isolieren
	Resiliente Seiten bauen
	Technology agnostic sein
	Team prefixes etablieren
	Browser Features gegenüber Custom APIs bevorzugen

	Nur ein Teil der User wird zur neuen Funktionalität weitergeleitet
	Soll dazu helfen, keinen Big Bang durchführen zu müssen
	Bei Erfolg werden alle User auf den neuen Service umgeleitet
	Wird in Production getestet ("Testing in Production")

	Horizontale Skalierung (MSA) vs. vertikale Skalierung (SOA)
	"1 Service owns 1 Database" (MSA) vs. mehrere Services teilen sich wenige Enterprise-Datenbanken (SOA)
	JSON via REST (MSA) vs. komplexes WS* Protokoll (SOA)
	BASE-like (MSA) vs. ACID-like (SOA)

	Kein Netzwerk-Overhead durch Verteilung
	Einfaches End-to-End Testing
	Einfaches Deployment (eine einzige Einheit)
	Freie Technologieauswahl für jede Komponente
	Eine einzige gemeinsame Codebasis

	Single Responsibility Principle (SRP)
	Open Closed Principle (OCP)
	Liskov Substitution Principle (LSP)
	Dependency Injection Principle (DIP)
	Acyclic Dependencies Principle (ADP)
	Don't Repeat Yourself (DRY)
	Common Reuse Principle (CRP)
	Keep it simple, stupid (KISS)

	Ein Circuit Breaker Framework von Netflix
	Ein Datenbank-Fallback Framework von Google
	Ein Service Mesh von Microsoft
	Ein API Gateway Framework von Amazon

	Der Circuit Breaker "trips" wenn eine konfigurierte Anzahl an aufeinanderfolgenden Fehlern überschritten wird
	Nach dem Auslösen schlagen alle weiteren Aufrufe sofort fehl (für die Dauer eines Timeout-Zeitraums)
	Hystrix ersetzt automatisch ausgefallene Services durch Backups
	Hystrix leitet Anfragen bei Ausfall auf eine zentrale Datenbank um

	Cascading Failures (Fehlerausbreitung auf andere Services)
	Datenverlust bei Datenbankausfall
	Inkonsistente API-Versionen zwischen Services
	Überlastung des API Gateways

	Fehler zurückgeben
	Letzten gültigen Wert zurückgeben
	Vorkonfigurierten Standardwert zurückgeben
	Anfrage an einen anderen Service weiterleiten

	Verteilte Transaktionen und Konsistenz sind schwer zu gewährleisten
	Datenduplizierung und Konsistenzprobleme
	Kein ACID über Servicegrenzen hinweg möglich
	Alle Services müssen dieselbe Datenbank verwenden

	Deployment von potenziell tausenden Services ist komplex
	Optimale Service-Grenzen sind schwer zu definieren
	Integrationstesting ist aufwändiger als beim Monolithen
	MSA benötigt zwingend ein relationales Datenbanksystem

	n*(n-1)/2 Kommunikationskanäle müssen verwaltet werden
	Dezentralisierte Governance kann zu Chaos führen
	Mehr Netzwerk-Overhead als beim Monolithen
	MSA erlaubt keine Verwendung von REST

	Secure service communication
	Access control
	Service discovery
	Traffic governance
	Operation reliability

	Componentization via Services
	Organized around Business Capabilities
	Smart endpoints and dumb pipes
	Centralized Governance
	Decentralized Data Management
	Products not Projects
	Design for Failure
	Shared Database