Terraform & Legacy Tech

Build · Hold

Terraform, MongoDB, Hadoop and Scala sit in the “Hold” ring of my technology radar. That doesn’t mean I think these tools are bad or that I’ve never worked with them. The opposite is true: I used most of them productively for years. I’ve put them on hold on purpose, and for two very different reasons.

What “Hold” means in my technology radar

A technology radar sorts tools by maturity into Adopt, Trial, Assess and Hold. People often misread the “Hold” ring as a list of rejected tools. In my radar it holds technologies I know, some of which I used heavily, that don’t play an active role in my work today. What matters is the reason, and for Terraform that reason is completely different from the one for MongoDB, Hadoop and Scala.

Terraform: on hold by choice, in favor of AWS-first

I used Terraform in production, including at Audi and in codecentric client projects. The goal was the one Infrastructure as Code always has: describe infrastructure as versioned, reviewable code instead of clicking servers, networks and permissions together by hand. Reproducible environments, traceable changes and code reviews for infrastructure won me over back then, and they still do.

Even so, Terraform is on “Hold” today because of a strategy decision. I work by the AWS-first principle described on the Cloud & Infrastructure page. I’ve worked deep in the AWS ecosystem for more than ten years, and my current projects don’t need multi-cloud. Terraform’s biggest strength is cloud independence: one tool and one language for many providers. If you don’t need that independence, you still pay for it with an extra tool, separate state management and one more layer of abstraction between your code and the cloud.

That’s why I prefer AWS-native tools such as CloudFormation. They are built into the platform, and I don’t have to maintain a second toolchain just to keep options open that nobody on the project uses. One distinction matters to me here: Terraform isn’t forgotten, it’s on hold. As soon as a project really does combine several cloud providers, Terraform becomes relevant again, and I have the experience for it.

MongoDB: the document model from the early days of the NoSQL wave

I learned MongoDB in 2012 and 2013 through the first online courses from 10gen, the company behind MongoDB: M101, M101J and M102. They covered the document model, queries, replication and sharding. The last two topics in particular, how to spread data across multiple nodes and still keep it available, shaped my understanding of distributed data storage early on. To be honest, though, I don’t use MongoDB in my current work, so the database is on “Hold”.

Hadoop: years in the big data engine room

For many years Hadoop was a tool I used every day. From 2014 to 2017 I worked with the Hadoop ecosystem as an IT Consultant Big Data at codecentric. Since 2018 I’ve been at MAN Truck & Bus (currently D&A IT Spoke Lead), where I started as a Data Engineer on a data platform. I also earned the Cloudera Certified Developer for Apache Hadoop (CDH3/CDH4) certification during that time.

I no longer run Hadoop clusters today. That’s not because large data volumes have left my day-to-day work. It’s because the tools have changed.

Scala: used in production, not just in a course

My Scala knowledge goes beyond theory. I started in 2012 with the EPFL Coursera course taught by Martin Odersky, who created the language. I then used Scala in production from 2014 to 2018, on the ACDC platform at Audi and in codecentric client projects. Functional programming on the JVM, immutable data structures and expressive transformations over large data sets were a great fit for big data processing at the time.

An important distinction: big data is not on hold

A clear distinction is worth making here. Hadoop and Scala are on hold as tools, but big data processing itself is not. Today I process several hundred terabytes of data every day. I just do it with AWS data services such as Amazon Athena, Amazon Kinesis and Amazon MSK instead of self-managed Hadoop clusters and Scala jobs. More on this on the Cloud & Infrastructure: AWS-first page.

The concepts I absorbed during that time have stayed with me: distributed processing, data locality, a functional mindset and a deliberate approach to failure in large systems. Once you’ve seen a job spread across hundreds of nodes, and learned why individual failures are normal in that setting, you design pipelines on managed services differently too.

The common thread: two reasons, one clear stance

Both areas are on “Hold”, for different reasons, and each reason is clear:

Terraform is a deliberate strategy decision, even though I’ve used it in practice. The tool is mature and useful, but an AWS-first environment simply doesn’t need its core strength, cloud independence. If the need changes, the rating changes.

MongoDB, Hadoop and Scala are older tech legacy with no link to my current projects. I no longer use the tools themselves, but the concepts behind them still shape my work with large data volumes on AWS today.

For me, that is the heart of an honest technology radar. It doesn’t just show what’s trending. It also explains openly why I’m not using certain tools right now, and under what conditions they would become relevant again.