Die architektonische Kernspaltung: Wie Container und VMs Isolation erreichen

Wenn Sie eine Anwendung in der Produktion bereitstellen, bestimmt die Umgebung, in der sie läuft, alles über ihr Verhalten — wie schnell sie beginnt, wie viel Speicher sie verbraucht, wie sicher sie ist und wie leicht sie sich zwischen Maschinen bewegt. Container und virtuelle Maschinen stellen zwei grundlegend unterschiedliche Ansätze zur Erstellung dieser Umgebungen dar, und der Unterschied beginnt auf architektonischer Ebene.

Eine virtuelle Maschine emuliert einen ganzen physischen Computer. Sie betreibt ein vollständiges Gastbetriebssystem mit einem eigenen Kernel, eigenen Gerätetreibern, einem eigenen Init-System und einem eigenen Satz von Systemdiensten. Der Hypervisor – Software wie VMware ESXi, Microsoft Hyper-V oder KVM – sitzt zwischen der physischen Hardware und der VM, übersetzt Hardwareanforderungen und erzwingt die Isolation. Wenn Sie eine VM starten, schalten Sie effektiv einen kompletten Computer in Ihrem Computer ein. Dieser Prozess braucht Zeit, verbraucht Ressourcen und bietet eine dicke Sicherheitsgrenze.

Container hingegen emulieren überhaupt keine Hardware. Container teilen sich den Kernel des Host-Betriebssystems direkt. Sie erreichen die Isolation durch Linux-Kernel-Features – Namespaces für Prozesssichtbarkeit, cgroups für Ressourcenlimits, seccomp für Systemaufruffilterung und SELinux oder AppArmor für obligatorische Zugriffskontrolle. Die Containerlaufzeit (wie Docker Engine oder containerd) startet Prozesse in diesen isolierten Umgebungen, ohne zusätzliches Betriebssystem zu booten. Das Ergebnis ist eine leichte, schnell startende Umgebung, die den Host-Kernel teilt, aber Prozesse getrennt hält.

Dieser architektonische Unterschied hat kaskadierende Auswirkungen auf jede operative Eigenschaft, die in der Produktion von Bedeutung ist: Ressourceneffizienz, Startgeschwindigkeit, Sicherheitshaltung, Portabilität und Managementkomplexität.

Virtuelle Maschinen in der Tiefe: Isolation, Reife und Overhead

Wie Hypervisoren Hardware-Virtualisierung ermöglichen

Hypervisoren sind die Grundlage der Technologie virtueller Maschinen. Ein Typ-1-Hypervisor läuft direkt auf physischer Hardware ohne Host-Betriebssystem und bietet nahezu native Leistung und starke Isolation. VMware ESXi, Microsoft Hyper-V und KVM sind die dominierenden Typ-1-Hypervisoren in Unternehmensumgebungen. Diese Systeme verwalten CPU-Zeitplanung, Speicherzuweisung, Speicher-I/O und Netzwerk für jede VM direkt, ohne dazwischenliegende OS-Schicht.

Typ-2-Hypervisoren wie Oracle VirtualBox und VMware Workstation laufen als Anwendungen auf einem Host-Betriebssystem. Sie führen zusätzlichen Overhead ein, da Hardwareanforderungen durch das Host-Betriebssystem gehen müssen, bevor sie den Hypervisor erreichen. Typ-2-Hypervisoren sind in Entwicklungs- und Testumgebungen üblich, werden jedoch aufgrund der Leistungsstrafe in der Produktion selten verwendet.

Wo VMs Excel in Produktion ist

Virtuelle Maschinen bleiben in vielen Szenarien unverzichtbar, die Container nicht angemessen angehen können. Das stärkste Argument für VMs ist die Isolationstiefe. Jede VM betreibt ihren eigenen Kernel, was bedeutet, dass eine Schwachstelle auf Kernelebene in einer VM keine andere VM auf demselben Host gefährden kann. Diese Isolation ist entscheidend für Multi-Tenant-Umgebungen, in denen Anwendungen von verschiedenen Kunden oder verschiedenen Sicherheitsdomänen auf gemeinsam genutzter Hardware gehostet werden.

Compliance-Frameworks wie HIPAA, PCI-DSS und FedRAMP erfordern häufig eine Isolation auf Hardwareebene zwischen den Workloads. Auditoren verstehen VM-Grenzen und akzeptieren eine hypervisorbasierte Isolation als bewährte Kontrolle. Containerisolation erfordert bei kontinuierlicher Verbesserung zusätzliche Sicherheitsmaßnahmen und Dokumentation, um die gleichen Compliance-Anforderungen zu erfüllen.

Da der Hypervisor dedizierte CPU-Kerne, reservierten Speicher und garantierte I/O-Bandbreite zuweisen kann, eignen sich VMs für latenzempfindliche Anwendungen, Echtzeitsysteme und Workloads, die unabhängig von der Aktivität benachbarter VMs einen konsistenten Durchsatz erfordern.

Legacy-Anwendungen stellen einen weiteren starken VM-Anwendungsfall dar. Unternehmenssoftware, die vor zehn oder zwanzig Jahren geschrieben wurde, geht oft davon aus, dass sie die volle Kontrolle über das Betriebssystem hat. Sie kann Kernel-Module installieren, Systemkonfigurationsdateien ändern, spezifische Service-Manager erwarten oder von bestimmten Betriebssystemversionen abhängen, die nicht als Container-Basisabbilder verfügbar sind. Das Hochziehen dieser Anwendungen in VMs vermeidet die Kosten und das Risiko, sie neu zu schreiben, während sie immer noch die Vorteile der Serverkonsolidierung und Hardwareabstraktion nutzen.

Die wahren Kosten virtueller Maschinen

Jede VM enthält ein komplettes Betriebssystem mit eigenem Kernel, Systembibliotheken, Protokollierungsinfrastruktur, Paketmanager und Hintergrunddiensten. Auf einem typischen Linux-Server verbraucht das Betriebssystem selbst 512 MB bis 2 GB RAM, bevor eine Anwendung startet. Multiplizieren Sie das mit zehn VMs auf einem Host, und Sie haben 5 bis 20 GB RAM an Betriebssysteme verloren.

Die Startzeit ist ein weiterer versteckter Kostenfaktor. Das Booten einer VM beinhaltet BIOS- oder UEFI-Initialisierung, das Laden von Kernel, das Starten von Diensten und den Start von Anwendungen. Selbst bei optimierten Bildern dauert dieser Prozess ein bis fünf Minuten. Diese Verzögerung ist inakzeptabel für Auto-Skalierungsszenarien, CI/CD-Pipelines oder jede Umgebung, in der Sie die Kapazität schnell als Reaktion auf die Nachfrage hochfahren müssen.

VM-Images sind groß – typischerweise zwei bis zehn Gigabyte für eine minimale Linux-VM und dreißig Gigabyte oder mehr für eine Windows-VM. Das Verschieben dieser Bilder zwischen Umgebungen, das Speichern in Artefakt-Repositorien und das Bereitstellen über Regionen hinweg kostet Bandbreite, Zeit und Speicherkosten.

Container in der Tiefe: Effizienz, Portabilität und Ökosystem

Wie Docker- und Container-Runtimes funktionieren

Docker hat keine Container erfunden, aber Docker hat sie nutzbar gemacht. Vor Docker existierten Container als Linux-Kernel-Features – Namespaces und Cgroups – aber es war eine erhebliche manuelle Konfiguration zum Erstellen und Verwalten erforderlich. Docker wickelte diese Kernel-Features in eine benutzerfreundliche CLI ein, führte das Konzept von geschichteten Bildern ein und schuf ein Registrierungs-Ökosystem für die gemeinsame Nutzung dieser Bilder.

Ein Docker-Image ist eine schreibgeschützte Vorlage, die aus Schichten besteht. Jede Schicht stellt eine Dateisystemänderung dar — Hinzufügen einer Binärdatei, Installieren einer Bibliothek, Kopieren von Konfigurationsdateien. Layers werden zwischengespeichert und über Bilder hinweg wiederverwendet, was bedeutet, dass das Ziehen eines Container-Images, das Schichten mit bereits vorhandenen Bildern teilt, schnell und bandbreiteneffizient ist. Wenn Sie ein Docker-Image ausführen, fügt die Laufzeit eine dünne beschreibbare Schicht oben hinzu, und der Container-Prozess beginnt innerhalb dieses geschichteten Dateisystems.

Container verbrauchen deutlich weniger Ressourcen als VMs, weil sie sich den Host-Kernel teilen und kein Betriebssystem booten. Ein typischer Web-Anwendungscontainer könnte 50 bis 200 MB RAM verbrauchen – ungefähr ein Zehntel dessen, was dieselbe Anwendung in einer VM verbrauchen würde. Diese Effizienz führt direkt zu einer höheren Dichte: Derselbe physische Host kann Hunderte von Containern ausführen, aber nur Dutzende von VMs.

Wo Container dominieren

Microservices-Architekturen sind der natürliche Lebensraum von Containern. Wenn man eine Anwendung in Dutzende oder Hunderte von kleinen Diensten zerlegt, jeder mit seinen eigenen Abhängigkeiten, Skalierungsanforderungen und Release-Kadenz, werden VMs unpraktisch. Jeden Microservice in einer separaten VM einzusetzen, würde Ressourcen verschwenden und das Management unhandlich machen. Container ermöglichen es Ihnen, all diese Dienste in einem gemeinsamen Cluster auszuführen, wobei jeder Dienst auf Prozessebene isoliert und unabhängig skaliert wird.

CI/CD-Pipelines profitieren enorm von der Containergeschwindigkeit. Eine Build-Pipeline, die ein Container-Image erstellt, Tests innerhalb dieses Bildes durchführt und dasselbe Bild in der Produktion bereitstellt, kann in Minuten statt Stunden ausgeführt werden. Die Fähigkeit, Container für Testumgebungen zu drehen, parallele Testsuiten auszuführen und alles zu zerreißen, ohne Rückstände zu hinterlassen, macht Container zur Standardwahl für die moderne Softwarebereitstellung.

Die Parität in der Entwicklungsumgebung ist eine weitere Containerstärke. Docker Compose ermöglicht es Entwicklern, den gesamten Anwendungsstack – Webserver, Datenbank, Cache, Nachrichtenwarteschlange – in einer einzigen YAML-Datei zu definieren. Jeder Entwickler im Team führt den gleichen Stack aus, wodurch die Konfigurationsdrift eliminiert wird, die Fehler verursacht, die "funktioniert auf meinem Computer". Neue Teammitglieder können am ersten Tag mit dem Beitrag beginnen, anstatt eine Woche damit zu verbringen, ihre Entwicklungsumgebung einzurichten.

Container-Einschränkungen, die Sie verstehen müssen

Container teilen sich den Hostkernel, was bedeutet, dass eine Kernel-Schwachstelle möglicherweise alle Container auf diesem Host betreffen kann. Container-Escape-Exploits – bei denen ein Prozess aus seinem Namespace ausbricht und Zugriff auf den Host erhält – sind selten, aber aufgetreten. Container sicher auszuführen erfordert eine sorgfältige Konfiguration von seccomp-Profilen, AppArmor- oder SELinux-Richtlinien, Benutzer-Namespaces und Funktionsverluste.

Container legen auch Einschränkungen für die Kompatibilität mit dem Betriebssystem fest. Linux-Container erfordern einen Linux-Hostkernel. Windows-Container erfordern einen Windows-Hostkernel. Sie können einen Linux-Container nicht direkt auf einem Windows-Host ausführen, ohne dass eine Linux-VM die Übersetzung vermittelt. Diese Einschränkung ist wichtig, wenn Ihre Infrastruktur mehrere Betriebssysteme umfasst.

Persistente Speicherung in Containern erfordert zusätzliche Planung. Container sind von ihrer Konzeption her flüchtig — sie können jederzeit gestoppt, zerstört und neu erstellt werden. Stateful Applications wie Datenbanken müssen Daten in Volumes speichern, die über den Containerlebenszyklus hinaus bestehen. Die Verwaltung dieser Volumes über einen Cluster von Container-Hosts erhöht die Komplexität, die VMs natürlicher handhaben.

Head-to-Head-Vergleich: Wichtige operative Eigenschaften

Startzeit und Agilität

Container starten in Millisekunden bis Sekunden. Ein Containerprozess startet, sobald die Laufzeit die Namespaces einrichtet und die Dateisystemebenen einbindet — es gibt keinen Kernel zum Booten, kein Init-System zum Initialisieren, keine Dienste zum Starten. Diese Geschwindigkeit macht Container geeignet für Auto-Skalierung, serverlose Funktionen und Batch-Verarbeitungs-Workloads, die Traffic-Spikes schnell bewältigen müssen.

VMs benötigen je nach Betriebssystem und Konfiguration ein bis fünf Minuten, um zu starten. Diese Startzeit macht VMs für elastische Workloads ungeeignet, aber für lang laufende, stabile Dienste, die nicht häufig hoch- und runterskalieren.

Ressourceneffizienz und Dichte

Container erreichen eine fünf- bis zehnmal bessere Dichte als VMs auf derselben Hardware. Ein Server mit 64 GB RAM könnte 10 bis 15 Linux-VMs bequem ausführen, aber 100 bis 200 Container. Dieser Dichtevorteil reduziert Infrastrukturkosten, Stromverbrauch und Rechenzentrumsfläche.

VMs bieten jedoch eine garantierte Ressourcenzuweisung. Wenn eine VM mit 4 GB RAM und 2 CPU-Kernen konfiguriert ist, werden diese Ressourcen reserviert, unabhängig davon, was andere VMs auf dem Host tun. Container teilen Ressourcen dynamisch, was effizienter ist, aber zu Ressourcenkonflikten führen kann, wenn sie nicht ordnungsgemäß mit cgroup-Limits eingeschränkt sind.

Sicherheits- und Isolationsgrenzen

VMs bieten eine stärkere Isolation, weil jede VM ihren eigenen Kernel hat. Eine Sicherheitslücke im Kernel einer VM kann andere VMs nicht beeinflussen, weil sie diesen Kernel nicht teilen. Der Hypervisor erzwingt Speicherisolation, Geräteisolation und Netzwerkisolation auf Hardwareebene. Dies macht VMs zur bevorzugten Wahl für Multi-Tenant-Hosting, Compliance-sensitive Workloads und jedes Szenario, in dem Sie garantieren müssen, dass ein Mandant nicht auf die Daten eines anderen Mandanten zugreifen kann.

Container bieten eine Prozessisolierung durch Kernelmechanismen. Diese Mechanismen sind zwar robust, haben aber eine kleinere Angriffsfläche — eine Container-Escape-Schwachstelle könnte den Host und alle darauf laufenden Container gefährden. Moderne Container-Sicherheitspraktiken — wurzellose Container, Benutzernamensräume, seccomp-Profile und Laufzeit-Sicherheitstools wie Falco — verringern dieses Risiko erheblich, aber die Isolationsgrenze bleibt dünner als die einer VM.

Portabilität zwischen Umgebungen

Container gewinnen entscheidend an Portabilität. Ein Docker-Image, das auf einem Laptop eines Entwicklers aufgebaut ist, läuft identisch auf einem Staging-Server, einem Produktionscluster, einer Cloud-VM oder einem Raspberry Pi zu Hause – solange alle Ziele eine kompatible Container-Laufzeit ausführen. Das Bild enthält den Anwendungscode, die Laufzeit, die Bibliotheken und die Konfiguration. Es gibt keine Abhängigkeit vom Host-Betriebssystem jenseits der Kernel-Schnittstelle.

VM-Bilder sind weniger portabel. Ein VM-Bild läuft nicht auf Hyper-V ohne Konvertierung. Eine für Intel-Prozessoren gebaute VM läuft nicht auf ARM-Hardware ohne Emulation. VM-Bilder sind auch viel größer, wodurch sie langsamer zwischen Umgebungen übertragen werden.

Praktischer Entscheidungsrahmen für die Infrastruktur 2026

Wählen Sie virtuelle Maschinen, wenn

  • Sie müssen mehrere Betriebssysteme auf derselben physischen Hardware ausführen – zum Beispiel Linux- und Windows-Workloads auf einem einzigen Server.
  • Compliance- oder regulatorische Anforderungen verlangen eine Isolation zwischen Workloads auf Hardware-Ebene, was in den Bereichen Finanzen, Gesundheitswesen und Regierung üblich ist.
  • Sie führen Legacy-Anwendungen aus, die von bestimmten Betriebssystemversionen, Kernelmodulen oder Systemkonfigurationen abhängen, die in Containerumgebungen nicht verfügbar sind.
  • Sie benötigen eine garantierte Ressourcenzuweisung und eine vorhersehbare Leistung für Latenz-sensitive oder Echtzeit-Workloads.
  • Sie betreiben eine virtuelle Desktop-Infrastruktur (VDI), bei der jeder Benutzer ein vollständiges Desktop-Betriebssystem erhält.

Container auswählen, wenn

  • Sie erstellen oder migrieren zu einer Microservices-Architektur, in der jeder Dienst eine unabhängige Bereitstellung und Skalierung benötigt.
  • Sie betreiben moderne CI/CD-Pipelines und benötigen schnelle, reproduzierbare Build- und Testumgebungen.
  • Entwicklungsgeschwindigkeit und Umweltkonsistenz sind Prioritäten für Ihr Team.
  • Sie stellen Cloud-native Anwendungen bereit, die dynamisch als Reaktion auf die Nachfrage skaliert werden müssen.
  • Sie möchten die Hardwareauslastung maximieren und die Infrastrukturkosten durch höhere Dichte senken.

Der Hybrid-Ansatz: Container innerhalb von VMs

Die gängigste Produktionsarchitektur im Jahr 2026 kombiniert beide Technologien. Sie stellen eine VM auf Ihrem Cloud-Provider oder On-Premise-Hypervisor bereit, installieren Docker oder eine Containerlaufzeit innerhalb dieser VM und führen Ihre Anwendungen als Container aus. Die VM bietet die Ressourcenzuweisung und die Sicherheitsgrenze; Container bieten die Anwendungspaketierung und Bereitstellungsflexibilität.

Dieses Muster bietet Ihnen mehrschichtige Sicherheit – der Hypervisor isoliert die VM und die Containerlaufzeit isoliert die Prozesse innerhalb der VM. Es gibt Ihnen auch operative Flexibilität: Sie können ausgereifte VM-Management-Tools für die Kapazitätsplanung und die Disaster Recovery verwenden und gleichzeitig von der Containergeschwindigkeit für Anwendungsbereitstellungen profitieren.

Wichtige Cloud-Anbieter unterstützen dieses Muster nativ. AWS Elastic Kubernetes Service (EKS) führt Kubernetes auf EC2-Instanzen aus, die VMs sind. Google Kubernetes Engine (GKE) bietet eine ähnliche Architektur. Azure Kubernetes Service (AKS) läuft auf Azure VMs. Selbst serverlose Containerplattformen wie AWS Fargate führen Container in MicroVMs aus, die eine VM-Level-Isolation mit Container-Level-Dichte bieten.

Container Orchestration: Managen auf Skalierung

Kubernetes als Industriestandard

Kubernetes ist zur dominierenden Container-Orchestrierungsplattform geworden, weil es eine umfassende Reihe von Funktionen für den Betrieb von Containern in der Produktion bietet. Automatisierte Rollouts und Rollbacks ermöglichen es Ihnen, Änderungen schrittweise bereitzustellen und automatisch zurückzusetzen, wenn Gesundheitschecks fehlschlagen. Service Discovery und Load Balancing Route Traffic zu gesunden Containerinstanzen ohne manuelle Konfiguration. Selbstheilungsmechanismen starten fehlgeschlagene Container neu, verschieben sie auf gesunde Knoten und beenden Container, die fehlgeschlagen sind Gesundheitschecks.

Kubernetes verwaltet auch die Storage-Orchestrierung – das Anbringen persistenter Volumes an Container, unabhängig davon, auf welchem Knoten sie ausgeführt werden. Geheimnisse und Konfigurationsmanagement halten sensible Informationen von Containerabbildern getrennt. Horizontales Pod-Autoskalieren passt die Anzahl der Container-Repliken basierend auf CPU, Speicher oder benutzerdefinierten Metriken an.

Die Kosten für diese Fähigkeiten sind komplex. Kubernetes hat eine steile Lernkurve. Cluster-Setup erfordert Verständnis für Netzwerk, Sicherheit, Speicher und Identitätsmanagement. Der Betrieb eines Kubernetes-Clusters in der Produktion erfordert Fachwissen in den Bereichen etcd, CNI-Plugins, Ingress-Controller, Zertifikatsmanagement und Beobachtbarkeitstools. Für Teams ohne bestehende Kubernetes-Erfahrung reduzieren Managed Services von Cloud-Anbietern diese Belastung durch die Handhabung der Steuerungsebene.

Docker Swarm für einfachere Deployments

Docker Swarm bietet eine einfachere Alternative zu Kubernetes. Swarm ist in Docker Engine integriert, es gibt also keine zusätzliche Installation. Es verwendet die gleichen Docker Compose Dateien, die Sie bereits für die lokale Entwicklung schreiben. Die Lernkurve ist viel niedriger — wenn Sie Docker verstehen, verstehen Sie den größten Teil von Swarm.

Swarm übernimmt grundlegende Orchestrierungsanforderungen: Service Discovery, Load Balancing, Skalierung und rollende Updates. Es funktioniert gut für kleinere Bereitstellungen, Entwicklungsumgebungen und Teams, die Einfachheit über Erweiterbarkeit stellen. Swarm fehlt jedoch das Ökosystem, die Community und die erweiterten Funktionen von Kubernetes. Die meisten Organisationen, die über Swarm hinauswachsen, migrieren zu Kubernetes, anstatt weiter in Swarm zu investieren.

Mehrere Technologien, die in den letzten Jahren an Zugkraft gewonnen haben, kombinieren Aspekte von Containern und VMs. AWS Firecracker, die MicroVM-Technologie, die Lambda und Fargate antreibt, startet virtuelle Maschinen in Millisekunden mit minimalem Overhead. Jede MicroVM führt einen abgespeckten Kernel und einen einzigen Prozess aus, der eine Isolation auf Hardwareebene mit containerähnlicher Dichte und Startgeschwindigkeit bietet.

Kata Containers und gVisor verfolgen unterschiedliche Ansätze. Kata Containers wickelt jeden Container in eine leichte VM ein, sodass Sie Container-Tools mit VM-Isolation erhalten. gVisor bietet einen Benutzer-Raum-Kernel, der Systemaufrufe abfängt und Sicherheitsrichtlinien ohne Hardware-Virtualisierung durchsetzt. Diese Technologien fördern die Konvergenz zwischen Container- und VM-Welten.

Auch die Praktiken von Infrastructure-as-Code verwischen die Grenzen. Terraform, Pulumi und Ansible verwalten sowohl VMs als auch Container mit deklarativer Konfiguration. Die operativen Fähigkeiten für die Verwaltung von VMs und Containern laufen aufeinander, und die meisten Infrastrukturteams arbeiten jetzt täglich mit beiden Technologien.

Ihre Entscheidung treffen: Praktische Anleitung

Beginnen Sie mit der Bewertung Ihres Anwendungsportfolios. Identifizieren Sie, welche Workloads die Isolationstiefe von VMs erfordern und welche von der Effizienz von Containern profitieren können. Für die meisten Unternehmen ist die Antwort eine Mischung: Legacy-ERP-Systeme und Compliance-sensitive Datenbanken bleiben auf VMs, während neue Microservices und Webanwendungen in Containern gespeichert werden.

Investieren Sie in Automatisierung, unabhängig von Ihrer Technologiewahl. Terraform für die Bereitstellung von Infrastruktur, Ansible oder Puppet für das Konfigurationsmanagement und CI/CD-Pipelines für die Bereitstellung – diese Praktiken kommen sowohl VM- als auch Containerumgebungen zugute. Die Fähigkeiten, die Sie in Automatisierung, Überwachung und Sicherheitstransfer zwischen Technologien aufbauen.

Planen Sie eine schrittweise Migration. Das Containern von Anwendungen erfordert kein Umschreiben. Beginnen Sie mit zustandslosen Anwendungen, die leicht zu containerisieren sind. Fügen Sie zustandsfähige Anwendungen hinzu, nachdem Sie Erfahrung mit persistentem Volumen- und Speichermanagement haben. Lassen Sie VMs für Workloads laufen, die nicht bereit sind, sich zu bewegen. Eine hybride Infrastruktur ist kein Fehlerzustand – sie ist das realistische Ziel für die meisten Organisationen.

Für maßgebliche Leitlinien zur Containersicherheit siehe CIS Docker Benchmark für Hardening Guidelines. Die Official Kubernetes Documentation bietet umfassende Referenz für Cluster-Operationen. Docker's Documentation deckt Containerentwicklung und Laufzeitkonfiguration ab. Die Cloud Native Computing Foundation verfolgt die Ökosystemreife und bietet Landschaftsübersichten für Container-native Technologien.