In dieser Episode von software-architektur.tv sprechen Jonas Clusen und Hansjörg Gude mit Eberhard Wolff über soziotechnische Architektur-Reviews (STAR). Der Ansatz erweitert klassische Reviews um die organisatorische Perspektive. Das Ergebnis des Reviews zeigt, wie Teams, Kommunikation und Strukturen die Architektur beeinflussen.

Im Unterschied zum klassischen Ansatz liegt STAR ein kollaborativer Prozess zugrunde, der dazu beitragen soll, die Architektur so zu gestalten, dass sie mit der Organisation mitwachsen kann. So sollen beispielsweise Ursachen für Reibungsverluste in der Zusammenarbeit von Teams möglichst frühzeitig erkannt werden, um diesen entgegensteuern zu können.

Gemeinsam diskutieren Clusen, Gude und Wolff, wie STAR hilft, technische und soziale Spannungsfelder zu erkennen und daraus konkrete, wirksame Verbesserungen für Systeme und Organisationen abzuleiten – und wie durch den Ansatz Organisationen auch schon nachweisbar verbessert worden sind.

Jonas Clusen und Hansjörg Gude sind Gründer und Geschäftsführer von SWAGLab. Beide bringen jahrelange Erfahrung aus fachlich-technischen und leitenden Rollen in verschiedenen Bereichen der IT und Digitalisierung mit.

Livestream am 6. Februar

Die Ausstrahlung findet am Freitag, 6. Februar 2026, live ab 13 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zu den Folgen finden sich auf der Videocast-Seite.

(map)

Microsoft hat mit LiteBox sein neues Library OS fürs Sandboxing von Linux-Anwendungen vorgestellt. Das unter MIT-Lizenz veröffentlichte Open-Source-Projekt nutzt Rust als Programmiersprache und zielt darauf ab, durch stark reduzierte Schnittstellen zum Host-System die Angriffsfläche erheblich zu minimieren.

LiteBox unterscheidet sich von traditionellen Sandboxing-Ansätzen durch seinen Library-OS-Ansatz. Während klassische virtuelle Maschinen einen vollständigen Kernel mitbringen und Container den Kernel mit dem Host-System teilen, setzt LiteBox auf eine modulare Architektur mit sogenannten North- und South-Interfaces. Das North-Interface orientiert sich an nix und rustix und bietet POSIX-ähnliche Systemaufrufe in Rust. Das South-Interface verbindet verschiedene Host-Plattformen mit dem Library OS. LiteBox wurde dabei sowohl für die Ausführung im Kernel- als auch im Non-Kernel-Modus konzipiert.

Unterstützung für Confidential Computing

Die Architektur ermöglicht es, unmodifizierte Linux-Programme unter Windows auszuführen, Linux-Anwendungen auf Linux-Systemen in einer Sandbox einzusetzen oder Programme auf AMD SEV SNP (Secure Encrypted Virtualization Secure Nested Paging) laufen zu lassen. Auch die Integration von OP-TEE (Open Portable Trusted Execution Environment) auf Linux-Systemen unterstützt LiteBox. Damit eignet sich das Projekt primär für Confidential-Computing-Szenarien in Cloudumgebungen. Ein typisches Einsatzgebiet wäre beispielsweise das Ausführen von Anwendercode in einer Multi-Tenant-Cloud-Umgebung, bei der maximale Isolation zwischen verschiedenen Workloads erforderlich ist.

Die Entscheidung für Rust als Implementierungssprache folgt dem Trend zu mehr Speichersicherheit in systemnaher Software. Rust eliminiert ganze Klassen von Sicherheitslücken wie Buffer Overflows durch sein Ownership-Modell, ohne dabei auf Garbage Collection angewiesen zu sein. Microsoft setzt bereits bei der Treiberentwicklung auf Rust und hat mit Edit letztes Jahr einen neuen Open-Source-Editor für die Kommandozeile vorgestellt, der komplett in Rust geschrieben ist. Zum Jahresende 2025 musste Microsoft sogar das Gerücht einfangen, dass sämtlicher C/C++-Code bis 2030 auf Rust umgestellt werden solle.

Noch experimentelles Stadium

Interessierte Nutzer sollten beachten, dass sich LiteBox noch in aktiver Entwicklung befindet. Die APIs und Interfaces können sich noch ändern, ein stabiles Release liegt nicht vor. Microsoft empfiehlt auf GitHub daher, für den produktiven Einsatz auf eine stabile Version zu warten oder entsprechende Anpassungen einzuplanen. Das Projekt richtet sich aktuell vor allem an Entwickler, die mit neuen Sandboxing-Konzepten experimentieren möchten.

Im Vergleich zu Alternativen wie gVisor von Google, das Systemaufrufe im User-Space abfängt, oder Firecracker von Amazon, das auf Rust-basierten Micro-VMs setzt, verspricht LiteBox durch seine Library-OS-Architektur einen besonders geringen Overhead. Konkrete Performance-Benchmarks liegen allerdings noch nicht vor. Auch Kata Containers, das VMs für Kubernetes bereitstellt, adressiert ähnliche Anwendungsfälle, setzt aber auf eine andere technische Basis.

Offiziell unterstützt LiteBox derzeit AMD SEV SNP als Hardware-Plattform sowie Linux und Windows als Host-Betriebssysteme. Ob Microsoft plant, LiteBox in Azure oder das Windows Subsystem for Linux zu integrieren, ist nicht bekannt.

(fo)

Mit Git 2.53 steht eine neue Version des verteilten Versionsverwaltungssystems bereit. Der Fokus liegt vor allem auf Verbesserungen beim Umgang mit großen Repositorys sowie auf Überarbeitungen an bestehenden Werkzeugen.

Geometrisches Repacking und Partial Clones

Git 2.53 behebt eine lange bestehende Einschränkung beim sogenannten geometrischen Repacking. Dabei organisiert Git Objekte nicht in einer einzigen großen Packdatei, sondern verteilt sie auf mehrere Packfiles unterschiedlicher Größe. Ziel ist es, Repacking‑Vorgänge zu beschleunigen, insbesondere in großen Repositories, in denen das vollständige Neuverpacken aller Objekte viel Zeit in Anspruch nehmen kann.

Bislang war diese Strategie nicht mit Partial Clones kompatibel – also mit Repository‑Kopien, bei denen Git zunächst nur einen Teil der Daten herunterlädt und fehlende Inhalte später bei Bedarf nachlädt. Solche Repositories enthalten sogenannte Promisor‑Packfiles, die auf noch nicht vorhandene Objekte verweisen. Git 2.53 behandelt diese Packfiles nun separat und erhält ihre Kennzeichnung auch beim geometrischen Repacking. Damit lässt sich die effizientere Repacking‑Strategie erstmals auch in Partial‑Clone‑Umgebungen einsetzen.

Feinerer Umgang mit Signaturen in git-fast-import

Git 2.53 erweitert das Werkzeug git-fast-import, das Entwicklerinnen und Entwickler vor allem für den schnellen Import großer Datenmengen und zum Umschreiben von Repository‑Historien nutzen. Solche Massenänderungen kommen etwa beim Einsatz von Werkzeugen wie git‑filter‑repo zum Einsatz, die gezielt Teile der Commit‑Historie verändern.

Neu ist ein zusätzlicher Modus für den Umgang mit kryptografischen Signaturen. Bisher konnte git-fast-import Signaturen mit der Option --signed-commits= nur vollständig beibehalten oder vollständig entfernen. Sobald Entwickler nur einen Teil der Historie umschrieben, verloren zwar die betroffenen Commits ihre Signaturgültigkeit, Git entfernte laut Blogbeitrag von GitLab jedoch auch die weiterhin gültigen Signaturen unveränderter Commits. Mit Git 2.53 führt git-fast-import den neuen Modus strip-if-invalid ein. Er entfernt Signaturen nur dann, wenn sie durch eine Umschreibung tatsächlich ungültig werden, und erhält gültige Signaturen unveränderter Commits. Damit schafft Git eine wichtige Voraussetzung, um Signaturen bei der automatisierten Historienbearbeitung gezielt zu bewahren.

Erweiterte Analysefunktionen für Repository-Strukturen

Seit Git 2.52 liefert das Unterkommando git repo structure Einblicke in den Aufbau eines Repositorys. In Git 2.53 baut das Projekt diese Analysefunktion weiter aus und ergänzt zusätzliche Kennzahlen, mit denen sich große Repositorys genauer untersuchen lassen.

Das Kommando ermittelt auch die Gesamtgröße erreichbarer Objekte. Git weist dabei sowohl die unkomprimierte Größe als auch den tatsächlichen Speicherbedarf auf dem Datenträger aus und gliedert die Werte nach Objekttypen.

$ git repo structure

| Repository structure | Value      |
| -------------------- | ---------- |
| * References         |            |
|   * Count            |   1.78 k   |
|     * Branches       |      5     |
|     * Tags           |   1.03 k   |
|     * Remotes        |    749     |
|     * Others         |      0     |
|                      |            |
| * Reachable objects  |            |
|   * Count            | 421.37 k   |
|     * Commits        |  88.03 k   |
|     * Trees          | 169.95 k   |
|     * Blobs          | 162.40 k   |
|     * Tags           |    994     |
|   * Inflated size    |   7.61 GiB |
|     * Commits        |  60.95 MiB |
|     * Trees          |   2.44 GiB |
|     * Blobs          |   5.11 GiB |
|     * Tags           | 731.73 KiB |
|   * Disk size        | 301.50 MiB |
|     * Commits        |  33.57 MiB |
|     * Trees          |  77.92 MiB |
|     * Blobs          | 189.44 MiB |
|     * Tags           | 578.13 KiB |

Die erweiterten Ausgaben sollen helfen, Größe und potenzielle Performance-Eigenschaften eines Repositorys besser einzuschätzen – insbesondere bei sehr umfangreichen Codebasen.

(mdo)