Tolles Projekt

Bei der Financial Times senken Container die Server-Kosten um 80 Prozent

| Autor / Redakteur: Dr. Dietmar Müller / Ulrike Ostler

Aus der Präsentation von Sarah Wells, Financial Times, „Switching horses midstream: the challenge of migrating 150+ services to kubernetes“
Aus der Präsentation von Sarah Wells, Financial Times, „Switching horses midstream: the challenge of migrating 150+ services to kubernetes“ (Bild: Sarah Wells)

Container und deren Orchestrierung sind aus der Anwendungslandschaft nicht mehr wegzudenken – bei der „Financial Times“ konnte die Containerisierung der weltweiten Medienproduktion und -bereitstellung rund 80 Prozent der Kosten für Server einsparen. Überhaupt scheint die neue Technik viele Vorteile zu haben.

Neue Technologien folgen in der Regel der Hype-Kurve – zunächst werden sie hochgelobt, dann werden die Anwender durch den tatsächlichen Einsatz ernüchtert, schließlich wird das Verfahren irgendwann zur Commodity. Im Falle von Containern scheint dies nicht mehr zu stimmen: Auf den Hype folgt direkt der Erfolg, ganz ohne Ernüchterung.

So jedenfalls sieht es Sarah Wells, Technical Director bei der weltweit bekannten Financial Times (FT). In ihrer Keynote auf der KubeCon/CNCFCon in Kopenhagen, stellte sie das nunmehr operative Projekt vor. Das in London ansässige Wirtschaftsmagazin konnte ihren Angaben zufolge durch die Einführung von Containern 80 Prozent der Server-Kosten einsparen.

Sarah Wells: „Ich habe nie zuvor Entwickler gesehen, die glücklich über die Stabilität ihrer Code-Base waren. Nun kenne ich so etwas.“
Sarah Wells: „Ich habe nie zuvor Entwickler gesehen, die glücklich über die Stabilität ihrer Code-Base waren. Nun kenne ich so etwas.“ (Bild: Sarah Wells)

Und das kam so: Die FT, zu der neben der gedruckten Zeitung auch die „Website FT.com“ sowie die Töchter Financial Publishing, FT Chinese, Medley Global Advisors (MGA) und FT Labs gehören, hatte 2015 jede Menge Server in der AWS-Cloud belegt. Dazu muss man wissen, dass auch im News-Geschäft Daten das neue Öl sind: Sowohl das Management als auch die Redakteure des Magazins nutzen die Analyse von Kundendaten, um neue Produkte und deren Preise anzuvisieren, das Marketing auszurichten und zu entscheiden, welche Themen im nächsten Heft behandelt werden sollen. Dazu wird im großen Stil Business Intelligence (BI) eingesetzt.

„Wir sind ja keine Zeitung im klassischen Sinne mehr“, so Wells vor den damaligen Zuhörern. „Die meisten Leser haben wir online. Sie können sich also vorstellen, wie wichtig Technologie für uns und unseren Erfolg ist.“ Die zentrale Content-Plattform der FT wird gleich von vielen verschiedenen Content Management Systemen (CMS) gespeist und ist an Komplexität kaum zu toppen, berichtete Wells.

Datenwachstum zwingt zum Hosting

Nachdem das Datenwachstum bereits mehrere Umstiege auf jeweils neue, größere und auf Microsoft-Stacks basierende Data Warehouses provoziert hatte, wurde Hosting und Verwaltung an einen Drittanbieter, nämlich AWS, abgegeben. „Unsere Datenmengen sind in der Vergangenheit sehr viel stärker gewachsen, als wir erwartet hatten – und es geht vielleicht ewig so weiter“, so John Kundert, Leiter der BI-Abteilung bei FT. „Uns war klar, dass wir eine skalierbare Lösung brauchen, die mit uns wächst.“

Das genutzte Angebot trug die Bezeichnung „Amazon Redshift“. Zu Testzwecken wurden die innerhalb von zwei Jahren gesammelten Daten zum Nutzerverhalten auf FT.com hochgeladen und ein Reporting-Tool hinzugefügt. Damit standen etwa zwei Milliarden Datensätze zur Verfügung, die jeden Klick auf FT.com erfassten.

„Das war super“, berichtete Wells, „neben horrenden Kosten für die Server galt es aber auch jede Menge Loggin-Tools zu verwalten, was die Admins an die Grenzen ihrer Belastbarkeit brachte“. Wieder musste eine neue Lösung her, zumal, wie Wells weiter erklärt, 2015 jeder einzelne Microservice auf einer Virtual Machine (VM) lief. „Das war reichlich ineffizient“, so die Managerin.

Container zeigen neue Wege auf

Das 2013 erstmals vorgestellte Docker wurde im Laufe des Jahres 2014 so populär, dass es Bestandteil des „Red Hat Enterprise Linux 7.0“ wurde. So entdeckte es auch das FT-Entwicklerteam. Es versprach sich durch einen Umstieg auf die damals noch neue Technologie einfacheres Management und kostenseitige Einsparungen. Das Problem: Zu dieser Zeit gab es noch kein Orchestrierungs-Tool für Docker, das Entwicklerteam der FT musste es sich selbst bauen.

Wells sagt: Die Containerisierung der Prozesse war neu aber eindeutig die neue Art der Cloudifizierung. Das war uns klar. Es gab keine Alternative. Eines der frühen Mängel war: Es fehlte eine Architektur. Heute bilden die Microservices die Architektur. Doch muss man keine Microservices haben, um von Containern profitieren zu können. Also konnten auch wir diese neue Art der Cloudifizierung nutzen, selbst wenn wir weder eine Architektur noch eine Orchestrierung a la Kubernetes hatten. Dazu gehörte es, dass die Anwendungen immer stabiler liefen und wir uns selber verbessern konnten.“

Der Erfolg

Der Erfolg stellte sich ein. Zwei Jahre später wurden 150 Microservices mit einem eigenen Tool verwaltet. Aber es gab ein Problem: Das Entwicklerteam, das 2015 Docker eingeführt hatte, bestand schon 2016 nicht mehr, die meisten Programmierer hatten den Arbeitsplatz gewechselt. Für Wells und ihr Team war das ein Riesenproblem, weil die Dokumentation unzureichend war „und wir niemanden mehr um Hilfe bitten konnten“, so Wells.

Die neuen Leute verstanden kaum, wie das selbstgestrickte Orchestrierungs-Tool funktionierte. Das ebnete den Weg für die Einführung eines Werkzeuges von der Stange. „Neue Technologien sind spannend, aber wir sehnten uns nach etwas ‚Langweiligem‘, das bereits von vielen Leuten genutzt wird“, berichtet Wells. Kubernetes geriet in das Blickfeld.

Da das Werkzeug Open Source ist, hatte man nur geringe Berührungsängste so Wells. Eine Bewertung fiel positiv aus, zudem zeichnete sich damals schon ab, dass sich Kubernetes zu einem quasi-Standard entwickeln wird.

Kubernetes nimmt viel Arbeit ab

„Mit Kubernetes konnte der Container-Stack aus 150 Microservices auf lediglich acht große VMs konsolidiert werden – was Kosteneinsparungen in Höhe von 80 Prozent bedeutete“, so die Technikchefin. Sie weiß aber auch von Blut, Schweiß und Tränen zu berichten, die die Umstellung mit sich brachte. „Es war, als ob man in einem reißenden Fluss die Pferde wechselt“, beschrieb sie die Situation in ihrem Vortrag. Aber bei der Einführung neuer Technologien müsse man eben beherzt vorgehen.

Und angesichts der in Aussicht gestellten Vorteile musste der Umstieg einfach sein. Einer der Vorteile bestand darin, dass man sich bei der FT nicht mehr um die Maintenance des kompletten Systems kümmern würde müssen. „Warum sollten wir etwas selbst pflegen, wenn es als Produkt verfügbar ist?“ Sie setzt hinzu: „…zumal wir kein Cluster-Orchestrierungs-Unternehmen sind. Unser Geschäft sind Nachrichten“, und weiter: „Den Strom beziehen wir auch, dafür bauen wir kein eigenes Kraftwerk.“

Hürden beim Umstieg

Der Umstieg gestaltete sich dennoch nicht problemlos, „es galt einfach zu viele Entscheidungen zu treffen“, so Wells – und das bei zwei voneinander getrennten Systemen. Denn vor der tatsächlichen Konsolidierung auf acht Server liefen zwei Systeme parallel – das alte, mit einem Microservice pro VM, sowie das neue, mit Kubernetes orchestrierte. Alleine der stetige Abgleich des Contents in den beiden Systemen sei zum Haare raufen gewesen, so die Technikchefin. Sie habe sich in der „Merge-Hölle“ befunden, die mit viel verlorener Zeit und Kosten verbunden gewesen sei.

Ihr heutiger Tipp: Sich nicht zu lange mit dem Testen von Code aufhalten. „Programmierer, gerade wenn sie frisch ‚Go‘ gelernt haben, tendieren zum Perfektionismus“, erörtert Wells. „Sie werden praktisch nie endgültig fertig.“

Für das FT-Containerisierungs-Projekt aber galt schließlich – „Nach einem kleinen Bug in den APIs, der uns viel Zeit und Nerven gekostet hat“ – war der Umstieg geschafft. Als Belohnung war die Content-Plattform nun viel stabiler als vorher, auch aufgrund der Orchestrierungsplattform. Zweimal sei das System in den Monaten nach dem Go-life abgeschmiert, „aber Kubernetes hat das Problem selbst aus der Welt geschafft, und zwar schneller, als unser Team seine Laptops aufklappen konnte“.

Wells schließt: „Ich habe nie zuvor Entwickler gesehen, die glücklich über die Stabilität ihrer Code-Base waren. Nun kenne ich so etwas.“

* Dr. Dietmar Müller ist freier Journalist und lebt in Niederbayern.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45379130 / Anwendungen)