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

Aus VoWi
Wechseln zu: Navigation, Suche

Daten[Bearbeiten]

Vortragende Weidl-Rektenwald, Johannes; Univ.Lektor Dipl.-Ing. Dr.techn., Diverse Tutoren, tw. von SEPM und ASE
ECTS 3
Abteilung Informationssysteme
Wann Sommersemester
Links tiss:184153
Zuordnungen
M. Software Engineering & Internet Computing Wahlmodul Distributed Systems and Networking

Mattermost: Channel "distributed-systems-engineering" Team invite & account creation link Mattermost-Infos

Inhalt[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]

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]

  • 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]

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]

SS2012[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]

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]

Ü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".

Prüfung, Benotung[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.

Siehe Materialien!

Dauer der Zeugnisausstellung[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]

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.)

Unterlagen[Bearbeiten]

VO-Folien im TISS.

Tipps[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.

Verbesserungsvorschläge / Kritik[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.