Infrastruktur ist nicht nur eine IT-Frage: Es ist eine Tracking-Frage
Wenn ein Unternehmen eine serverseitige Tracking-Plattform evaluiert, dreht sich das Gespräch meist um Datenqualität, Konnektoren und Einwilligung. Die darunterliegende Ebene kommt selten zur Sprache, bis die Rechts- oder IT-Abteilung zum Gespräch hinzukommt – und dann wird alles auf einmal thematisiert: Welches Land verarbeitet die Daten, wer hat Zugriff darauf, was passiert bei Verkehrsspitzen und wer ist verantwortlich, wenn um zwei Uhr morgens ein Knotenpunkt ausfällt?
Für eine Tracking-Plattform sind diese Fragen nicht nebensächlich. Serverseitige Erfassung bedeutet, dass die Infrastruktur des Anbieters im Pfad jedes Ereignisses auf Ihrer Website liegt. Wenn sie nicht skalieren kann, gehen Daten verloren. Wenn sie außerhalb der EU verarbeitet, bricht das Compliance-Argument zusammen, unabhängig davon, wie sich das Produkt verhält.
Dieser Artikel beschreibt den technischen Unterbau der JENTIS-Plattform und stützt sich dabei auf die von IONOS veröffentlichte Cloud Success Story.
Die wichtigste Anforderung zuerst: Die Verarbeitung bleibt in der EU
JENTIS wurde 2020 in Wien von Tracking- und Analytics-Experten gegründet. Die Grundvoraussetzung war von Anfang an, dass Unternehmen Webdaten erfassen können sollten, ohne die Kontrolle darüber abzugeben, und dass die Rohdaten beim Kunden verbleiben sollten, anstatt beim Anbieter.
Diese Prämisse setzt eine harte Grenze für die Hosting-Ebene. Eine Plattform, die entwickelt wurde, um europäische Unternehmen vor Problemen bei Datentransfers in Drittstaaten zu bewahren, darf selbst keine Daten außerhalb der EU verarbeiten. Der Infrastrukturpartner musste garantieren, dass Daten nicht an Drittländer weitergegeben oder über EU-Grenzen hinweg verarbeitet werden – und diese Garantie musste vertraglich zugesichert sein, nicht nur eine Frage der Konfiguration.
Das ist auch der Grund, warum es bei der Entscheidung nie nur um Preis oder Verfügbarkeit ging. Die meisten der größten Cloud-Anbieter schieden aufgrund dieser Anforderung von vornherein aus.
Warum kein On-Premise
Der Betrieb eigener Hardware wurde früh in Betracht gezogen und wieder verworfen. Für ein kleines Team hätte eine On-Premise-Infrastruktur genau die Engineering-Kapazitäten absorbiert, die das Produkt benötigte, und wirtschaftlich war dies zu diesem Zeitpunkt nicht tragbar.
Es gab einen zweiten Grund. Die Kunden von JENTIS reichen von mittelständischen Firmen bis hin zu Großunternehmen aus den Bereichen Bankwesen, Automobilindustrie und E-Commerce, und ihre Ressourcenanforderungen unterscheiden sich vom ersten Tag der Implementierung an stark. Eine feste Infrastruktur, die auf einen Durchschnittskunden ausgelegt ist, wäre für die meisten von ihnen ungeeignet gewesen. Was die Plattform brauchte, war die Fähigkeit, ihre eigene Server-Topologie zu definieren und bei Bedarf anzupassen – nicht eine Vorlage des Anbieters mit bereits festgelegten Ressourcenzuweisungen.
Kubernetes war eine zwingende Voraussetzung, da das Produkt als containerisierte Microservice-Architektur aufgebaut ist.
Was gegen Anbieter sprach
Vor der Entscheidung wurden mehrere Anbieter getestet. Die wiederkehrenden Probleme waren struktureller und nicht zufälliger Natur: kein verwaltetes Kubernetes-Angebot, keine persistenten Volumes und Support-Vereinbarungen, bei denen die Zuständigkeit im Fehlerfall unklar war. Diese Partnerschaften endeten schnell. Der Debugging-Aufwand, der mit einem Infrastrukturpartner einhergeht, der keine Fragen beantworten kann, ist ein direkter Kostenfaktor für ein kleines Engineering-Team.
Managed Kubernetes als Fundament
Die Plattform läuft auf einem verwalteten Kubernetes-Cluster innerhalb des IONOS Cloud-Ökosystems, mit der Microservice-Architektur im Hintergrund.
Zwei Eigenschaften sind operativ entscheidend. Die erste ist die bedarfsgerechte Skalierung: Die Kapazität folgt dem Verlauf der Arbeitslast und nicht einem bereitgestellten Maximum, was es ermöglicht, sehr unterschiedlich große Kunden auf derselben Plattform zu betreiben. Die zweite ist die Selbstheilung. Die Cluster erholen sich automatisch von Komponentenausfällen ohne manuelles Eingreifen, wodurch der Wartungsaufwand proportional zur Größe des Teams bleibt, das sie betreibt, und nicht zur Größe der gesamten Infrastruktur.
Für Kunden bedeutet das konkret: Eine Verkehrsspitze auf Ihrer Website ist ein Infrastrukturereignis, das von der Plattform gehandhabt wird, und kein Vorfall, bei dem Ihr Team aktiv werden muss.
Das Speicherproblem, das den Ausschlag gab
Der technisch interessanteste Teil der Geschichte ist eine Einschränkung und kein Feature.
Zu Beginn der Zusammenarbeit standen nur Kubernetes Persistent ReadWriteOnce-Volumes zur Verfügung, was für den Anwendungsfall von JENTIS nicht geeignet war. Es wurde ReadWriteMany benötigt, was im Angebot jedoch nicht enthalten war.
Anstatt dies als Hindernis zu betrachten, entwickelten die beiden Engineering-Teams eine benutzerdefinierte Storage-Klasse auf Basis von S3-Speicher, die ReadWriteMany ermöglichte und die Anforderung erfüllte. JENTIS bezeichnete dies als das entscheidende Kriterium für die Zusammenarbeit, das durch die Entwicklung einer Lösung gelöst wurde, die nicht auf der Produkt-Roadmap stand.
Das ist ein nachvollziehbarer Punkt für jeden Käufer. Infrastruktur-Partnerschaften werden üblicherweise anhand der Funktionsliste bewertet. Diese Entscheidung fiel jedoch aufgrund dessen, was geschah, als die Funktionsliste nicht ausreichte.
Drei Datenbanken, drei Aufgaben
Die Datenschicht nutzt drei Speicher, von denen jeder einen eigenen Zweck erfüllt:
- Redis fungiert als Nachrichten-Warteschlange und puffert Daten während der Übertragung. Sollte ein nachgelagerter Prozess ausfallen, verhindert dieser Puffer, dass Ereignisse verloren gehen.
- MongoDB dient als Key-Value-Store für schnelle Abfragen.
- MySQL speichert die größeren Datenmengen.
Die Integration der Einwilligung und die Pseudonymisierung erfolgen innerhalb dieser Pipeline, bevor die Daten ein Ziel erreichen. Kunden entscheiden selbst, ob JENTIS ihre Rohdaten überhaupt speichert; von dort aus werden die Daten an die kundenseitig konfigurierten Tracking-Tools weitergeleitet. [Aktuelle Architektur bestätigen. Teile davon spiegeln das Setup von 2023 wider.]
Support als Auswahlkriterium
Der technische Support wurde als entscheidender Faktor und nicht nur als unterstützende Komponente genannt. Der rund um die Uhr verfügbare Zugang zu Ingenieuren, die kompetente Antworten geben konnten – auch während der Testphase vor Vertragsabschluss –, hatte echtes Gewicht. Ebenso wie die direkten Arbeitssitzungen mit Kubernetes-Spezialisten während der Design- und Aufbauphase.
Dies sollte klar ausgesprochen werden, da es auch auf die Arbeitsweise von JENTIS mit seinen eigenen Kunden zutrifft. Ein Plattform-Team, das reaktionsschnellen Infrastruktur-Support benötigt, um schnell voranzukommen, baut sein Servicemodell nach demselben Prinzip auf.
Was das für Ihre Evaluierung von JENTIS bedeutet
Aus der oben beschriebenen Architektur ergeben sich vier Punkte, die Sie unbedingt mit Ihren IT- und Rechtsabteilungen besprechen sollten:
- Die Verarbeitung erfolgt innerhalb der EU, auf einer Infrastruktur, die auf dieser Grundlage vertraglich vereinbart wurde. [Aktuelle Hosting-Regionen und Wortlaut der AVV bestätigen]
- Sie behalten Ihre Rohdaten. Ob JENTIS diese speichert, entscheidet der Kunde, nicht die Standardeinstellung der Plattform.
- Die Skalierung ist Aufgabe der Plattform. Die Kapazität passt sich Ihrem Traffic an, ohne dass Sie eine Dimensionierung vornehmen müssen.
- Die Infrastruktur wird verwaltet und nicht selbst gehostet. Ihr Engineering-Team implementiert den Basis-Code und einen DNS-Eintrag. Es muss keine Server betreiben.
