NextGen IT Stack Radar DACH 2026/H1: Klare Empfehlungen für Tech-Leads

Marcus, Solution Architect | NextGen IT

ThoughtWorks publiziert seit 2010 einen Technology Radar.^[6] Wir machen das auch, nur zugeschnitten auf die Realität des deutschen, österreichischen und schweizer Mittelstands. 50 bis 250 Mitarbeiter, On-Premise-Altlasten, BSI-Grundschutz als Randbedingung, kein Hyperscaler-Budget. Dieser Radar ist kein Wunschkonzert. Er ist eine Positionierung, die ich mit meinem Namen vertreten kann.

Vier Ringe, wie gehabt: Adopt, Trial, Assess, Hold. Wer ein neutrales „Es kommt drauf an" erwartet, liest den falschen Radar.

Methodik

Jede Einordnung basiert auf drei Kriterien. Erstens produktionsreife Evidenz, das heißt mindestens zwei Referenzinstallationen im DACH-Mittelstand. Zweitens der Betriebsaufwand relativ zur erzielten Wertschöpfung. Drittens die regulatorische Kompatibilität (DSGVO, BSI IT-Grundschutz, NIS2).^[5] Technologien im Ring Hold werden nicht verdammt. Sie bekommen schlicht keine neuen Investitionen. Der Unterschied zählt.

ADOPT: Jetzt einsetzen, kein weiteres Abwarten rechtfertigbar

Platform Engineering mit Internal Developer Platform (IDP)

Martin Fowler hat es 2003 in Patterns of Enterprise Application Architecture vorweggenommen: Infrastruktur, die sich wie ein Produkt verhält, reduziert die kognitive Last der Entwicklungsteams dauerhaft.^[1] Heute heißt das Internal Developer Platform. Ein IDP, aufgebaut auf Backstage.io als Katalog-Schicht, kombiniert mit GitOps und einem Self-Service-Portal für Umgebungen, ist keine Spielerei für FAANG-Konzerne. Es ist die einzige nachhaltige Antwort auf den Engpass DevOps-Kapazität im Mittelstand.

Warum Adopt? Teams mit weniger als acht Backend-Entwicklern können sich kein dediziertes Platform-Team leisten. Aber sie können einen schlanken Golden Path definieren: ein Dockerfile-Template, eine CI/CD-Vorlage, ein Monitoring-Stack. Das genügt, um die Onboarding-Zeit um 40 % zu senken, eine Zahl, die wir intern gemessen haben. Wer heute noch jeden Entwickler sein eigenes Deployment-Skript schreiben lässt, verschenkt Seniorität.

Empfehlung: Backstage.io als Einstieg, port.io als managed Alternative wenn kein Kubernetes-Know-how vorhanden.

OpenTelemetry

Observability ohne Vendor-Lock-in war bis 2022 ein Versprechen. Seit OpenTelemetry v1.0 (Traces) und der Stabilisierung des Metrics-Signals ist es Realität. Das Projekt hat 2026 mehr Contributor als jedes andere CNCF-Projekt außer Kubernetes selbst. OTEL ist der einzige vertretbare Standard für Traces, Metrics und Logs in Neuimplementierungen.

Sam Newman schreibt in Building Microservices (2. Auflage, 2022): „Observability is not optional in a distributed system, it's the prerequisite for everything else."^[2] Ich unterschreibe das vollständig. Wer heute mit Datadog-SDKs oder proprietären APM-Agents neu aufbaut, tauscht kurzfristige Einfachheit gegen mittelfristige Abhängigkeit. Der Exit-Cost übersteigt den Onboarding-Vorteil nach spätestens 24 Monaten.

Empfehlung: OTEL Collector als zentrales Gateway. Die Backend-Wahl (Grafana Tempo, Jaeger, oder kommerziell) davon getrennt treffen. Genau das ist der Punkt.

GitOps mit Flux v2 oder ArgoCD

Deployment als deklarativer Zustand im Git-Repository ist kein Modetrend, sondern die logische Konsequenz aus Immutable Infrastructure. Wer Infrastructure-as-Code mit Terraform betreibt, aber Deployments noch per kubectl apply oder Ansible-Playbook auslöst, hat einen konzeptionellen Bruch in seiner Delivery-Kette.

Flux v2 ist die konservativere Wahl: kleiner Footprint, CNCF graduated, Pull-Modell ohne eingehende Netzwerkverbindungen ins Cluster. Im BSI-Kontext ein klarer Vorteil. ArgoCD bietet mehr UI und Multi-Cluster-Support, das aber auf Kosten von mehr Komplexität. Für den Mittelstand mit einem Cluster: Flux.

Empfehlung: Flux v2 für Single-Cluster. ArgoCD ab drei oder mehr Clustern. Hybride Entscheidungen (beides gleichzeitig) sind architektonische Selbstbestrafung.

TRIAL: Gezielte Piloten starten, nicht flächendeckend ausrollen

eBPF für Observability und Security

Extended Berkeley Packet Filter ist seit Linux-Kernel 5.8 stabil genug für den Produktionseinsatz. Was Cilium und Falco damit ermöglichen, ist substanziell. Netzwerktransparente Observability ohne Sidecar-Proxies, dazu Syscall-basierte Anomalieerkennung ohne Agent-Installation pro Service. Im Kontext der NIS2-Konformitätspflichten (die Umsetzungsfrist Oktober 2024 ist überschritten, wer es noch nicht hat, ist im Verzug) bietet Falco/eBPF ein Intrusion-Detection-Signal, das herkömmliche SIEM-Anbindungen ergänzt.

Einschränkung: eBPF erfordert Kernel-Kontrolle. In managed Kubernetes-Angeboten (AKS, GKE) ist das teilweise eingeschränkt. Hetzner Dedicated und eigenem Bare-Metal steht nichts im Weg.

Empfehlung: Pilot mit Cilium als CNI in einem Staging-Cluster. Entscheidung nach sechs Monaten Betriebserfahrung. Kein flächendeckendes Ausrollen ohne internen eBPF-Kenntnisträger.

Vektordatenbanken für RAG-Workloads

Große Sprachmodelle ohne Anbindung an eigenes Unternehmenswissen sind im B2B-Kontext weitgehend nutzlos. Retrieval-Augmented Generation (RAG) ist die pragmatische Architektur, um das zu ändern, und sie benötigt eine Vektordatenbank. pgvector auf PostgreSQL reicht für die meisten Mittelstands-Workloads aus (unter 10 Millionen Vektoren, keine Sub-10ms-Anforderungen). Wer skalierbarere Anforderungen hat: Qdrant ist Rust-native, deployment-freundlich und BSI-tauglich, weil selbst gehostet.

Vlissides et al. formulierten 1994 in Design Patterns das Prinzip: „Program to an interface, not an implementation."^[4] Das gilt hier für die Embedding-Schicht. Stellt API-Kompatibilität zu OpenAI sicher, damit der Modellaustausch (lokales Mistral gegen GPT-4o) ohne Architektur-Umbau möglich bleibt.

Empfehlung: pgvector als Einstieg wenn PostgreSQL bereits vorhanden. Qdrant wenn dedizierte Vektorsuche mit Filterung über Millionen Dokumente benötigt wird. Pinecone oder Weaviate Cloud nur wenn Datensouveränität keine Rolle spielt, was im DACH-Raum selten zutrifft.

Dagger.io für portable CI/CD-Pipelines

CI-Konfigurationen sind heute das neue Vendor-Lock-in. GitLab CI YAML, GitHub Actions Syntax, Jenkins Groovy: jeder Migrationspfad kostet Monate. Dagger kapselt die Pipeline-Logik in Code (Go, Python, TypeScript) und führt sie lokal wie in der Cloud identisch aus. Das Versprechen „same pipeline everywhere" ist 2026 eingelöst.

Einschränkung: Das Ökosystem ist noch klein, und die Debugging-Erfahrung schlechter als bei etablierten CI-Systemen. Noch kein Adopt-Kandidat, aber die Richtung stimmt.

ASSESS: Beobachten, noch nicht investieren

KI-gestützte Entwicklungsumgebungen (Copilot, Cursor, Cody)

Die Produktivitätsgewinne bei der Code-Completion sind real. GitHub veröffentlichte 2023 eine Studie mit 55 % schnellerer Aufgabenerfüllung bei standardisierten Tasks. Die technische Schuld durch unkritisch übernommenen generierten Code ist allerdings genauso real. Vaughn Vernon warnt in Implementing Domain-Driven Design (2013) vor dem „Smart UI Anti-Pattern", also Komplexität, die im falschen Layer landet.^[3] KI-Assistenten reproduzieren dieses Muster auf Codebase-Ebene, wenn kein Review-Prozess existiert.

Position: Sinnvoll für Junior-Entwickler unter Senior-Supervision. Kein Produktivitätswerkzeug für komplexe Domänenmodellierung. Regulatorisch gilt: bei Einsatz in Projekten mit personenbezogenen Daten die DSGVO-Konformität der Datenübertragung prüfen (GitHub Copilot: Daten verlassen die EU).

WebAssembly (WASM) außerhalb des Browsers

WASM als serverseitiges Runtime (via Spin, Wasmtime) verspricht Isolation ohne Container-Overhead. Technisch faszinierend. Die Produktionsreife für allgemeine Backend-Workloads ist aber noch nicht erreicht. Beobachten.

HOLD: Keine Neuinvestitionen

Jenkins als primäre CI/CD-Plattform

Jenkins hat eine glorreiche Geschichte. Es hat auch eine Gegenwart als Wartungs-Albtraum: XML-Konfiguration, Plugin-Kompatibilitätshölle, kein natives Container-Modell. 2026 existieren bessere Alternativen (GitLab CI, GitHub Actions, Woodpecker CI für Self-Hosted), die alle ohne dedizierten Jenkins-Administrator auskommen. Migration kostet Zeit. Kein Invest in neue Jenkins-Pipelines kostet weniger.

Ausnahme: Bestehende, stabile Jenkins-Infrastruktur mit funktionierendem Know-how. Migration nur mit klarem Business-Trigger.

Ansible als alleiniges IaC-Werkzeug

Ansible ist ein exzellentes Konfigurationsmanagement-Werkzeug. Es ist kein Infrastructure-as-Code-Werkzeug im modernen Sinne: es gibt keinen State, keinen Plan-Step, keine Drift-Erkennung. Wer Cloud-Ressourcen (Hetzner Cloud, Azure, AWS) per Ansible provisioniert, statt Terraform oder OpenTofu zu verwenden, baut auf einem konzeptionellen Fundament, das für diese Aufgabe nicht entworfen wurde.

Regel: Terraform/OpenTofu für die Infrastruktur-Provisionierung. Ansible für OS-Konfiguration und Application-Deployment auf der provisionierten Infrastruktur. Die Kombination ist stark. Jedes Tool alleine für alles ist ein Anti-Pattern.

Monolithische Deployments ohne Feature Flags

Wer Features direkt in Releases koppelt, koppelt auch das Business-Risiko in jedes Deployment. Feature Flags (via Unleash, OpenFeature Standard, oder LaunchDarkly) entkoppeln Deployment von Release. Das ist keine Komfortfunktion, sondern die Voraussetzung für Trunk-Based Development und damit für Continuous Delivery. Ohne Feature Flags keine sinnvolle CI/CD-Strategie.

Fazit: Drei Entscheidungen für das zweite Halbjahr 2026

Wenn ich Tech-Leads im DACH-Mittelstand eine Prioritätenliste geben soll, dann diese:

1. OpenTelemetry jetzt standardisieren. Jeder neue Service ohne OTEL-Instrumentierung ist technische Schuld, die in zwölf Monaten abgetragen werden muss. Der Aufwand heute: zwei Tage. Der Aufwand später: zwei Wochen pro Service.

2. GitOps als Deployment-Standard einführen. Nicht weil es modern klingt, sondern weil Auditierbarkeit und Rollback ohne GitOps manuelle Arbeit sind. Im NIS2-Kontext ist das kein Nice-to-have.

3. Jenkins-Migration planen. Nicht sofort umsetzen, aber einen Migrationspfad definieren und keine neuen Pipelines mehr in Jenkins aufbauen. Die Konversionsstrategie entscheidet über die Migrationskosten.

Der Rest des Radars gibt Orientierung. Diese drei Punkte sind Entscheidungen. Wer sie aufschiebt, trifft sie trotzdem, nur unter schlechteren Bedingungen.

Quellen

[1] Martin Fowler, „Patterns of Enterprise Application Architecture", Addison-Wesley, 2002.

[2] Sam Newman, „Building Microservices", 2. Aufl., O'Reilly, 2022.

[3] Vaughn Vernon, „Implementing Domain-Driven Design", Addison-Wesley, 2013.

[4] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, „Design Patterns", Addison-Wesley, 1994.

[5] BSI IT-Grundschutz-Kompendium, Edition 2023.

[6] ThoughtWorks Technology Radar, Vol. 30, April 2024.