Künstliche Intelligenz
39C3: Wenn Moleküle zu kryptografischen Funktionen werden
DNA gilt gemeinhin als Bauplan des Lebens. Auf dem 39. Chaos Communication Congress löste die Chemikerin Anne Lüscher das Molekül jedoch konsequent aus diesem biologischen Kontext und betrachtete es als das, was es aus informationstechnischer Sicht ebenfalls ist: ein extrem dichter, stabiler und überraschend gut beherrschbarer Informationsträger. In ihrem Vortrag „Chaos Communication Chemistry: DNA security systems based on molecular randomness“ zeigte sie, warum sich ausgerechnet synthetische DNA für Datenspeicherung und Sicherheitsarchitekturen eignet – und warum RNA dabei kaum eine Rolle spielt.
Weiterlesen nach der Anzeige
Warum DNA als Informationsträger taugt
Aus digitaler Perspektive sei DNA leicht zu lesen, so Lüscher: Vier Basen, klare Paarungsregeln, sequenzielle Speicherung. „Genau wie bei digitaler Information speichert DNA Daten in einer Sequenz, und im Grunde müssen wir nur zwischen Basis zwei und Basis vier übersetzen. Wir können einfach zwei Bits pro Base zuweisen und so zwischen digitaler oder binärer Information und DNA hin- und herübersetzen.“
Entscheidender seien jedoch die physikalischen Eigenschaften. DNA als Speichermedium vereint enorme Informationsdichte mit Langzeitstabilität – unter geeigneten Bedingungen über Zeiträume, die heutige Speichermedien weit übersteigen. Dass sich das Genom eines etwa 700.000 Jahre alten Pferdeknochens noch auslesen ließ, sei weniger biologische Kuriosität als technisches Argument. Im Labor ließen sich diese Bedingungen künstlich erzeugen, etwa durch Einkapselung in winzige Glaskügelchen.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmung wird hier ein externer Inhalt geladen.
Hinzu komme ein Aspekt, der in der Informatik zunehmend an Bedeutung gewinne: Parallelität. Molekulare Systeme arbeiteten nicht sequenziell, sondern massiv parallel. „Denn wenn man an einen winzigen Wassertropfen denkt – da sind so viele Moleküle drin, und im Fall von DNA kann jedes dieser Moleküle potenziell sein eigener Prozessor sein, der Berechnungen eigenständig durchführt, gleichzeitig und unabhängig von den anderen. Und das eröffnet Möglichkeiten für parallele Operationen, die mit traditioneller Computertechnik so nicht möglich sind.“
Die Frage nach RNA drängt sich auf, nicht zuletzt durch ihre prominente Rolle in der Medizin. In der Fragerunde erläuterte Lüscher, warum technisch klare Gründe dagegen sprechen: RNA sei einzelsträngig und chemisch instabil. Eine zusätzliche Hydroxylgruppe mache sie besonders anfällig für Hydrolyse. Für Anwendungen, bei denen Daten über lange Zeiträume erhalten bleiben sollen, sei das ungeeignet. DNA dagegen sei doppelsträngig, robust und von einem über Jahrzehnte gewachsenen Werkzeug-Ökosystem begleitet: Synthese, PCR, Sequenzierung und gezielte Manipulation seien etabliert und zuverlässig verfügbar. Bei anderen Biomolekülen wie Proteinen fehlten diese direkten Werkzeuge weitgehend – ein Protein lasse sich etwa nicht direkt von einem anderen Protein kopieren.
Weiterlesen nach der Anzeige
Auch große Akteure wie Microsoft und Seagate hätten inzwischen eigene Teams für DNA-Datenspeicherung aufgebaut, berichtete Lüscher. Fortschritte bei Random Access, Fehlerkorrektur und optimierter Kodierung durch epigenetische Methoden seien erzielt worden. Dennoch befänden sich die meisten realisierten Projekte bisher eher im Bereich Kunst und PR – etwa die Speicherung von Musik der Band Massive Attack in DNA, die dann in Sprühfarbe für ein Albumcover gemischt wurde.
Zufälligkeit als kryptografische Ressource
Besonders interessant werde DNA dort, wo Zufälligkeit ins Spiel komme, erklärte Lüscher. „In einer einzigen Reaktion können wir durch die Kombination der vier Basen riesige Mengen an Zufälligkeit in einer einzigen Reaktionsumgebung erzeugen. Und hier sehen Sie einige Zahlen. Wir können hunderte Petabytes an Zufälligkeit für unter 100 Euro erzeugen.“ Diese Zufälligkeit sei praktisch nicht rekonstruierbar, weder algorithmisch noch durch erneute Synthese. Darauf aufbauend ließen sich sogenannte chemische Unclonable Functions (CUFs) realisieren: zufällige DNA‑Pools, die zwar nicht vollständig bekannt oder kopierbar seien, sich aber gezielt „abfragen“ ließen.
Das Prinzip funktioniere über PCR mit definierten Primern, so Lüscher. Diese Primer suchten im Pool nach passenden Sequenzen, bänden dort und kopierten den dazwischenliegenden Abschnitt. Das Ergebnis sei spezifisch für die Kombination aus Pool und Primer‑Paar – reproduzierbar, aber nicht vorhersagbar oder umkehrbar. Ähnlich wie bei physikalischen Unclonable Functions (PUFs) entstehe so ein System, das sich wie eine kryptografische Hashfunktion verhalte, aber auf chemischer statt mathematischer Grundlage basiere.
Im Unterschied zu klassischen PUFs seien diese Systeme nicht an ein einzelnes physisches Objekt gebunden, betonte Lüscher. Durch chemische Verfahren ließen sich identische Kopien der zufälligen Pools herstellen, ohne deren genaue Zusammensetzung zu kennen. Anschließend könnten diese Kopien „verriegelt“ werden, sodass sie sich nicht mehr weiter vervielfältigen ließen. Damit werde die Anzahl möglicher Abfragen im Voraus definiert, und mehrere Nutzer könnten denselben Pool für dezentrale Anwendungen verwenden – etwa zur gegenseitigen Authentifizierung oder zur gemeinsamen Schlüsselgenerierung.
Anwendungen: Von Kunstwerken bis Medikamenten
DNA lasse sich zudem in Materialien integrieren, erläuterte Lüscher. In Farben, Kunststoffe oder 3D‑Druckfilamente eingebettet, ermögliche sie objektgebundene Metadaten mit extrem langer Haltbarkeit. Ein Forschungsprojekt habe etwa eine STL‑Druckdatei in DNA gespeichert, diese in das Druckfilament integriert und daraus einen Kunststoffhasen hergestellt. Aus einem winzigen Stück des Ohrs habe sich die DNA extrahieren und der Hase erneut drucken lassen. „Und es hat auch einige praktische Anwendungen. Denn wenn man an Objekte mit einer sehr langen Lebensdauer denkt, wie Gebäude oder öffentliche Infrastruktur, kann es wirklich schwierig sein, die Daten und Metadaten zu diesen Objekten über einen längeren Zeitraum zu erhalten. Und auf diese Weise könnten wir das lösen, indem wir diese Information einfach direkt in die Baumaterialien integrieren.“
Konkrete Anwendungen für CUFs reichten von der Authentifizierung von Kunstwerken bis zum Fälschungsschutz von Medikamenten. Ein winziger Materialchip genüge, um eine eindeutige chemische Signatur auszulesen und mit einer Referenz abzugleichen. Da die Pools weder vollständig sequenzierbar noch synthetisch reproduzierbar seien, wäre ein Angriff extrem aufwendig: Die chemische Modifikation verhindere die übliche Sequenzier‑Vorbereitung, und selbst bei erfolgreicher Sequenzierung würde die gezielte Neusynthese aller Sequenzen Milliarden kosten.
Trotz des Potenzials blieb Lüschers Blick realistisch. „Aber für diese Operationen, also eine einzelne Challenge-Response pro Durchgang, dauert es im Moment ein paar Stunden, und dann müssen wir die Ergebnisse sequenzieren, was wieder ein paar Stunden dauert. Wenn man also ein Medikament authentifizieren will, müsste man im Grunde einen Tag warten. Das ist der Stand im Moment.“
Lesen Sie auch
Der eigentliche Wert liegt laut Anne Lüscher in der Perspektive: Chemie als Informationswissenschaft zu denken und physische Systeme mit einem digitalen Blick zu betrachten. DNA werde dabei nicht als Ersatz für Silizium präsentiert, sondern als Ergänzung – dort, wo Haltbarkeit, Dichte, Zufälligkeit und physische Nicht‑Klonbarkeit entscheidend seien. Das Feld brauche Expertise aus verschiedenen Disziplinen: Menschen mit Laborerfahrung ebenso wie solche mit Hacker‑Mindset, die bereit seien, diese Herausforderungen anzugehen.
(vza)
Künstliche Intelligenz
Von Legacy-Monolithen zu Self-contained Systems
Legacy-System – kaum ein anderer Begriff schürt mehr Abneigung und Furcht im Herzen von Softwareentwicklerinnen und -entwicklern. Was einmal als flexible und einfache Anwendung begann, wuchs über die Jahre zu einem unüberschaubaren Monolithen heran, der sich nur noch unter größtem Aufwand weiterentwickeln, testen und deployen lässt.
Weiterlesen nach der Anzeige
Johannes Seitz ist als Softwarearchitekt und Trainer mit dem Schwerpunkt Domain-driven Design und Softwaremodernisierung bei INNOQ tätig.
Eine solche Anwendung ist ein typisches Beispiel für ein schlecht oder gar nicht modularisiertes System, bei dem eine Anpassung an einer Stelle weitere an anderen Stellen nach sich zieht. Architektinnen und Architekten sprechen von starker Kopplung. Sind alle Funktionen in einen großen, unstrukturierten Block Code gegossen, ist der Kopplungseffekt auch innerhalb dessen zu beobachten. Anpassungen können dann zu einem Fehlverhalten an einer unerwarteten, anderen Stelle führen.
Zerlegt man den Monolithen in lose gekoppelte Module, haben lokale Änderungen keine Anpassungen in anderen Systemen mehr zur Folge. Werden diese Module in Form von autonomen, aber miteinander integrierten Systemen umgesetzt, erhält man zusätzlich den Vorteil, dass sie weitgehend unabhängig voneinander deployt werden können. Dieser Ansatz ist der bekannte Microservices-Architekturstil [1], dem viele Architektinnen und Architekten allerdings inzwischen mit Skepsis gegenüberstehen, da die Komplexität schnell wächst.
Daneben gibt es noch einen einfacheren Ansatz, der ähnliche und noch weitere Vorteile verspricht: Self-contained Systems (SCS).
Was sind Self-contained Systems?
Die Self-contained-Systems-Architektur legt großen Wert auf eine hohe Unabhängigkeit verschiedener Module. Diese lose gekoppelte Systemarchitektur (siehe Textbox unten „Kleine Bausteine, lose verbunden“) verspricht, dass Teams einzelne Teile weitgehend unabhängig entwickeln und deployen. Während die relativ vage Definition eines Microservice als „unabhängig deploybarer Service, modelliert um eine fachliche Domäne“ [1] große Freiräume bei der Wahl des Architekturstils lässt, sind die Kriterien für Self-contained Systems klarer umrissen.
Weiterlesen nach der Anzeige
Eine starke Kopplung kann viele Formen annehmen, von eher technischen wie „Ich muss genau wissen, auf welcher IP dieser Dienst läuft“ oder „Jedes Mal, wenn ein Feld dazukommt, muss ich überall die Deserialisierungslogik updaten“ bis hin zu einer sehr subtilen Art der Kopplung: „Wenn ich fachlich an System A etwas ändere, muss auch zwangsweise System B angepasst werden“.
Zum Bau weitgehend unabhängiger Systeme ist vor allem die zuletzt genannte Form hinderlich. Es ist deshalb nicht nur notwendig, die technischen Implementierungsdetails zu abstrahieren, um so wenig Artefakte der Infrastruktur (Datenbank, Frontend und weitere) wie möglich zwischen Systemen zu teilen. Vielmehr müssen Schnittstellen zwischen Systemen gebildet werden, die möglichst viele der fachlichen Implementierungsdetails verstecken. Diese Empfehlung ist nicht neu, sondern geht auf die Arbeit von David Parnas in den 70er-Jahren zurück [2].
Um die fachlich abstrahierten Schnittstellen zu finden, bedienen sich Architektinnen und Architekten gerne aus dem Repertoire des strategischen Domain-driven Design [3]. Eine Faustregel für Self-contained Systems ist, dass jedes System idealerweise einen Bounded Context umsetzt, also einen abgeschlossenen Bereich mit einer einheitlichen, aus der Fachdomäne stammenden Sprachgebung.
Wie Microservices sind sie mit einer streng gezogenen fachlichen Grenze versehen, häufig handelt es sich dabei jedoch um einen kompletten Bounded Context – also einen abgeschlossenen Bereich mit einer einheitlichen, aus der Fachdomäne stammenden Sprachgebung – im Sinne des strategischen Domain-driven Design (DDD). Dadurch sind sie tendenziell größer als Microservices, sodass weniger Aufwand für Integration und Infrastruktur anfällt.
Zudem gibt es für SCS eine Reihe an Best Practices zur Systemintegration. SCS sollen bevorzugt auf Nachrichten nach dem Credo „fire and forget“ setzen und nach dem Versenden nicht auf Antwort warten. Synchrone Request-Response-Kommunikation (zum Beispiel über RESTful-Services) sollte vermieden werden. Dann entsteht ein System, das bei Teilausfällen sehr resilient reagiert.
Die Nutzeroberfläche wird stets als ein Teil des Self-contained System behandelt (eine Idee, die im Rahmen der Micro Frontends ebenfalls in der Microservices-Welt Fuß gefasst hat). In erster Linie bleibt hierdurch mehr Arbeit innerhalb eines Teams und es entstehen keine Frontend-Monolithen als Flaschenhälse. Ein weiterer, oft überraschender Effekt ist, dass sich in vielen Fällen ein Austausch von Datenstrukturen zwischen UIs und die dadurch entstehende fachliche Kopplung über geteilte Datenformate komplett vermeiden lässt. Entwickler können stattdessen Teile der Nutzeroberflächen des einen Systems in einem anderen verwenden.
Damit die unabhängige Entwicklung der verschiedenen SCS nicht in einem unterschiedlichen Look and Feel oder einem Wildwuchs von Integrationsansätzen endet, fordert die SCS-Architektur von allen Systemen, sich an eine gemeinsame, koordinierte Makroarchitektur zu halten. Dazu gehören beispielsweise die Verwendung bestimmter Integrationstechniken, UI-Komponenten oder Styleguides. Sie ermöglichen ein weitgehend reibungsloses Zusammenspiel im System of Systems.
Gerade die Best Practices zur Systemintegration eröffnen Migrationspfade, um eine gewachsene Architektur in kleinen, inkrementellen Schritten zu einer SCS-Architektur umzubauen. Eine Umstellung nach dem Big-Bang-Muster ist nach Erfahrung des Autors nur in seltenen Fällen empfehlenswert oder wirtschaftlich.
(Bild: RONY/Adobe Stock)
Die Online-Konferenz betterCode() Modern Architecture von iX und dpunkt.verlag am 25. März 2026 stellt aktuelle Konzepte der Softwarearchitektur vor wie Clean Architecture, Hexagonale Architektur oder Microservices. Design mit LLMs ist ebenso ein Thema wie Architektur für eine digitale Souveränität.
Planung der Migration
Der erste Schritt vom Monolithen zu SCS ist es, die Teilstücke zu identifizieren, die sich in ein eigenes SCS überführen lassen. Da die Zielarchitektur aus fachlich geschnittenen Systemen besteht, ist die im Monolithen enthaltene Fachlichkeit genauer zu analysieren. Diesen Schritt sollten Entwicklerinnen und Entwickler nicht auf die leichte Schulter nehmen, da sich bei der Aufteilung der Applikation in ihre verschiedenen Bausteine entscheidet, wie stark oder lose diese gekoppelt sind (siehe Textbox oben „Kleine Bausteine, lose verbunden“).
Eine Möglichkeit, eine Analyse der Fachdomänen durchzuführen, ist das Event Storming zur Identifikation der Bounded Contexts. Abbildung 1 zeigt das Ergebnis einer solchen Analyse für eine fiktive Car-Sharing-Anwendung. Dort wurden die fachlichen Domänen „Nutzerregistrierung“, „Fuhrparkmanagement“, „Trips“, „Abrechnung“ und „Kundendienst“ identifiziert. Bei der Analyse entstehen bereits erste Ideen, wie die verschiedenen Fachlichkeiten miteinander interagieren und welche Nachrichten sie miteinander austauschen.
Das Ergebnis der fachlichen Analyse dient dazu, sinnvolle Schnittstellen für den Legacy-Monolith zu finden (Abb. 1).
Hat sich im Dialog mit den Fachabteilungen eine Aufteilung gefunden, die die gewünschte fachliche, lose Kopplung widerspiegelt, beginnen Architektinnen und Architekten damit, Teile des Altsystems nach und nach durch neue SCS zu ersetzen. Diese arbeiten mit dem Altsystem zusammen, ohne dass Nutzer einen Unterschied feststellen. Das ist eine Herangehensweise, die auch Strangler Fig Application heißt, da eine neue Anwendung wie die namensgebende Würgefeige langsam aber sicher immer größere Teile des alten Wirtssystems überdeckt und es letztendlich abtötet (siehe Abbildung 2).
Die Strangler Fig Application übernimmt nach und nach immer mehr Funktionen des Legacy-Systems. Nutzerinnen und Nutzer sehen immer nur die Fassade (Abb. 2).
Ein gutes Kriterium für die Wahl der ersten Fachlichkeit, die aus dem Legacy-System herausgelöst wird, ist der dadurch entstehende Geschäftswert [4]. Die Migration fügt beispielsweise dem Legacy-System zusätzliche Funktionen hinzu, etwa einen Check-in-Prozess sowohl für den Desktop als auch das Smartphone. Fachlichen Wert kann eine Migration auch stiften, wenn sie einen akuten Schmerz mit dem Legacy-System beseitigt: besonders unzuverlässige, fehleranfällige Funktionen.
Der Aufwand der Migration ist ein weiteres Kriterium. Spielt die Fachlichkeit an vielen Stellen im Monolithen eine Rolle, kann diese starke Verwebung eine Re-Integration erheblich erschweren. Beide Kriterien können in einer 2×2-Entscheidungsmatrix kombiniert werden (siehe Abbildung 3). Fachlichkeiten, die sich in der rechten, oberen Ecke befinden, sind gute Kandidaten für ein erstes SCS. Eine weitere Technik zur Analyse, die sich in der DDD-Community immer größerer Beliebtheit erfreut, sind Core Domain Charts.
Eine Entscheidungsmatrix hilft dabei, Kandidaten für das erste Self-contained System zu identifizieren (Abb. 3).
Das erste SCS integrieren
Hat man sich für einen guten Kandidaten entschieden, ergeben sich eine Reihe technischer Fragen. Gerade hier wirken sich die Stärken der sehr losen Kopplung durch die SCS-Architektur positiv aus. Folgende Möglichkeiten gibt es:
Link Integration: Im einfachsten Fall springen Nutzer über einen Link im Altsystem in das neue. Eine kleine Menge von Daten sowie eine Rücksprungadresse für den Erfolgs- oder Fehlerfall können hier als Request-Parameter mitgegeben werden:
UI-Inklusion: Auch eingebundene UI-Elemente erlauben eine sehr lose Kopplung zwischen zwei Systemen. Da nur Formate wie pures HTML und CSS ausgetauscht werden, muss das konsumierende System sehr wenig Details über Datenstrukturen oder deren Interpretation von dem Quellsystem wissen. Soll das System Kundendienst beispielsweise Stammdaten über ein Fahrzeug anzeigen, sind nicht die kompletten Datenstrukturen aus dem Fuhrparkmanagement erforderlich, vielmehr reicht eine kurze Beschreibung des Fahrzeugs (siehe Abbildung 4).
Ein UI-Element wird über HTTP von einem SCS geladen (Abb. 4).
Die Vorteile liegen auf der Hand: Entscheiden sich Architektinnen oder Architekten beispielsweise, die Daten eines Fahrzeugs anders zu benennen oder weitere Merkmale wie Kennzeichen aufzunehmen, kann das konsumierende System bleiben, wie es ist. Diese sehr lose Form der Kopplung wird jedoch durch eine Abhängigkeit zur Laufzeit bezahlt. Ist das Fuhrparkmanagement-SCS nicht verfügbar, liegen nur noch Stammdaten aus dem Cache vor.
Messaging zum Datenaustausch: Ist Laufzeitabhängigkeit bei der UI-Integration nicht erwünscht oder muss das System die Daten nicht nur anzeigen, sondern auch auswerten, ist eine Integration erforderlich, die zu einer stärkeren Kopplung zwischen beiden Systemen führt. Zu den Grundsätzen der SCS-Architektur gehört, dass jedes System über eine eigene Datenbank verfügen soll, die alle Daten enthält, die es benötigt. Verwenden mehrere Systeme bestimmte Daten, wird es nötig, sie zwischen den SCS auszutauschen.
Dabei hat sich eine Übertragung in Form von Domain Events bewährt. Dabei erzeugt ein System bei bestimmten Ereignissen (etwa beim Abschluss eines fachlichen Vorgangs) ein Domain Event mit allen relevanten Informationen (aber nicht mehr!) und publiziert es. Das konsumierende System kann auf die Publikation durch eigene Logik reagieren und seine eigene Kopie des entsprechenden Datensatzes anlegen oder anpassen. Bei der redundanten Speicherung ist es wichtig, genau festzulegen, welches System die Wahrheit definiert. Nur aus dieser Quelle sollten nachlaufende Systeme Daten konsumieren oder ändern.
Das oben beschriebene Event Storming hat bereits mögliche Events zur Integration identifiziert (siehe die orangefarbenen Kreise in Abbildung 1). Es gilt, diese zu relevanten Zeitpunkten aus dem Legacy-System heraus zu publizieren, sodass die neuen SCS sie konsumieren können.
Manchmal möchte ein System an anderer Stelle verortete Daten ändern oder anlegen. Am besten lässt sich das durch eine UI-Integration lösen: Muss etwa der Kundendienst einen Eintrag im Fuhrpark korrigieren, ist ein Sprung in die UI des Fuhrparkmanagements mit einem Rücksprung in das Kundendienst-SCS die beste Wahl. Ein Gegenbeispiel, bei dem diese Taktik nicht funktioniert, wäre die automatische Sperrung eines Benutzers, der seine Rechnungen nicht bezahlt. Hier kann ein Command (in Abbildung 1 grün) das Quellsystem anweisen, eine Änderung der Daten vorzunehmen. Das Quellsystem kann diese Anfrage jedoch ablehnen, wenn sie gegen die eigenen Regeln verstößt.
Integration über synchrone API-Aufrufe: Auch über eine RESTful API lässt sich ein anderes System direkt ansprechen. Da diese Methode Systeme zur Laufzeit stark aneinander bindet und zu einer fehleranfälligen, schwer abzufangenden Kaskade an blockierenden Aufrufen führen kann, gilt sie als letzter Ausweg. Sie kommt etwa dann zum Zuge, wenn die Daten aus dem Quellsystem viel zu umfangreich sind, um sie über Events zu replizieren, oder wenn sie nur durch die Anwendung fachlicher Logik quasi ad-hoc generiert werden können.
Fazit
Auch nach der Wahl und Planung eines ersten SCS-Kandidaten bleiben Fragen offen: Wie soll in Zukunft ein gemeinsamer Look and Feel zwischen den Self-contained Systems und dem Monolithen hergestellt werden? Wie lässt sich eine gemeinsame Nutzer- und Rechteverwaltung etablieren? Diese und noch viele weitere Fragen müssen Architektinnen und Architekten nicht sofort oder zumindest nicht sofort richtig beantworten.
Ein wesentlicher Vorteil der inkrementellen Migrationsstrategie ist, dass die Konsequenz einer Fehlentscheidung nicht katastrophal ist. Solange nur ein oder zwei Systeme laufen, ist Zeit zum Lernen, welche Entscheidungen wirklich für alle Systeme als getroffen gelten (Stichwort Makroarchitektur) und welche besser lokal zu fällen sind (Mikroarchitektur). Viele Ansätze zur Integration, Sicherstellung der UI-Konsistenz oder für Single Sign-on hängen von den konkreten Gegebenheiten ab.
Die Makroarchitektur wächst mit jedem weiteren Self-contained System, während das monolithische System weiter schrumpft. Unterstützung in Form von Best Practices für die Makroarchitektur unabhängiger Systeme finden sich auch in den Prinzipien der Independent Systems Architecture, die mit SCS sehr gut harmonieren.
Mit Beharrlichkeit und einem Fokus auf Geschäftswert werden Architektinnen und Architekten eher früher als später eine Landschaft von gut modularisierten, lose gekoppelten SCS und die damit verbundenen Vorteile genießen lernen. Und eventuell werden sie feststellen, dass manche Teile ihres Systems gar keiner Migration bedürfen.
Quellen
[1] Sam Newman; Building Microservices: Designing Fine-Grade Systems; 2021
[2] David Parnas; On the Criteria To Be Used in Decomposing Systems into Modules; 1972
[3] Eric Evans; Domain-Driven Design: Tackling Complexity in the Heart of Software, 2003
[4] Sam Newman; Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith; 2019
(who)
Künstliche Intelligenz
Unerwartet interessant: Moderne Drucker | c’t uplink
Man könnte ja meinen, Drucker seien seit mindestens 20 Jahren ausentwickelt. Einerseits ist das nicht ganz falsch, denn grundlegende Techniken wie Bubblejet- und Laserdruck verändern sich kaum noch. Andererseits ist seitdem viel passiert, was die Vertriebs- und Verkaufsmodelle für Tinte angeht.
Weiterlesen nach der Anzeige
Den wöchentlichen c’t-Podcast c’t uplink gibt es …
Vor allem ist etwas zur Realität geworden, wovon viele in den Nullerjahren nur träumen konnten: Tintendrucker mit festinstallierten Tanks, für die es Originaltinte zum in Nachfüllfläschchen zu kaufen gibt – und das Ganze zu privatkundenverträglichen Preisen. Eine andere Variante des Tintenvertriebs ist das Abo, bei dem der Drucker automatisch Tinte nachbestellt, sobald der Füllstand zur Neige geht.
Im c’t uplink sprechen wir über diese Vertriebsmodelle, aktuelle Druckertechnik, Preise – und warum Drucken unter Linux, anders als damals, inzwischen komplett stressfrei ist.
Zu Gast im Studio: Rudolf Opitz
Host: Jan Schüßler
Produktion: Tobias Reimer
► Unsere Drucker-Kaufberatung lesen Sie bei heise+ (€)
► sowie in c’t 4/2026 (€).
Weiterlesen nach der Anzeige
In unserem WhatsApp-Kanal sortieren Torsten und Jan aus der Chefredaktion das Geschehen in der IT-Welt, fassen das Wichtigste zusammen und werfen einen Blick auf das, was unsere Kollegen gerade so vorbereiten.
► c’t Magazin
► c’t auf Mastodon
► c’t auf Instagram
► c’t auf Facebook
► c’t auf Bluesky
► c’t auf Threads
► c’t auf Papier: überall, wo es Zeitschriften gibt!
(jss)
Künstliche Intelligenz
Telekom beendet Kampagne „Im besten Netz“ in der Netzkennung
Mobilfunk-Kunden der Deutschen Telekom sahen seit dem 22. Januar eine neue, sich bewegende Netzkennung mit der Nachricht „Im besten Netz“ in der linken Ecke ihres Smartphone-Bildschirms. Diese Anzeige war Teil einer großangelegten Werbekampagne, die der Netzbetreiber nun offenbar vorzeitig beendet hat. Die Änderung erfolgte per Over-the-Air-Update (OTA) auf die SIM-Profile der Kunden. Auf Telefonen sollte jetzt wieder Telekom.de zu sehen sein.
Weiterlesen nach der Anzeige
Die im Januar geänderte Netzkennzeichnung war Teil einer 360-Grad-Werbekampagne „für ihre leistungsfähigen Netze“, erklärt der Telekommunikationskonzern in seiner Ankündigung. Neben der Werbung auf dem Smartphone bewarb die Telekom ihr Netz mit einem neuen Werbespot mit dem Song „What The World Needs Now Is Love“ und verschiedenen Motiven.
Die Werbung auf den Smartphones der Kunden stieß auf allerhand Kritik: So schrieb etwa ein Telekom-Kunde: „Hallo, diese Smartphone-Anzeige ‚Im besten Netz‘ statt ‚Telekom‘ hat mich heute früh extrem verunsichert, dachte an einen Hackerangriff, der alle Daten abgegriffen hat und dann diesen Hinweis hinterlassen hat.“ Nicht nur Kundinnen und Kunden zeigten sich von der Werbung irritiert: Der Verbraucherzentrale Bundesverband hatte vor dem Oberlandesgericht Köln am 5. Februar 2026 einen Antrag auf Erlass der einstweiligen Verfügung gegen die Werbeanzeige gestellt.
Lesen Sie auch
Die Verbraucherzentrale scheint indes nicht der einzige Kläger zu sein: Wie Carsten Knobloch von Stadt-Bremerhaven.de aus Branchenkreisen erfahren haben will, reagierte die Deutsche Telekom mit der Rückkehr zur üblichen Netzkennung auf eine einstweilige Verfügung des LG Düsseldorf. Wie man einem bissigen Linkedin-Beitrag von Telekom-Chef Tim Höttges entnehmen kann, stammt die weitere Verfügung vom Mitbewerber 1&1.
Telekom: Kampagne wie geplant beendet
Mit dieser Verfügung hatte die „Im besten Netz“-Kampagne der Telekom offenbar früher als ursprünglich vorgesehen. Denn laut dem Netzbetreiber war sie zunächst für vier Wochen geplant, mit der Option der Verlängerung. Die Rückkehr zur alten Netzkennung bestätigen unter anderem Kunden im Telekom-Forum „Telekom hilft“.
Weiterlesen nach der Anzeige
Auf eine Anfrage von heise online bestätigte die Deutschen Telekom, dass eine einstweilige Verfügung vorliege. Die Kampagne habe der Konzern indes unabhängig davon beendet: Man habe von Beginn an geplant, Mitte Februar wieder auf „Telekom.de“ umzustellen. „Mit der Umstellung der Netzkennung auf ‚Im besten Netz‘ haben wir wie geplant rund vier Wochen darüber informiert, dass die Telekom ihren Kundinnen und Kunden höchste Netzqualität zur Verfügung stellt.“
Update
13.02.2026,
13:26
Uhr
Artikel um Linkedin-Beitrag von Tim Höttges erweitert.
(afl)
Dieses Abenteuer-Highlight kehrt endlich zurück
Eric Schwarz hat keine Angst vor großen Gefühlen › PAGE online
Von Legacy-Monolithen zu Self-contained Systems
Kommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac
Schnelles Boot statt Bus und Bahn: Was sich von London und New York lernen lässt
Huawei Mate 80 Pro Max: Tandem-OLED mit 8.000 cd/m² für das Flaggschiff-Smartphone
-
Entwicklung & Codevor 3 MonatenKommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac
-
Künstliche Intelligenzvor 2 MonatenSchnelles Boot statt Bus und Bahn: Was sich von London und New York lernen lässt
-
Apps & Mobile Entwicklungvor 3 MonatenHuawei Mate 80 Pro Max: Tandem-OLED mit 8.000 cd/m² für das Flaggschiff-Smartphone
-
Social Mediavor 3 TagenCommunity Management zwischen Reichweite und Verantwortung
-
Apps & Mobile Entwicklungvor 3 MonatenFast 5 GB pro mm²: Sandisk und Kioxia kommen mit höchster Bitdichte zum ISSCC
-
Entwicklung & Codevor 2 MonatenKommentar: Anthropic verschenkt MCP – mit fragwürdigen Hintertüren
-
Datenschutz & Sicherheitvor 2 MonatenSyncthing‑Fork unter fremder Kontrolle? Community schluckt das nicht
-
Social Mediavor 2 MonatenDie meistgehörten Gastfolgen 2025 im Feed & Fudder Podcast – Social Media, Recruiting und Karriere-Insights