Beiträge von AnnaWInf

Ich sitze gerade an meiner Projektarbeit und soll die Risiken eines Cloud-Anbieterwechsels bewerten. Theoretisch verstehe ich, dass Vendor Lock-in bedeutet, dass man quasi an einen Anbieter "gekettet" ist, aber mir fehlt der Blick fürs Konkrete.

Bei meiner Fallstudie geht es um ein Unternehmen, das seine Anwendungen in eine bestimmte Cloud-Umgebung migriert hat. Ich soll jetzt einschätzen, wie stark die Architektur anbieterabhängig ist, aber ich weiß nicht genau, worauf ich im Text achten soll. Reicht es schon, wenn proprietäre Dienste wie bestimmte Datenbank- oder Storage-Lösungen des Anbieters genutzt werden? Oder zählt das erst als Lock-in, wenn zusätzlich noch anbieterspezifische APIs oder Automatisierungs-Tools im Spiel sind?

Mich interessiert auch, ob es da typische Kategorien gibt, nach denen man sowas bewertet - also sowas wie Datenmigration, Schnittstellen, vertragliche Bindung... Hat jemand von euch sowas schon mal in einer Fallstudie analysiert und kann mir sagen, worauf ich besonders achten sollte?

Hallo Markus, die Verwechslung kenne ich noch von meinem ersten Semester, das geht wirklich vielen so. Ich merke mir das immer über die Frage, die ich mir am Gateway stelle, nicht über die Symbole allein, auch wenn die natürlich auch helfen (XOR = Kreis mit X oder leerer Kreis, AND = Kreis mit Plus, OR = Kreis mit Kreis/O drin).

Meine Faustregel:

• XOR (exklusiv): "Entweder-oder" – genau ein Pfad wird genommen. Frage: Schließen sich die Bedingungen gegenseitig aus?
• AND (parallel): "Sowohl-als-auch" – alle ausgehenden Pfade werden immer gleichzeitig aktiviert, ohne Bedingung. Am Join-Gateway wartet der Prozess, bis wirklich alle Pfade abgeschlossen sind (Synchronisation).
• OR (inklusiv): "Mindestens einer, kann aber auch mehr sein" – hier hängt es von Bedingungen ab, wie viele Pfade aktiv werden, zwischen 1 und allen.

Zu deinem Bestellbeispiel: Rechnung und Lieferschein werden bei jeder Bestellung immer beide erstellt, ohne Bedingung – das spricht für AND. Die Sonderfreigabe kommt aber nur bei bestimmten Bestellungen (z.B. ab einem Schwellenwert) hinzu, das ist eine Bedingung. Deshalb würde ich hier ein OR-Gateway nehmen: Rechnung und Lieferschein laufen immer, die Sonderfreigabe optional zusätzlich. Wichtig beim Modellieren: zum passenden Split-Gateway muss später auch das gleiche Join-Gateway kommen, sonst wird das Zusammenführen der Pfade nicht sauber synchronisiert.

Wir sitzen gerade an unserem Semesterprojekt (kleine Webanwendung mit Datenbankanbindung) und haben uns ziemlich selbst ein Bein gestellt: Wir haben von Anfang an alle Testdaten direkt in die Datenbank gehauen, die am Ende auch produktiv laufen soll. Jetzt beim Deployment merken wir, dass sich Test-Datensätze und „echte“ Daten vermischen und wir nicht mehr sauber trennen können, was eigentlich gelöscht werden müsste.

Ich habe inzwischen verstanden, dass man eigentlich mindestens zwischen Dev-, Test- und Produktivumgebung trennen sollte, aber für ein Studienprojekt mit 4 Leuten kommt uns das nach kompletten separaten Serverumgebungen ziemlich übertrieben vor. Reicht es z. B., einfach mehrere Datenbanken (z. B. per Docker oder lokal) mit unterschiedlichen Connection-Strings anzulegen, oder braucht man dafür wirklich mehr Infrastruktur?

Wie macht ihr das in euren Projekten oder im Job, wenn der Rahmen klein ist? Gibt es eine pragmatische Mindestlösung, mit der man sich solche Probleme erspart, ohne dass der Setup-Aufwand den eigentlichen Projektinhalt sprengt?

Ich sitze gerade an meiner Projektarbeit und soll ein Lastenheft und ein Pflichtenheft erstellen. Theoretisch weiß ich, dass das Lastenheft vom Auftraggeber kommt und das Pflichtenheft die Antwort des Auftragnehmers ist, aber in der Praxis verschwimmt das bei mir total.

Mein Problem: Ich beschreibe im Lastenheft z. B. schon, dass eine bestimmte Datenbankstruktur gewünscht ist – aber ist das nicht eigentlich schon zu technisch für den Auftraggeber? Und im Pflichtenheft weiß ich nicht, wie detailliert ich werden muss. Reicht es, wenn ich dort beschreibe, wie die Anforderung technisch umgesetzt wird, oder muss ich da schon auf Ebene von Datenbankfeldern oder Schnittstellen runtergehen?

Habt ihr vielleicht eine Faustregel, an der man sich orientieren kann, wann etwas ins Lastenheft und wann ins Pflichtenheft gehört? Mir würde auch ein kleines Beispiel aus eurer Praxis oder einem Projekt helfen, um das Prinzip besser zu verstehen. Bin für jeden Denkanstoß dankbar 🙂

Hallo Jonas, kann deine Bauchschmerzen gut nachvollziehen, ging mir am Anfang ähnlich. Aus meiner Erfahrung: feste Lernzeiten unter der Woche sind besser als alles aufs Wochenende zu schieben, weil man sonst in Stresswochen genau diesen einen Lernblock verliert und dann gar nichts mehr passiert. Lieber kleine Einheiten, z. B. drei- bis viermal 45-60 Minuten abends, dafür regelmäßig.

Zur Organisation der Materialien hat sich bei mir ein ganz simples System bewährt:

• Pro Modul einen eigenen Ordner (digital und wenn nötig auch physisch), darin nach Kapiteln sortiert
• Eine zentrale Übersichtsdatei (Excel reicht völlig) mit Modulname, Prüfungstermin, Stand der Bearbeitung und offenen Fragen
• Zusammenfassungen direkt nach dem Durcharbeiten eines Kapitels schreiben, nicht erst kurz vor der Prüfung – das spart später enorm viel Zeit

Beim Wochenplan würde ich nicht zu starr planen, sondern mit Pufferzeiten arbeiten. Also nicht "Montag 20-21 Uhr Kapitel 3", sondern eher ein Wochenpensum festlegen (z. B. zwei Kapitel) und flexibel verteilen, wann es reinpasst. Das nimmt den Druck raus, wenn im Vertrieb mal wieder ein Kunde dazwischenfunkt.

Vorarbeiten in Woche eins lohnt sich übrigens schon, einfach weil man dann einen Puffer hat für die Wochen, in denen es im Job brennt. Nur nicht zu viele Module parallel anfangen, lieber eins nach dem anderen konzentriert durchziehen.

Hallo Daniel, dein Bauchgefühl trügt dich hier nicht. Ich würde die Entscheidung für euer Projekt über die klassischen Treiber für Microservices begründen, die in der Literatur (z. B. bei Fowler) genannt werden: unabhängige Skalierbarkeit einzelner Komponenten, getrennte Deployment-Zyklen, Teams, die parallel und eigenständig an Services arbeiten, und organisatorische Entkopplung nach Conway's Law. Wenn keiner dieser Punkte bei dir zutrifft, kannst du das in der Begründung auch genau so argumentieren: nicht "Microservices sind too much", sondern "die Voraussetzungen, unter denen Microservices ihren Mehrwert entfalten, liegen hier nicht vor".

Der modulare Monolith ist tatsächlich ein sehr guter Mittelweg für eine Projektarbeit, weil er dir erlaubt, fachliche Bereiche sauber per Modulgrenzen (z. B. getrennte Packages/Namespaces, klar definierte Schnittstellen zwischen den Modulen, eigene Datenhaltung pro Modul wenn gewünscht) zu trennen, ohne den Overhead von Netzwerkkommunikation, verteilten Transaktionen oder Service-Discovery. Das lässt sich auch didaktisch gut verkaufen: du zeigst, dass du die Prinzipien von Domain-Driven Design und lose Kopplung verstanden hast, aber auch, dass du die Architektur passend zum Kontext (Teamgröße, Projektumfang, Zeitrahmen) wählst statt blind dem Trend zu folgen. Genau diese Abwägung ist meist das, was in der Bewertung positiv auffällt, weil sie zeigt, dass du nicht nur Buzzwords anwenden, sondern Architekturentscheidungen begründen kannst.

Ich sitze gerade an einem Projekt, bei dem ich eine kleine Umfrage unter Kommilitonen mache (ca. 50-80 Teilnehmer, Google Forms oder ähnliches Tool). Jetzt frage ich mich, wie ich das sauber DSGVO-mäßig aufziehe, bevor ich den Link rausschicke.

Konkret hänge ich an folgenden Punkten:

• Brauche ich wirklich eine explizite schriftliche Einwilligung, oder reicht ein Hinweistext mit Opt-in-Checkbox am Anfang der Umfrage?
• Wenn ich von Anfang an nur anonyme Daten erhebe (also gar keine Namen, E-Mails oder IP-Adressen abfrage/speichere), falle ich dann überhaupt noch unter die DSGVO, oder ist das dann komplett raus aus dem Thema?
• Wie lange darf/soll ich die Rohdaten nach Abschluss des Projekts eigentlich aufbewahren? Reicht es, sie nach der Abgabe zu löschen, oder gibt es da eine Art Mindest- oder Höchstfrist, an die man sich halten sollte?

Hat jemand von euch sowas schon mal für ein Studienprojekt gemacht und kann sagen, worauf er im Nachhinein geachtet hätte? Vor allem die Frage, ob „anonym“ wirklich automatisch „unkritisch“ bedeutet, macht mich gerade unsicher.

Ich sitze gerade an einer Fallstudie, bei der wir zuerst ein ER-Diagramm und danach ein UML-Klassendiagramm für denselben Sachverhalt (Kunden, Bestellungen, Produkte) erstellen sollen. Am Ende kommt bei mir optisch fast dasselbe raus: Kästchen mit Attributen, Linien dazwischen, Kardinalitäten dran. Deswegen frage ich mich, wofür man sich überhaupt die Mühe macht, beides zu lernen.

Ich hab bisher verstanden, dass ER-Diagramme eher für die Datenmodellierung/Datenbankentwurf gedacht sind und UML-Klassendiagramme eher aus der Softwareentwicklung kommen, weil man da auch Methoden reinpacken kann. Aber ist das schon der ganze Unterschied, oder gibt es da noch was Grundsätzlicheres in der Denkweise dahinter?

Konkret hänge ich auch daran: Wann würde man in der Praxis wirklich beide Diagramme für dasselbe System brauchen, und wann reicht eins von beiden? Oder ist das eher eine akademische Übung, um beide Notationen mal gesehen zu haben?

Hallo zusammen, kann das aus der Wirtschaftsinformatik-Ecke nur bestätigen, Daniel hat das mit den Rubrics schon gut beschrieben. Bei uns läuft das ähnlich: Wartbarkeit ist ein eigenes Lernziel, kein netter Bonus. Das hat auch einen fachlichen Hintergrund, der über die reine Benotung hinausgeht.

In der Praxis arbeitet man so gut wie nie allein an Code, und selbst wenn doch, übernimmt irgendwann jemand anderes die Wartung, oder man selbst nach Monaten, wie ihr beide schon beschrieben habt. Deshalb wird Clean Code im Studium oft schon früh trainiert, obwohl die Projekte klein und einsam sind, damit man es sich gleich zur Gewohnheit macht statt es später mühsam umzulernen.

Zur Bewertung bei uns: Es gibt meistens Punkte für

• sprechende Bezeichner (Funktionsnamen sollen sagen, was sie tun, nicht wie)
• Single-Responsibility auf Funktionsebene, also eine Funktion macht genau eine Sache
• konsistente Formatierung und sinnvolle Modularisierung statt einer "God-Function"

Ein Merksatz, den ich mir gemerkt habe: Code wird viel öfter gelesen als geschrieben. Das rechtfertigt auch, beim Schreiben etwas mehr Zeit zu investieren. Typischer Anfängerfehler ist übrigens, Clean Code erst am Ende "drüberzubügeln" statt von Anfang an sauber zu strukturieren, das kostet am Ende mehr Zeit als es spart.

Danke euch beiden, das bringt für mich echt Struktur rein, vor allem der Punkt mit dem Teamlead-Denkfehler, Tobi. Ich hatte dazu letztes Semester im Praxisprojekt (Uni-intern, aber mit echtem Kunden) einen Fall, der genau in diese Richtung ging.

Bei uns gab es im Sprint eine Situation, wo zwei Entwickler sich nicht einig waren, wie eine Story technisch umzusetzen ist, und das hat sich dann als vermeintlicher Prioritätskonflikt im Daily entladen. Unser Scrum Master hat da bewusst nicht gesagt „macht's so", sondern hat vorgeschlagen, das Thema aus dem Daily rauszunehmen und in ein separates kurzes technisches Spike-Meeting zu packen. Der PO war dabei nur als Zuhörer anwesend, weil die fachliche Anforderung unstrittig war, es ging rein um den Lösungsweg.

Das fand ich im Nachhinein ein gutes Beispiel für die Grenze: Der Scrum Master hat erkannt, dass das eigentliche Problem ein Prozess-/Kommunikationsproblem war (zwei Lösungswege im Daily diskutieren funktioniert einfach nicht), und hat den Rahmen geschaffen, damit das Team selbst entscheidet. Hätte es aber um die Frage gehen, ob die Story überhaupt noch in diesem Sprint Sinn macht, wäre sofort der PO gefragt gewesen.

Mein Fazit aus der Erfahrung: Je klarer vorher getrennt ist, wer worüber entscheidet, desto seltener eskaliert sowas überhaupt erst im Daily.

Daniel, dein Gedankengang ist genau richtig und kein Trugschluss. Git ist ein Versionskontrollsystem, kein Backup-System, auch wenn beides oft verwechselt wird, weil Git ja mehrere Kopien der Historie erzeugt.

Der Unterschied liegt im Zweck: Versionskontrolle soll Änderungen nachvollziehbar machen und dir erlauben, zu früheren Ständen zurückzugehen. Ein Backup soll dich vor Datenverlust durch Hardware-Defekt, Diebstahl, Fehlbedienung oder eben Anbieter-Ausfall schützen. Die beiden Ziele überschneiden sich, sind aber nicht deckungsgleich.

Dein Szenario mit dem force-push ist ein gutes Beispiel: reflog hilft dir nur lokal und auch nur eine begrenzte Zeit (Standard ca. 90 Tage für erreichbare, 30 Tage für unerreichbare Commits, und auch das nur, wenn du die Garbage Collection nicht vorher laufen lässt). Wenn dein Remote-Repo weg ist und dein lokales Repo auch, bringt dir das reflog nichts mehr.

Als Merksatz nutze ich für mich: Versionskontrolle schützt vor dem eigenen Code-Chaos, Backup schützt vor dem Totalverlust. Beides macht unterschiedliche Jobs.

Ich mache es bei größeren Projekten so, dass ich zusätzlich zum Remote-Repo in regelmäßigen Abständen einen Clone oder zumindest ein Archiv des Repos auf einem unabhängigen Speicher ablege, der nicht an denselben Account/Anbieter gekoppelt ist. Das ist kein Mehraufwand, der sich nicht lohnt, gerade bei einer Abschlussarbeit oder einem prüfungsrelevanten Projekt würde ich das nicht dem Zufall überlassen.

Das Thema hatten wir letztes Semester im Modul zu Datenbanksystemen tatsächlich auch, aber eher theoretisch mit B-Baum-Struktur, ohne dass man ein Gefühl für die Praxis bekommt. Dein Problem ist genau der klassische Trade-off: jeder Index ist im Grunde eine zusätzliche, mitgepflegte Datenstruktur. Bei INSERT muss nicht nur die Tabelle selbst beschrieben werden, sondern auch jeder Index aktualisiert werden, bei UPDATE kommt es drauf an, ob sich die indizierten Spalten ändern. Je mehr Indizes, desto mehr Schreibaufwand pro Operation – das lässt sich nicht wegoptimieren, das ist einfach der Preis für schnelleres Lesen.

Eine feste Faustregel wie „maximal X Indizes“ gibt es meines Wissens nicht, weil es stark vom Verhältnis Lese- zu Schreiblast abhängt. Bei einer Tabelle, die hauptsächlich für Reports oder Auswertungen gelesen wird und selten verändert wird, können durchaus mehr Indizes sinnvoll sein. Bei einer Tabelle mit vielen Transaktionen (z. B. Bestellpositionen, Logs) sollte man sparsamer sein und wirklich nur die Spalten indizieren, die in Abfragen häufig in WHERE, JOIN oder ORDER BY vorkommen.

Praktisch würde ich vorgehen, indem man sich vorher die Query-Statistiken anschaut (welche Abfragen laufen am häufigsten, welche sind am teuersten) und erst danach gezielt indiziert, statt pauschal auf alle vermeintlich wichtigen Spalten. Viele Datenbanksysteme bieten dafür Execution-Pläne an, mit denen man sehen kann, ob ein Index überhaupt genutzt wird – das ist aus meiner Erfahrung der zuverlässigste Weg, statt nur zu raten.

Hallo zusammen,

ich sitze gerade über unserer Datenbank-Vorlesung und habe ein kleines Verständnisproblem, bei dem ich hoffe, dass ihr mir weiterhelfen könnt. Bei uns wurde ziemlich klar vermittelt: Normalisierung bis zur 3. Normalform ist der Standard, damit man Redundanzen und Anomalien beim Einfügen, Ändern und Löschen vermeidet. Soweit habe ich das auch verstanden und die Beispiele mit den Funktionalen Abhängigkeiten nachvollzogen.

Jetzt bin ich aber im Praktikum und sehe dort Tabellen, die ganz bewusst denormalisiert sind, also mit Redundanzen, die laut Theorie eigentlich vermieden werden sollten. Auf Nachfrage hieß es nur knapp „Performance“, aber so richtig greifen konnte ich das nicht.

Deswegen meine Frage an euch:

• In welchen konkreten Situationen lohnt sich Denormalisierung wirklich?
• Geht es dabei nur um Lesezugriffe bei großen Datenmengen oder gibt es noch andere Gründe?
• Und welche Nachteile muss man sich dafür einhandeln, außer dass Updates komplizierter werden?

Habt ihr vielleicht Beispiele aus der Praxis, an denen man das greifbarer machen kann?

Wir hatten das Thema gerade im Modul Projektmanagement/Prozesse und ich sitze mit meinen Unterlagen da und weiß theoretisch, dass der Product Owner für das „Was“ zuständig ist und der Scrum Master für das „Wie“ im Sinne von Prozessbegleitung. Aber sobald ich mir vorstelle, wie das im echten Projektalltag aussieht, wird es bei mir unscharf.

Konkret hänge ich an Fragen wie: Wer entscheidet eigentlich, wenn das Team mitten im Sprint merkt, dass eine Anforderung aus dem Product Backlog so nicht umsetzbar ist? Greift da der PO ein oder moderiert das der Scrum Master nur? Und wie ist das mit Priorisierungskonflikten im Team – ist das reine PO-Sache oder mischt der Scrum Master da auch inhaltlich mit?

In der Theorie klingt die Trennung sauber, aber ich kann mir schwer vorstellen, wie das im Daily oder Sprint Review tatsächlich abläuft, ohne dass sich die beiden Rollen ständig überschneiden. Hat jemand von euch das schon in einem echten Projekt (egal ob Praktikum, Werkstudentenjob oder im Job selbst) erlebt und kann mir erzählen, wo die Grenze in der Praxis wirklich verläuft?

Hallo Markus, das Problem kenne ich gut, mir ging es am Anfang genauso. Was mir geholfen hat: nicht die Kreise auswendig lernen, sondern immer an ein konkretes Beispiel denken, dann merkt man sich die Logik statt die Definition.

Stell dir zwei Tabellen vor: Kunden (KundenID, Name) und Bestellungen (BestellID, KundenID, Betrag). Nicht jeder Kunde hat eine Bestellung, und theoretisch könnte es auch eine Bestellung mit einer KundenID geben, die es in der Kundentabelle nicht mehr gibt (kommt in sauberen DBs mit Fremdschlüsseln zwar nicht vor, aber zur Veranschaulichung reicht's).

• Inner Join: nur Kunden, die auch wirklich bestellt haben. Die Schnittmenge der beiden Kreise, alles außen rum fällt weg.
• Left Join: alle Kunden bleiben erhalten, egal ob sie bestellt haben oder nicht. Wer nichts bestellt hat, bekommt bei den Bestell-Spalten einfach NULL. Merksatz: "Links steht die Tabelle, die komplett bleibt."
• Right Join: genau umgekehrt, alle Bestellungen bleiben, auch wenn (rein hypothetisch) der Kunde dazu fehlt. In der Praxis nutze ich Right Join kaum, weil man das meist einfach als Left Join mit vertauschter Tabellenreihenfolge schreiben kann, das ist übersichtlicher.
• Full Join: beide Kreise komplett, also alle Kunden und alle Bestellungen, mit NULLs auf der jeweils fehlenden Seite. Der Unterschied zum Cross Join: Cross Join kombiniert jede Zeile mit jeder, ganz ohne Bedingung, das hat mit den Venn-Kreisen gar nichts zu tun.

Eselsbrücke, die bei mir hängen geblieben ist: "Left/Right sagt, wessen Tabelle komplett bleibt, nicht wo die NULLs auftauchen." Die NULLs stehen ja auf der jeweils anderen Seite.

Ich sitze gerade an meiner Fallstudie und muss ein IT-Projekt planen und begründen, warum ich mich für ein bestimmtes Vorgehensmodell entscheide. Die Theorie zu Scrum und Wasserfall habe ich soweit verstanden, also Phasenmodell vs. iteratives Vorgehen, Sprints, Rollen wie Product Owner usw. Aber an der Stelle, wo ich das konkret auf mein Projektbeispiel anwenden soll, hänge ich total.

Mein Fallbeispiel ist die Einführung eines neuen internen Systems für die Auftragsverwaltung in einem mittelständischen Unternehmen. Die Anforderungen scheinen mir eigentlich relativ klar zu sein, zumindest auf den ersten Blick, aber ich könnte mir vorstellen, dass sich im Laufe des Projekts noch Dinge ändern, weil verschiedene Abteilungen involviert sind.

Meine Frage: Gibt es sowas wie handfeste Kriterien oder Fragen, die man sich stellen sollte, um zu entscheiden, ob Scrum oder Wasserfall passender ist? Also nicht nur "Scrum ist agil und flexibel", sondern konkret bezogen auf Faktoren wie Stakeholder-Anzahl, Unsicherheit der Anforderungen oder Unternehmenskultur? Wie würdet ihr sowas in einer Hausarbeit begründen, ohne dass es zu oberflächlich wirkt?

Hi,

in Algorithmen und Datenstrukturen sind wir jetzt bei der Laufzeitanalyse. Ich kann die Liste auswendig (O(1), O(log n), O(n), O(n log n), O(n²)), aber ehrlich gesagt verstehe ich nicht, warum man sich darüber so aufregt. Computer sind doch schnell?

Und in der Übung sollen wir bei Code-Schnipseln die Komplexität bestimmen. Bei einer Schleife ist klar O(n), aber sobald Funktionen aufgerufen werden oder die Schleife „halbiert“, bin ich raus. Gibt es da ein System, oder muss man das einfach sehen? 😅

Aus meinem eigenen Gruppenprojekt letztes Semester noch der organisatorische Teil, der bei uns mehr gebracht hat als jeder Git-Befehl:

• Aufgaben so schneiden, dass sich Dateien wenig überschneiden. Wenn zwei Leute gleichzeitig dieselbe zentrale Datei umbauen, hilft auch der beste Workflow nicht. Kurze Absprache im Board („ich fasse gerade die Routing-Datei an“) spart viel Ärger.
• Ein kleines Kanban-Board (reicht schon das in GitHub/GitLab eingebaute) mit einer Karte pro Branch. Dann sieht jeder, was gerade offen ist.
• Eine .gitignore von Anfang an, damit keine IDE-Ordner, Build-Ergebnisse oder lokale Konfigdateien im Repo landen – die erzeugen sonst ständig sinnlose Konflikte.
• Kurz vor der Abgabe keine großen Umbauten mehr, nur noch Bugfixes.

Und falls ihr das in der Dokumentation beschreiben müsst: Genau diese Begründungen („warum Feature-Branches, warum geschützter main, warum Review“) wollen die Prüfer meistens lesen, nicht die Befehle. 👍

Hi, kurze Verständnisfrage aus dem IT-Infrastruktur-Modul.

Virtualisierung und Container wurden bei uns in derselben Sitzung behandelt, mit dem Fazit „beides trennt Anwendungen voneinander“. Im Praktikum sollten wir dann eine kleine Webanwendung einmal in einer VM und einmal als Container bereitstellen – und da war der Unterschied ziemlich deutlich: Die VM hat gefühlt ewig gebootet und rund 8 GB belegt, der Container war in zwei Sekunden da und ein paar hundert MB groß.

Jetzt frage ich mich:

• Was ist der technische Unterschied, wenn doch beides „virtualisiert“?
• Warum ist ein Container so viel kleiner und schneller – was fehlt ihm?
• Und wann nimmt man in der Praxis was? Wenn Container in allem besser wären, gäbe es ja keine VMs mehr.

Die Klausurfrage wird vermutlich „Vergleichen und beurteilen Sie“ lauten, und da will ich nicht nur „Container ist leichter“ hinschreiben. 😅

Daniel hat die Klausurantwort komplett, ich ergänze den Punkt, bei dem viele Skripte (und leider auch manche echte Software) stehen bleiben: SHA-256 allein ist für Passwörter trotzdem keine gute Wahl.

Der Grund: SHA-256 ist darauf optimiert, schnell zu sein – super für Prüfsummen und Signaturen, schlecht für Passwörter. Wer eine gestohlene Datenbank hat, probiert einfach Wörterbücher und Varianten durch, und auf einer einzigen Grafikkarte sind das Milliarden Versuche pro Sekunde. Das Salt verhindert zwar vorberechnete Tabellen, aber nicht das gezielte Durchprobieren eines einzelnen Kontos.

Deshalb nutzt man für Passwörter absichtlich langsame Verfahren:

• bcrypt – mit einstellbarem Kostenfaktor
• PBKDF2 – viele tausend Iterationen einer Hashfunktion
• scrypt und Argon2 – zusätzlich speicherintensiv, was massenhaftes Parallelrechnen auf Grafikkarten teuer macht. Argon2 hat 2015 die Password Hashing Competition gewonnen und gilt heute als Empfehlung.

Für den Nutzer fällt eine Viertelsekunde beim Login nicht auf. Für einen Angreifer, der Milliarden Kandidaten testen will, ist das der Unterschied zwischen Stunden und Jahrhunderten. Alte Verfahren wie MD5 oder SHA-1 gelten für diesen Zweck als unsicher.

Mein Merksatz für die Klausur:

Verschlüsselung schützt Daten, die man wieder lesen muss. Hashing schützt Daten, die man nur prüfen muss.

Und als Grenze, falls „beurteilen“ gefragt ist: Kein Hashverfahren rettet ein schwaches Passwort wie „123456“ – das steht in jedem Wörterbuch ganz oben. Deshalb gehören Passwortrichtlinien und Zwei-Faktor-Authentifizierung in eine vollständige Antwort zur Zugangssicherheit dazu. Einordnung in die Schutzziele: Hashing unterstützt vor allem Integrität und schützt bei Passwörtern indirekt die Vertraulichkeit der Konten.