Terraform & früheres Tech-Erbe

Terraform, MongoDB, Hadoop und Scala stehen in meinem Technologie-Radar im Ring „Hold“. Das heißt nicht, dass ich diese Werkzeuge für schlecht halte oder nie damit gearbeitet hätte – im Gegenteil: Mit den meisten davon habe ich über Jahre produktiv gearbeitet. Sie sind bewusst zurückgestellt, und zwar aus zwei sehr unterschiedlichen Gründen.

Was „Hold“ in meinem Technologie-Radar bedeutet

Ein Technologie-Radar ordnet Werkzeuge nach Reifegrad ein: Adopt, Trial, Assess und Hold. Der Ring „Hold“ wird oft missverstanden, als stünde dort nur, was man ablehnt. Bei mir sammeln sich dort Technologien, die ich kenne und teils intensiv eingesetzt habe, die aber in meiner heutigen Arbeit keine aktive Rolle spielen. Entscheidend ist das Warum – und das ist bei Terraform ein völlig anderes als bei MongoDB, Hadoop und Scala.

Terraform: bewusst zurückgestellt zugunsten von AWS-first

Terraform habe ich produktiv eingesetzt, unter anderem bei Audi und in Kundenprojekten bei codecentric. Das Ziel war dasselbe, das Infrastructure as Code immer verfolgt: Infrastruktur als versionierten, überprüfbaren Code beschreiben, statt Server, Netzwerke und Berechtigungen manuell zusammenzuklicken. Reproduzierbare Umgebungen, nachvollziehbare Änderungen und Code-Reviews für Infrastruktur – diese Vorteile haben mich damals überzeugt und überzeugen mich bis heute.

Trotzdem steht Terraform heute auf „Hold“. Der Grund ist eine Strategieentscheidung: Ich arbeite nach dem Prinzip AWS-first, wie auf der Seite Cloud & Infrastruktur beschrieben. Seit über zehn Jahren bewege ich mich tief im AWS-Ökosystem, und in meinen aktuellen Projekten gibt es keinen Multi-Cloud-Bedarf. Terraforms größte Stärke ist die Cloud-Unabhängigkeit – ein Werkzeug, eine Sprache für viele Anbieter. Wer diese Unabhängigkeit nicht braucht, bezahlt sie trotzdem: mit einem zusätzlichen Werkzeug, einem eigenen State-Management und einer weiteren Abstraktionsschicht zwischen Code und Cloud.

Deshalb setze ich bevorzugt auf AWS-native Werkzeuge wie CloudFormation. Sie sind direkt in die Plattform integriert, und ich muss keine zweite Toolchain pflegen, nur um eine Flexibilität offenzuhalten, die im Projekt niemand nutzt. Wichtig ist mir dabei die Abgrenzung: Terraform ist nicht vergessen, sondern zurückgestellt. Sobald ein Projekt tatsächlich mehrere Cloud-Anbieter kombiniert, wird Terraform wieder relevant – und die Erfahrung dafür ist vorhanden.

MongoDB: Dokumentmodell aus den Anfängen der NoSQL-Welle

MongoDB habe ich 2012 und 2013 über die ersten Online-Kurse von 10gen gelernt, dem Unternehmen hinter MongoDB: M101, M101J und M102. Inhaltlich ging es um das Dokumentmodell, Abfragen, Replikation und Sharding. Gerade die beiden letzten Themen – wie man Daten auf mehrere Knoten verteilt und trotzdem verfügbar hält – haben mein Verständnis verteilter Datenhaltung früh geprägt. Eine aktuelle Praxis mit MongoDB habe ich allerdings nicht, deshalb steht die Datenbank ehrlicherweise auf „Hold“.

Hadoop: Jahre im Big-Data-Maschinenraum

Hadoop war über viele Jahre mein tägliches Werkzeug. Als IT Consultant Big Data bei codecentric habe ich von 2014 bis 2017 mit dem Hadoop-Ökosystem gearbeitet, anschließend seit 2018 bei MAN Truck & Bus (aktuell D&A IT Spoke Lead), wo mein Einstieg als Data Engineer an einer Datenplattform war. Abgerundet wird diese Zeit durch die Zertifizierung als Cloudera Certified Developer for Apache Hadoop (CDH3/CDH4).

Heute betreibe ich keine Hadoop-Cluster mehr. Das liegt nicht daran, dass große Datenmengen aus meinem Alltag verschwunden wären – sondern daran, dass sich die Werkzeuge verschoben haben.

Scala: produktiv im Einsatz, nicht nur im Kurs

Scala habe ich nicht nur theoretisch kennengelernt. Der Einstieg war 2012 der Coursera-Kurs der EPFL bei Martin Odersky, dem Erfinder der Sprache. Produktiv eingesetzt habe ich Scala dann von 2014 bis 2018: auf der ACDC-Plattform bei Audi und in Kundenprojekten bei codecentric. Funktionale Programmierung auf der JVM, unveränderliche Datenstrukturen und ausdrucksstarke Transformationen über große Datenmengen – das passte damals hervorragend zur Big-Data-Verarbeitung.

Wichtige Abgrenzung: Big Data ist nicht zurückgestellt

An dieser Stelle lohnt eine klare Unterscheidung. Zurückgestellt sind die Werkzeuge Hadoop und Scala – nicht die Big-Data-Verarbeitung selbst. Aktuell verarbeite ich täglich mehrere hundert Terabyte an Daten. Nur geschieht das heute über AWS-Datendienste wie Amazon Athena, Amazon Kinesis und Amazon MSK statt über selbst betriebene Hadoop-Cluster und Scala-Jobs – mehr dazu auf der Seite Cloud & Infrastruktur: AWS-first.

Geblieben sind die Konzepte, die ich in dieser Zeit verinnerlicht habe: verteilte Verarbeitung, Datenlokalität, eine funktionale Denkweise und ein bewusster Umgang mit Fehlern in großen Systemen. Wer einmal erlebt hat, wie sich ein Job über Hunderte Knoten verteilt und warum einzelne Ausfälle dabei der Normalfall sind, entwirft auch Pipelines auf Managed Services anders.

Der rote Faden: zwei Gründe, eine klare Haltung

Beide Themenfelder stehen auf „Hold“, aber aus unterschiedlichen, jeweils klar begründeten Gründen:

Terraform ist eine bewusste Strategieentscheidung trotz vorhandener Praxiserfahrung. Das Werkzeug ist ausgereift und nützlich, seine Kernstärke – Cloud-Unabhängigkeit – wird in einer AWS-first-Umgebung aber schlicht nicht gebraucht. Ändert sich der Bedarf, ändert sich die Einordnung.

MongoDB, Hadoop und Scala sind älteres Tech-Erbe ohne aktuellen Projektbezug. Die Werkzeuge selbst nutze ich nicht mehr, doch die Konzepte dahinter prägen meine heutige Arbeit mit großen Datenmengen auf AWS weiterhin.

Für mich ist das der Kern eines ehrlichen Technologie-Radars: nicht nur zu zeigen, was gerade im Trend liegt, sondern auch offen zu begründen, warum ich bestimmte Werkzeuge im Moment nicht einsetze – und unter welchen Bedingungen sie wieder relevant würden.