Observability-Preisfallen: Top 5

Separate monatliche Zusatzkosten und Aufschläge

Abonnementbasierte Preismodelle im Enterprise-Segment zielen darauf ab, das vertragliche Commitment für Shelfware zu maximieren – Überhangtechnologien also, die zwar bezahlt, aber nicht genutzt werden. Bleiben die entsprechenden Kontingente ungenutzt, leidet der ROI. Werden sie zu viel genutzt, fallen Aufschläge an. Der Anbieter gewinnt also in jedem Fall.

Und so sind in vielen niederschwelligen Preismodellen und bei Abrechnung je Agent oft nur eingeschränkte Kontingente etwa zur Datenerfassung und -Retention, für Container, Custom-Metrics und Synthetics-Checks enthalten. Um unerwünschte Kostenüberraschungen zu vermeiden, müssen diese Grenzen und die Gebühren für ihre Überschreitung bei der Budgetplanung präzise berücksichtigt werden.

Eine containerbasierte Abrechnung (wie bei Datadog¹) schlägt sich schnell in einem erhöhten Konfigurationsaufwand für Ihre Entwickler:innen nieder. Denn häufig fallen bei mehr als fünf Containern auf einem Infrastruktur-Host Aufschläge an. Nicht unproblematisch, denn 20 oder mehr sind durchaus gang und gäbe. Splunk berechnet ganze 150 % zusätzlich bei Überschreiten des monatlichen Abonnement-Kontingents für Synthetics-Checks. ²

Weicht die Freude über einen niederschwelligen Einstieg der Realität kaum planbarer Zusatzkosten im Zuge der Skalierung, ist das wenig erfreulich. Das kleine Wörtchen „Ab“ vor dem Preis dient da durchaus als Warnsignal. Im Rahmen eines Jahresvertrags mit monatlichen Fixausgaben bietet etwa Datadog Vergünstigungen. Der On-Demand-Preis fällt bei Monatsverträgen oder Überschreiten des Monatskontingents jedoch um 17 bis 50 % höher aus: Hosts schlagen dann mit 17–20 % mehr zu Buche, Logs mit bis zu 50 %.³

Wünschenswert wäre stattdessen automatische Skalierung ohne Aufschläge im Falle von saisonalen Traffic-Spikes und nicht planbaren Workload-Spitzen – für jede Preiseinheit.

Integriert sein sollten im Sinne der Planbarkeit zudem Möglichkeiten zur Abfrage, zum Tracking und Alerting rund um abrechnungsspezifische Daten. Übersteigt die Datennutzung etwa einen monatlichen Gigabyte-Threshold, muss dafür ein automatischer Alert definierbar sein. Doch nicht alle Observability-Technologien bieten diese Tools, manche nur in abgespeckter Form. Eine genauere Prüfung ist hier also lohnenswert. Was aber, wenn die Frage von Kontingenten, Traffic-Peaks und Aufschlägen komplett hinfällig wäre?

Bei verbrauchsbasierten Preismodellen müssen Sie sich nicht vorab auf langfristige Datenkontingente festlegen. Auch Aufschläge bei Mehrverbrauch fallen nicht an, und die Frage nach Shelfware stellt sich aufgrund ihrer Flexibilität ebenfalls nicht. Weit weniger Aufwand vorab also, entfällt doch die mühsame Kontingent-Jahresplanung, und keine unliebsamen Budgetüberraschungen obendrein.

Freeze der Monats- oder Jahreskosten auf Peak-Niveau

Weiter will berücksichtigt werden, wie saisonal zyklische Hochphasen, Canary Deployments (bzw. Blue/Green-Deployments) und Traffic-Spikes berechnet werden. Einige Observability-Anbieter wie Datadog⁴, Elastic⁵ und Splunk⁶ verankern die Kosten hier auf Peak-Niveau statt auf Grundlage Ihrer eigentlichen Nutzung. Doch Veränderungen in der Kundennachfrage beeinflussen auch maßgeblich die Infrastrukturskalierung. So gestaltet sich dieses Benchmarking alles andere als kundenfreundlich, kann es doch mit einer Verdopplung Ihrer Kosten einhergehen. Eine ungewollte Strafe für Geschäftserfolge umso mehr, wenn etwa rund um die Weihnachtsfeiertage mehr Traffic über Ihre Frontend-Anwendungen läuft. Warum für Peak-Nutzung bezahlen, wo keine Peak-Nutzung ist? Verbrauchsbasierte Modelle sind hier erneut fairer.

Wichtige Features in überdimensionierten Bundles

Bei SKU-Bundles sollten Sie gut darauf achten, ob Sie nicht vielleicht auch unfreiwillig ganze Feature Sets für mehrere Use Cases mit erwerben, die für Sie nicht oder nur sehr untergeordnet relevant sind. Application Performance Management (APM) ist Ihnen wichtig, wird aber verpflichtend begleitet vom Abonnement für Infrastruktur-Monitoring? Das ist keine Ausnahme. Beispielsweise ist bei Datadog Infrastruktur-Monitoring für jeden zahlungspflichtigen APM-Host erforderlich – so steigen Ihre APM-Kosten relativ zu den Ausgaben für Infrastruktur-Monitoring.⁷

Konstante Forecast- und Vertragsanpassungen für über 16 SKUs

Abgesehen von New Relic setzen alle großen Observability-Anbieter auf SKU-Bundles. Zusammengefasst werden dabei bis zu 20 unterschiedliche Infrastruktur- und servicebasierte Preiseinheiten wie Hosts, Agents, Nodes und CPU-Kerne. Häufig zudem als Monatsvolumina, deren nicht genutzter Anteil verfällt. Ihre benötigten Kontingente müssen Sie dabei basierend auf Ihren bestehenden Daten prognostizieren. Dieses Vorgehen kann sich speziell vor dem Hintergrund schnellen Wachstums als problematisch erweisen.

Wird dieser ohnehin schon komplexe Prozess auch noch von überraschenden Aufschlägen begleitet, löst dies erst recht keine Begeisterungsstürme aus. Denn auch hier gilt: Übersteigt Ihre monatliche Nutzung Ihr Kontingent, erwarten Sie Aufschläge. Und so können schon wenige Stunden an zusätzlichem Traffic für eine Verdopplung Ihrer monatlichen Kosten sorgen.

Weiter gilt zu bedenken, dass sich Anwendungen auch fortlaufend weiterentwickeln: Neue Technologien werden eingebunden, Cloud-Migrationen durchgeführt, aus großen VMs werden kleine, aus VMs werden Kubernetes-Cluster, aus Kubernetes-Clustern wiederum Container und aus Containern Serverless-Funktionen. Mit diesen Änderungen an Ihren Anwendungen und Komponenten von Sprint zu Sprint geht bei SKU-Bundles auch die Notwendigkeit einher, immer wieder neue Forecast- und Vertragsanpassungen durchzuführen. Eine enorm zeitaufwendige Aufgabe für die meisten Teams. Die Folge: Viele Observability-Kund:innen sehen sich mit immer neuen unerwarteten Aufschlägen konfrontiert und müssen immer umfassendere Kontingente bei ihren Anbietern buchen. Hier bietet sich stattdessen vielmehr ein Preismodell an, das auf statischeren Preiseinheiten wie Benutzer:innen basiert.

New Relic etwa bietet Ihnen ein All-in-One-Preismodell, in dessen Rahmen Sie alle unserer über 30 Toolsets flexibel nach Ihren Anforderungen nutzen können. Dies ganz ohne Aufschläge oder komplexe, immer wiederkehrende Forecasting-Übungen.

Daten- und Kostenexplosionen

Daten sind die wichtigste Kostenvariable im Observability-Pricing. Beim Wechseln von On-Prem hin zu einer Cloud-Infrastruktur und Microservices besteht Ihr Stack womöglich aus hunderten kleiner Programme statt einer Handvoll großer. Hieraus ergibt sich eine zumeist zwei- bis zehnfache Zunahme bei den Telemetriedaten. Alle zwei bis drei Jahre kann es hier zudem zu einer weiteren Verdopplung kommen. Eine wahre Datenexplosion also mit unter dem Strich hohen Netzwerk-, Speicher- und CPU-Kosten.

Allgemein problematisch ist hierbei, dass Log-Volumina bei der Kostenprognose nicht antizipierbar sind. Bei Datadog etwa können die Kosten für Log-Management basierend auf System- und User-Load und unerwarteten Kostenänderungen leicht gewaltig in die Höhe schießen. Zur Anwendung kommt hier eine recht komplizierte Formel zur Log-Nutzung, die in 2,50–3,75 US-Dollar Zusatzkosten je 1 Million Logging-Events mit 30 Tagen Retention resultieren kann. Bei einem Durchschnitt von 1,5 bis 2 GB je 1 Million Events entspricht dies 1–2,50 US-Dollar pro GB – deutlich mehr als 0,10 US-Dollar je erfasstem GB wie von Datadog kommuniziert.⁸ Bei Splunk schlagen Logs mit ca. 4 US-Dollar je GB zu Buche.^{9 10} Elastic berechnet pro Server im Elasticsearch Cluster. Mehr Daten bedeuten hier mehr Elasticsearch Server.¹¹ Eine Verdopplung der erfassten Daten kann also in exakt dem gleichen Maße Cluster-Größe und -Kosten erhöhen.

Zukünftige Cloud-Nutzung und -Erweiterung werden mit einem Observability-Anbieter mit niederschwelligen Kosten je GB also um ein Vielfaches tragfähiger.

Um die Menge an erfassten Daten und die zugehörigen Kosten zu reduzieren, sollten Data-Dropping-Regeln konfigurierbar sein, die potenziell sensible Datenpunkte und solche von geringem Wert herausfiltern.