NUXOA – Eine souveräne Edge Cloud braucht ein Netzfundament
Eine souveräne Edge Cloud braucht ein belastbares Netzfundament. Warum wir beim Frankfurter Edge-Standort mit NUXOA und AS51202 zusammenarbeiten.
Platform
Interne oder gemanagte Plattformen, die Entwickler-Self-Service und goldene Pfade anbieten.
48 von 262 Einträgen
JD Group – Eine leistungsfähige Edge Cloud beginnt im Netzwerk
Partner Spotlight: Warum eine leistungsfähige Edge Cloud nicht nur Compute, sondern starke Netzwerkanbindung, Peering, Routing und Redundanz braucht.
Software-Betrieb für Behörden – Online-Dienste auf der ayedo Cloud
Betrieb von Bürgerportalen, Fachverfahren und EfA-Leistungen für die öffentliche Verwaltung: souverän auf der ayedo Cloud mit Standort in der EU, ISO-27001-zertifiziert, mit persönlichen Ansprechpartnern.
Einführung in OpenShift Workshop
Lernen Sie Red Hat OpenShift in 3 Tagen: Web Console, oc CLI, Routes, Builds, Operators und Security. Live-Online am eigenen Cluster. Maximal 8 Teilnehmer.
Einführung in Rancher Workshop
Lernen Sie Rancher live online in 3 Tagen: Multi-Cluster-Management, RKE2, Fleet GitOps und Longhorn. Eigener Cluster pro Teilnehmer, maximal 8 Plätze.
Building the Edge — Part 8
Der Anfang einer Plattform – warum jede Architektur irgendwann an den Punkt gelangt, an dem sie das Netzwerk neu denken muss.
Building the Edge — Part 7
Gute Plattformen entstehen nicht durch mehr Infrastruktur – sondern durch klar definierte Verantwortlichkeiten.
Building the Edge — Part 6
Eine Verbindung ist noch kein HTTP-Request – warum moderne Edge-Plattformen deutlich früher beginnen, als viele Architekturdiagramme vermuten lassen.
Building the Edge — Part 5
Compute ist nicht die Plattform – warum moderne Anwendungen heute aus zwei Plattformen bestehen.
Building the Edge — Part 4
Warum Hochverfügbarkeit heute im Netzwerk beginnt – Ausfälle sind kein Ausnahmezustand, sondern ein Architekturprinzip.
Building the Edge — Part 3
Eine IP-Adresse kann an drei Orten gleichzeitig existieren – warum Anycast keine Funktion, sondern eine Eigenschaft des Internets ist.
Building the Edge — Part 2
Das Internet kennt keine Anwendungen – warum BGP nicht versucht, den schnellsten Weg zu finden.
Kubernetes 1.38: Was wir bisher wissen
Kubernetes 1.38 ist für Dezember 2026 geplant. Wir zeigen, welche Features sich abzeichnen und welche Termine für den Release-Zyklus wichtig sind.
Polycrate Platform Architecture Workshop
2-Tage Polycrate Workshop für Platform-Architekten: IaC-Blöcke entwickeln, Kubernetes-Integration, Multi-Cluster-Management und Enterprise-Plattformen. Made in Germany.
Polycrate Platform Operations Workshop
Hands-on Polycrate Workshop für Platform Operators: Actions, Backups, Monitoring, Support-Workflows und App Deployments. Ein Tag intensives Training. Made in Germany.
Polycrate Platform Building Workshop
Individueller Beratungs- und Hands-on Workshop: Infrastruktur-Planung, Software Development Lifecycle und Aufbau interner Entwicklungskapazitäten. Für MSPs und IT Teams. Made in Germany.
Plattform
Die ayedo Software Delivery Platform: zertifiziertes Hosting cloud-nativer Software – Managed Kubernetes, Identity, GitLab, Argo CD, Harbor, OpenBao und Observability.
Building the Edge — Part 1
Die unterschätzte Architektur moderner Anwendungen – warum moderne Anwendungen nicht erst im Rechenzentrum beginnen.
Health Checks als Grundlage stabiler Traffic-Pfade
Health Checks im Loadbalancing bewerten nicht nur, ob ein Backend-Netzwerkziel erreichbar ist. Entscheidend ist, ob der Service tatsächlich Anfragen verarbeiten kann. Die Ergebnisse beeinflussen Pool-Zustände, Failover und Traffic-Steuerung. Damit werden Health Checks zur Grundlage verlässlicher Backend-Auswahl und stabiler öffentlicher Zugriffspfade.
Anycast im Traffic-Management: Routing bis zum Backend
Anycast Traffic Management beginnt mit einem global erreichbaren Einstiegspunkt, endet aber nicht am nächstgelegenen Edge-Standort. Anycast Routing führt den Traffic zu einer Edge-Instanz; dort entscheiden Layer-4- und Layer-7-Regeln über Backend-Pools, Health Status und gegebenenfalls Application-Routing. Erst diese Trennung schafft einen kontrollierbaren Pfad bis zur Anwendung.
L4 oder L7: Traffic-Management in der Edge Cloud
L4- und L7-Loadbalancing lösen unterschiedliche Aufgaben. Layer 4 vermittelt Verbindungen anhand von IP, Port und Transportprotokoll, ohne den Anwendungsinhalt auszuwerten. Layer 7 versteht HTTP oder HTTPS und ermöglicht Routing nach Hostname, Pfad oder weiteren Request-Merkmalen. Die Entscheidung bestimmt TLS-Verarbeitung, Backend-Pools und Betriebsaufwand.
Failover testen: Runbooks, Zustände und Rückfallpfade
Failover ist erst belastbar, wenn Ausfall, Umschaltung und Rückkehr reproduzierbar getestet werden. Ein gutes Failover-Runbook beschreibt erwartete Health-Check-Zustände, Routing- und DNS-Verhalten, Beobachtungspunkte sowie einen kontrollierten Rückfallpfad. Entscheidend ist nicht die konfigurierte Regel, sondern das nachweisbare Betriebsverhalten.
Failover-Reaktionswege zwischen Edge, DNS und Backend
Failover ist keine einzelne Umschaltfunktion, sondern eine Kette aus Erkennung, Entscheidung, Weiterleitung und Stabilisierung. Edge-Routing reagiert typischerweise näher am laufenden Traffic, während DNS-Failover durch TTLs, Resolver- und Client-Caches verzögert wird. Bestehende Verbindungen folgen dabei anderen Regeln als neue Requests.
Backend Health Checks als Grundlage für belastbares Failover
Backend Health Checks liefern die Signale, anhand derer eine Edge-Plattform erreichbare und nicht erreichbare Ziele unterscheidet. Ihre Aussagekraft hängt jedoch vom Prüfpunkt ab: Netzwerkverbindung, Prozesszustand und tatsächlich nutzbarer Service sind unterschiedliche Failure Domains. Belastbares Failover entsteht deshalb erst durch passende Prüfsignale und kontrollierten Wiederanlauf.
Verantwortungsgrenzen zwischen Plattform und Anwendung
Ein belastbares Betriebsmodell für die Edge trennt zentrale Schutz- und Netzwerkfunktionen von anwendungsspezifischer Konfiguration. Das Plattformteam verantwortet DNS, TLS, DDoS Protection und technische Erreichbarkeit. Das Anwendungsteam liefert fachliche Anforderungen, WAF-Regeln und belastbare Health-Check-Endpunkte. Shared Responsibility verhindert dabei blinde Zuständigkeitslücken.
Kubernetes und Edge Cloud als gemeinsame Plattformgrenze
Eine einheitliche Veröffentlichung mehrerer Kubernetes-Cluster beginnt nicht bei Ingress-Ressourcen, sondern bei einer klaren Plattformgrenze. Kubernetes steuert Workloads und interne Services; die providerunabhängige Edge übernimmt öffentlichen Traffic, Schutz, TLS, Routing und Failover. So entsteht eine gemeinsame Kubernetes Edge Integration für Managed- und externe Cluster.
Edge-Funktionen als Produkt der internen Plattform
Eine interne Entwicklerplattform sollte Edge-Funktionen nicht als individuelle Infrastrukturaufgabe behandeln. TLS-Terminierung, DNS, Loadbalancing und Backend Health Checks werden als standardisierte Plattformdienste mit klaren Schnittstellen, Zuständigkeiten und Betriebsmodellen bereitgestellt. So entsteht ein wiederverwendbares Plattformprodukt für unterschiedliche Anwendungsteams und Laufzeitumgebungen.
Vom DNS zum Backend: Der Request-Pfad an der Edge
Ein Request zur Anwendung durchläuft mehrere technische Ebenen: Anycast DNS liefert einen erreichbaren Einstiegspunkt, das Internet routet den Traffic zur Edge, dort erfolgen Loadbalancing, TLS-Termination und Sicherheitsprüfungen. Erst danach wird der Request über Backend-Routing an einen gesunden Service weitergeleitet. Diese Kette muss als zusammenhängender Betriebsprozess geplant werden.
Ingress- und API-Traffic zentral an der Edge schützen
Kubernetes Ingress Security beginnt nicht erst im Cluster. Werden WAF, DDoS Protection, TLS Termination und Backend Cloaking am öffentlichen Eingang gebündelt, erreichen viele Angriffe und unnötige Verbindungsversuche die Cluster nicht. Eine Edge-Plattform schafft dabei eine zentrale Schutz- und Routingebene vor mehreren Backends.
DNS-Zonen per API und Terraform konsistent verwalten
DNS-Änderungen gehören in denselben kontrollierten Prozess wie andere Infrastrukturänderungen. Mit der ayedo Edge Cloud lassen sich externe DNS-Zonen über API und Terraform deklarativ verwalten. Versionskontrolle, Reviews und reproduzierbare Ausführung reduzieren manuelle Fehler und schaffen klare Verantwortlichkeiten zwischen Plattform- und Anwendungsteams.
L4 und L7 im Vergleich: Trade-offs für den Betrieb
L4- und L7-Loadbalancing unterscheiden sich nicht nur durch ihre Protokollebene, sondern vor allem durch ihren Betriebsaufwand. L4 ist meist einfacher und robuster, L7 bietet mehr Steuerungsmöglichkeiten, erzeugt aber höhere Anforderungen an Konfiguration, Beobachtbarkeit und Änderungsmanagement. Eine Edge-Plattform kann beide Ebenen gezielt kombinieren.
Failover und Health Checks für Backend-Pools planen
Loadbalancing Failover ist keine automatische Garantie für Hochverfügbarkeit. Entscheidend ist, welche Fehler ein Health Check erkennt, wie schnell er reagiert und welche Ziele danach noch erreichbar sind. Eine belastbare Failover Architektur trennt technische Erreichbarkeit von fachlicher Betriebsfähigkeit und definiert das Verhalten für L4- und L7-Traffic eindeutig.
L4/L7-Loadbalancing für zustandsbehaftete Anwendungen
Bei zustandsbehafteten Anwendungen entscheidet nicht allein die Verteilung von Verbindungen über die passende Loadbalancing-Ebene. L4 bietet geringe Eingriffstiefe und eignet sich für stabile Verbindungen, während L7 Routinglogik und Session Persistence gezielter abbilden kann. Entscheidend sind Session-Modell, Backend-Pools, Skalierungsverhalten und Failover-Strategie.
Session Persistence: Zustände beim Routing beherrschen
Session Persistence hält Requests eines Clients möglichst am selben Backend. Das stabilisiert zustandsbehaftete Anwendungen, begrenzt aber die Flexibilität horizontaler Skalierung. Entscheidend sind daher ein belastbares Zustandsmodell, definierte Failover-Regeln und eine Edge-Architektur, die Zuordnung nicht mit garantierter Verfügbarkeit verwechselt.
TCP-Verteilung mit L4-Loadbalancing für robuste Dienste
L4 Loadbalancing verteilt TCP-Verbindungen anhand von Transportinformationen wie IP-Adresse und Port. Im Gegensatz zu HTTP-Routing bewertet es keine URLs, Header oder Inhalte. Dadurch bleiben Protokoll und Payload unverändert, während Backend-Pools, Health Checks und Failover robuste Dienste für Datenbanken, Messaging, VPNs oder proprietäre TCP-Anwendungen ermöglichen.
Failover und Health Checks für Backend-Pools an der Edge
Backend Health Checks entscheiden nicht nur, ob ein Server erreichbar ist. Sie bestimmen, wann ein Backend Traffic erhalten darf, wann ein Pool als eingeschränkt gilt und wann Failover greift. Für die Verfügbarkeit zählt daher die Prüfstrategie: Netzwerkstatus, Protokollverhalten und fachliche Antwort müssen zum tatsächlichen Fehlerbild der Anwendung passen.
Session Persistence zwischen Edge und Backend systematisch
Session Persistence bindet aufeinanderfolgende Anfragen eines Clients an dasselbe Backend. Das kann für legacy-orientierte, zustandsbehaftete Anwendungen notwendig sein, verschlechtert jedoch Skalierung, Failover und Lastverteilung. L7 Loadbalancing sollte deshalb zunächst prüfen, ob der Anwendungszustand nicht zentral oder verteilt außerhalb einzelner Backends verwaltet werden kann.
Kubernetes 1.37:
Mit Kubernetes 1.37 wird `metrics.k8s.io` als `v1` und damit als Stable API veröffentlicht. Die Resource Metrics API gehört seit Jahren zur etablierten Infrastruktur eines Kubernetes-Clusters: Sie stellt aktuelle CPU- und Memory-Nutzungsdaten für Nodes und Pods bereit, wird von `kubectl top` konsumiert und bildet die Grundlage für ressourcenbasiertes Autoscaling über den HorizontalPodAutoscaler.
Ihre Kubernetes-Plattform ist bereit für Container. Ist sie bereit für KI?
Kubernetes hat sich als zentrale Plattform für die Bereitstellung und den Betrieb [container](/kubernetes/)isierter Anwendungen etabliert. Angesichts der wachsenden Nachfrage nach KI-Integration in [D
Das Dual-Runtime-Prinzip:
In hochregulierten Branchen wie dem Banken- und Versicherungswesen scheitern moderne SaaS-Geschäftsmodelle selten an der Anwendungslogik, sondern an restriktiven Hosting-Vorgaben der Enterprise-Kunden. Während agile Fintechs ihre Plattformen in standardisierten Cloud-Umgebungen skalieren wollen, verlangen konservative Institute und öffentliche Träger aus Gründen der Datenklassifikation und Compliance den Betrieb im eigenen Rechenzentrum hinter der Firmen-Firewall. Für Softwarehersteller führt diese Diskrepanz traditionell zu einer kostspieligen Zersplitterung der Codebasis und zu massiven Reibungsverlusten im Platform-Engineering.
Das Base-Image-Paradoxon:
In vielen wachsenden Softwarehäusern und eCommerce-Plattformen führt der operative Erfolg unbemerkt in eine architektonische Sackgasse: Jede neue Kundeninstanz erhält individuelle Anpassungen direkt im Build-Prozess. Was als pragmatische Kundenorientierung beginnt, mündet bei 50 oder 100 Mandanten in einer unkontrollierbaren Explosion von Container-Images, intransparenten Abhängigkeiten und massiven Sicherheitsrisiken bei jedem Patchday.
Kyverno ist ein Plattformprimitive, kein Sicherheitstool
Kyverno wird häufig fälschlicherweise als reines Sicherheitstool betrachtet, obwohl es als Plattformprimitive fungiert, die Entwicklern hilft, komplexe [Kubernetes-Ressourcen](/kubernetes/) effizient
Cloud Native Plattform-Souveränität durch Multi-Plane-Architektur
Cloud-Souveränität erfordert eine durchdachte Architektur, die Kontrolle, Runtime, Build und Observabilität über Cluster hinweg trennt. Die Multi-Plane-Architektur, wie sie im OpenChoreo-Projekt imple
Das Elastic-ETL-Modell:
In vielen Industrie- und Rohstoffkonzernen stoßen gewachsene ETL-Pipelines bei steigenden Datenmengen an harte physikalische Grenzen: Monolithische Orchestrierungs-Setups oder statische VM-Umgebungen zwingen Data Engineers dazu, Rechenkapazitäten permanent für Lastspitzen zu dimensionieren. Das Ergebnis sind teure Leerläufe bei gleichzeitiger Gefahr von Pipeline-Abbrüchen, sobald unvorhergesehene Datenmengen aus Produktionsstandorten zeitgleich einlaufen.
Das Self-Service-Engineering-Prinzip:
In vielen Data-Engineering- und Analytics-Organisationen beginnt jedes neue Projekt mit einem zeitraubenden Hindernislauf: Spezialisierte Python-Umgebungen, heterogene R-Pakete, divergierende CUDA-Treiber und lokale Host-Abhängigkeiten führen dazu, dass Entwickler Tage oder Wochen mit dem Einrichten lokaler Workstations verbringen. Der Satz „Auf meinem Rechner läuft es“ ist zum teuersten Symptom fragmentierter Plattform-Landschaften im gehobenen Mittelstand geworden.
Die Zero-Trust-Identitätsarchitektur: Wie granulare RBAC-Isolation ML-Plattformen auditfest skaliert
In vielen Machine-Learning-Initiativen kollidieren Innovationsgeschwindigkeit und IT-Sicherheit frontal: Um schnelle Trainingsergebnisse zu erzielen, teilen sich Data Scientists, externe Dienstleister und Entwicklerteams oft pauschale Cluster-Admin-Rechte, statische API-Keys oder unzureichend isolierte Zugänge zu sensiblen Inferenz-Endpunkten. Sobald Plattformen den Sprung aus der geschützten Sandbox in den industriellen Produktivbetrieb vollziehen, verwandelt sich dieser pragmatische Wildwuchs in ein gravierendes Einfallstor für Privilegienerweiterungen und Datenlecks.
LLMOps und Plattformengineering: Wer sollte die AI-Pipeline besitzen?
LLMOps, die Praxis des Betriebs großer Sprachmodelle, erfordert eine enge Zusammenarbeit zwischen [DevOps](/kubernetes/), MLOps und Plattformengineering. Die richtige Zuordnung von Verantwortlichkeite
So formatierst du dein Kubernetes YAML als KYAML und warum es sinnvoll ist
KYAML ist eine striktere und konsistentere Variante von YAML, die speziell für [Kubernetes](/kubernetes/) entwickelt wurde. Sie reduziert die Komplexität und Fehleranfälligkeit beim Schreiben von Kube