TU Wien:Distributed Systems Engineering VU (Weidl-Rektenwald)

Aus VoWi
Zur Navigation springen Zur Suche springen
Ähnlich benannte LVAs (Materialien):

Daten[Bearbeiten | Quelltext bearbeiten]

Vortragende Philipp Alexander RaithJohannes Weidl-Rektenwald
ECTS 3,0
Letzte Abhaltung 2024S
Sprache Deutsch
Abkürzung DSE
Mattermost distributed-systems-engineeringRegisterMattermost-Infos
Links tiss:184153
Zuordnungen
Masterstudium Software Engineering & Internet Computing Modul Distributed Systems and Networking (Gebundenes Wahlfach)


Inhalt[Bearbeiten | Quelltext bearbeiten]

ca. 6 VO-Einheiten rund um Software Engineering und Distributed Systems. "Offizieller" (=Folien-)Stoff ist etwas chaotisch und Wikipedia-lastig. Da der Vortragende aber nur in geringem Maß an der TU seine Moneten macht und stattdessen sehr stark in der freien Wirtschaft tätig ist, bereicht er den Vortrag ungemein mit praxisnahen Gschichteln, Tipps usw. Daher ist der Vortrag sehr zu empfehlen. Seine eigene Aussage (in etwa): Heute ist das Wikipedia-Zeitalter und es gibt nichts, was nicht in der Wikipedia steht, darum schreib ich nicht so viel auf die Folien (weil das könnts ihr eh selbst nachschauen) und erzähl stattdessen das, was nicht in der Wikipedia steht.

Das stimmt dann auch ziemlich. Berühmte Quotes (wiederum nur in etwa): "ACID, das war früher das Um und Auf, nichts ging ohne ACID und die Welt bestand aus ACID -- dann haben sich die Leute überlegt, ob wir das wirklich brauchen" (oder so in etwa). Weiters: "Der Bottom-Up-Approach - da teilt man das Problem in lauter kleine Subprobleme auf und jedes Team macht dann eine Lösung für das Subproblem. Und am Ende versucht man das alles zu integrieren. Und die Lösung lautet dann meistens, wir hauen das alles weg und kaufen SAP."

Außerdem gibt es parallel dazu eine Übung in 3er-Gruppen (siehe unten).

Ablauf[Bearbeiten | Quelltext bearbeiten]

ca. 6 VO-Einheiten; Übung in 3er Gruppen rund um Distributed Systems Engineering (mit vorgegebener Angabe); Übung mit "Projektstruktur".

SS2019: 7 VO-Einheiten

Benötigte/Empfehlenswerte Vorkenntnisse[Bearbeiten | Quelltext bearbeiten]

  • Java-Kenntnisse nötig
  • Spring/Dropwizard und Maven-Kenntnisse von Vorteil (sonst geht viel Zeit damit drauf, das zu lernen, ihr kennts es eh vermutlich)
  • SS2015: MongoDB und Docker von Vorteil (aber auch problemlos nebenbei lernbar)
  • Lt. Prof. Verteilte Systeme (Vorlesung und Übung), das ist aber nicht essentiell
  • Spring MVC, Web, JSP, HTML, Angular etc.

Vortrag[Bearbeiten | Quelltext bearbeiten]

Eindeutig einer der besseren Vorträge. Sehr frei, sehr praxisorientiert. Allerdings oft ein bisschen Buzzword-lastig. Im Vortrag kommt selbst allerdings nur vergleichsweise wenig konkreter Stoff vor. Dennoch Empfehlung.

Andere Meinung (SS2019): Der Vortragende versucht krampfhaft "lustig" zu sein - der gesamte Vortrag besteht aus unlustigen Kommentaren und buzzwords. Eigentlicher Informationsgehalt <5% und IMHO Zeitverschwendung.

Übungen[Bearbeiten | Quelltext bearbeiten]

SS2012[Bearbeiten | Quelltext bearbeiten]

Im SS2012 ein relativ praxisnahes Projekt mit Spring MVC, Maven, JUnit etc. in 3 Komponenten entwickelt und auf der Cloud-Plattform cloudfoundry.com deployed werden musste. Die Übung ist mittelmäßig-wenig zeitaufwändig (bei etwas Geschick bzw. Kenntis der Technologien und guten Gruppenpartnern). Am Ende des Semesters gibt's dazu ein Abgabegespräch. Theoretisch stehen Tutoren zum Fragen im TUWEL zur Verfügung, aber im SS12 hat keiner eine einzige Frage gestellt.

Der Ablauf der Übung ist etwas projektmäßig, mit Projektplan, Architektur- und Designdokument, Wartungshandbuch, Code und Fazit-Dokument (letzteres pro Gruppenmitglied, der Rest pro Gruppe), dazu halt jeweils Abgabetermine und Punkte pro Deliverable.

SS2015[Bearbeiten | Quelltext bearbeiten]

Es war ein System zur Verwaltung von OP-Wartelisten zu implementieren. Mittlerweile wird nicht mehr oben genannte Cloud-Plattform verwendet, sondern es war eine Microservice Architektur zu entwickeln, davon verpflichtend:

  • mindestens zwei Microservices in Java (Vorschläge: Spring Boot, Dropwizard oder Spring Data MongoDB)
  • Hystrix
  • MongoDB (Geo-Suche)
  • Docker
  • REST-Schnittstelle am API-Gateway
  • mindestens 3 Unit Tests pro Service
  • mindestens ein Lasttest gegen das API-Gateway

Restliche Technologien und APIs waren frei zu wählen, in unserem Fall Node.js für weitere Microservices, Docker Compose für die Container-Verwaltung und Foundation/AngularJS für das Web-Frontend.

Ablauf der Übung immer noch gleich projektmässig wie oben beschrieben. Die zu erstellenden Dokumente sollten nicht unterschätzt werden, die kosten einiges an Zeit wenn man sie vollständig macht und alle Aspekte dokumentiert. Das soll den Charakter einer echten Projektentwicklung zeigen, bringt aber (imho) keinen Wissensgewinn.

SS2019[Bearbeiten | Quelltext bearbeiten]

Übungsbeispiel war ein "Unfalldatenspeicher" für autonomes Fahren. Es gibt hier die drei Akteure OEMs, Blaulichtorganisationen und autonome Fahrzeuge.

OEMs können sich ihre aktiven Fahrzeuge auflisten oder in einer Kartenansicht anzeigen lassen und werden über Crash Events benachrichtigt.
Blaulichtorganisationen werden über neue Crashes benachrichtigt, legen aktive Unfälle an, können aktive Unfälle auf einer Kartenansicht einsehen, können alle Unfälle auflisten und aktive Unfälle auf "inaktiv" setzen.
Autonome Fahrzeuge übermitteln ihre Position und werden über Crash Events im 3km Radius benachrichtigt und können diese außerdem auf einer Kartenansicht einsehen.

Zu erstellende Komponenten:

  • API-Gateway (REST-Schnittstelle zu UI und Services)
- muss Hystrix verwenden (Projekt zu dem Zeitpunkt schon im maintenance mode)
  • Min. 3 Microservices (min. 1 in Java)
    • Jeder Service mit eigener Datenhaltung (z.B. MongoDB)
    • Evtl. Message Queue
  • Web GUI mit Ansichten für 3 verschiedene Akteure
- inkl. Kartenansicht und evtl. push notifications
  • Simulation
- Erzeugt Bewegungsdaten und Events

Das ganze muss kontainerisiert sein und auf Kubernetes in Google Cloud Platform deployed werden. Jeder Service muss in einem eigenen Container laufen und darf direkt nur auf die eigenen Datenbank zugreifen. Es muss min. eine MongoDB-Instanz verwendet werden.

Abzugeben sind ein Projektplan, ein Architektur- und/oder Designdokument, der Code, ein Wartungshandbuch und ein Dokument mit "Lessons learned/Conclusio".

SS2020[Bearbeiten | Quelltext bearbeiten]

Grundsätzlich recht ähnlich zu SS2019. Es war jedoch eine Auto/Ampelsimulation zu erstellen, bei der die Autos durch Steuern der Geschwindigkeit eine grüne Welle erreichen sollen. Hystrix musste nicht verwendet werden und die Technologie für die Microservices war nicht eingeschränkt.

Prüfung, Benotung[Bearbeiten | Quelltext bearbeiten]

VO-Prüfung und Abgabegespräch. Der Punkteschlüssel für die Übung ist sehr deutlich in der Angabe zu lesen. Prüfung ist tatsächlich relativ praxisnah. DH nicht "zähle alle Bullets von Folie X auf" sondern lt. Prof. z.B. "Beschreiben Sie Herausforderungen, die beim Bau von VSys entstehen können".

Prüfung SS2016: Fast dieselben Fragen wie im SS2015. Achtung! Auf der ersten Seite steh auch eine Frage ;)

SS18: Multiple choice test. Mit teils recht schwammingen Fragen und noch schwammigeren Antworten. 32 Fragen insgesamt, jede 1.25 Punkte (40 Punkte total), es ist mindestens eine Antwort von vier möglichen richtig, maximal sind alle Antwortmöglichkeiten richtig. Keine Teilpunkte aber auch keine Abzüge für falschbeantwortete Fragen. 60 Minuten zeit. Es war eher ein Buzzword Bingo und teils raten wie Fragen zu interpretieren sind. Fragen kamen auch zu Kubernetes, Hystrix (was nur in der Übung aber nicht in den Folien vorkommt).

SS19: Siehe SS18. Zusätzlich zu erwähnen: Es gibt viele redundante Fragen (mind. 5 mal "Was sind die Vorteile von Microservice-Architekturen?" in unterschiedlichen Formulierungen). Außerdem gibt es NICHTS in den Folien, was nicht gefragt werden könnte, auch die vermeintlich irrelevantesten Infos. Die Benotung war noch am selben Abend im Tuwel eingetragen.

SS20: Sehr faire Prüfung, wer vorbereitet ist kann problemlos eine gute Punktzahl erreichen.

Siehe Materialien!

Dauer der Zeugnisausstellung[Bearbeiten | Quelltext bearbeiten]

relativ lang (deutlich über 4 Wochen, ich glaub in etwa 6), allerdings kam die Note relativ pünktlich nach 4 Wochen. (Bzw. Benachrichtigung zur Einsichtnahme kam nach 4 Wochen; lustigerweise stand da die Note nicht dabei. Hab dem Prof dann aber eine Mail geschrieben und die Antwort war am nächsten Tag da.)

SS2015: Zeugnis zwei Wochen nach Prüfung/Abgabegespräch

Zeitaufwand[Bearbeiten | Quelltext bearbeiten]

OK. Da für die Prüfung nicht irrsinnig viel Stoff ist und viel vom Stoff schon woanders gehört wurde, muss man sich halt einige Dinge nochmal in Erinnerung rufen bzw. auf den speziellen Weidl-Rektenwald-Stil eingehen.

Die Übung kann von sehr wenig Zeitaufwand (mit Vorkenntnissen in den Technologien, speziell Spring MVC, JSP, Maven, CloudFoundry) bis moderat viel Aufwand (mit wenig Vorkenntnissen und schlechten Gruppenmitgliedern) reichen.

SS2019: Das Projekt ist extremst zeitaufwendig. Alleine die Dokumentation ist sehr umfangreich. Außerdem die Einarbeitungszeit in die Schiere Menge an neuen Technologien (soweit man keine Erfahrung mit ihnen hat), z.B. MongoDB und Geolocation, Docker, Kubernetes, GCP, Hystrix, usw. usf. (Disclaimer: ich habe das Projekt und die LVA nicht abgeschlossen.)

SS2020: Das Projekt ist wirklich extremst zeitaufwendig. Falls man mit den Technologien vertraut ist und möglicherweise auch nichts neues ausprobiert, ist es in der geschätzten Zeit umsetzbar. Kennt man jedoch nicht alle Technologien muss man viel Zeit einplanen. Wichtig ist auch zu versuchen früh anzufangen und sich auf die wirklich geforderten Features zu konzentrieren und sich nicht in den optionalen zu verlieren.

Anderer Student: Zeitaufwand ist fair, aber man darf nicht zu viel neues ausprobieren. Ein guter und moderner Tech-Stack im Backend wirkt wahre Wunder.

Unterlagen[Bearbeiten | Quelltext bearbeiten]

VO-Folien im TISS.

Tipps[Bearbeiten | Quelltext bearbeiten]

  • Angabe genau lesen, alle Pflichtpunkte erfüllen.
  • Implementierung nicht auf die letzten Wochen lassen. Im Juni ist sonst meist sehr viel los, und das Zusammenspiel der Services sowie das Zusammenfügen der APIs ist nicht zu unterschätzen. Besser auf eine Fertigstellung Ende Mai abzielen.

Highlights / Lob[Bearbeiten | Quelltext bearbeiten]

  • Ich bin nun überzeugt einen Audi zu kaufen.

Verbesserungsvorschläge / Kritik[Bearbeiten | Quelltext bearbeiten]

  • Das Buzzword-Bingo kann manchmal nerven, wenn man nicht 100%ig von der supertollen Cloud und "wir sind jung und dynamisch und daher die tollsten" überzeugt ist.
  • Obige Kritik ist sicher richtig, es ist aber ein angenehmer Kontrast gegenüber anderen (teilweise verstaubt wirkenden) TU-LVAs, dass hier sehr aktuelle (gehypte) Technologien zum Einsatz kommen dürfen und sollen. Die große Wahlfreiheit ist dabei definitiv ein Plus.