Choosing Your Technology Stack

Having trouble choosing your technology stack for your next software project? In order to help you in this process, I thought I would share a three-part series rationalizing the ‘technology stack’ that was used on Missing Link Technologies’ Prescriptive Decision Support System (PDSS) Project.

This IRAP funded project consisted of the following modules:

• Core Acquisition Services

• Core Data Services

• Administration and Reporting Web Services

• Data Analytics Pipeline and Big Data Services

I encourage you to take notes from our experience to help you choose the best technology stack for your upcoming project.

Part One

In this article, I will be focusing mainly on Core Services and how the ‘first level’ technology stack was chosen.

1. Define Highest Level Core Deliverables/Objectives

• Must Run on Small Hardware such as Rasp. Pie

• Must Run on Linux and Windows Operating System

• Must be runnable in Cloud and scale both horizontally and vertically

• Must be runnable in hybrid Cloud {public + private}

• Support for leveraging key Apache Foundation Software

  • Must be of ‘Enterprise Quality’ - Centralized build - Automated execution of Unit Tests - Continuous Integration - Artifact versioning {Publishing and Retrieval}

• Strongly typed language with clearly defined abstractions

• Supports implementation of SOLID principles

• Relatively easy to deploy

• Minimize licensing costs

• Provide good optics for company {external partners/academia}

• Extensible with a clear pathway for handling fringe cases.

• Supports creativity and experimentation without introducing unnecessary risk.

• Able to implement stated business requirements.

2. Reflective Thinking

The first thing to notice is that the deliverables/requirements that I’ve listed are contextually relevant to my role as Chief Software Architect. My primary objectives are to ensure that our technology choices are fundamentally sound and contribute to satisfying the stated objectives.

The developer in me wants to list things like tail recursion, implicitly typed variables, all exceptions are unchecked, of instead of instance of…. but these nice to haves do not really contribute to stated objectives. Having said that, I am sympathetic to developers as 50+ % of my work hours are still devoted to writing software. For what it’s worth I will do my best to keep things progressive and interesting in other areas of development!

3. Technology Stack Part 1 – Decision Time

This is perhaps the easiest decision to make. In my professional opinion, the only 2 valid choices for enterprise server-side development are Java and C#. One could make a case for C++ and VB.Net but they were immediately discarded as not being relevant.

This winner is Java Open JDK 1.8!

Bummer, as C#, especially DotNet Core 3.0 is a superior development experience….is like Java + Maven but better and gone are atrocious project file, solution file, and confusing NuGet package junk. I also much prefer using the free visual studio code over the heavy and clunky Visual Studio for Professionals.

The rationale for choosing JAVA Open JDK 1.8:

• By far best support for Apache APIS

• Great driver for Maria DB

• JDK Runs great on Raspbian

• Alpine Image for Docker is top-notch

• It is a better language choice for Academia. {this is changing though}

• Statically Typed Language

• Junit + Maven + JFrog + Git Lab is rock solid.{msbuild users never complain about maven}

• Configuring Apache Stuff prepares you for configuring Kubernetes stuff

• Encourages use of Linux Operating System

• Simplifies runtime requirements as many supporting services are written in Java as well

• Free IntelliJ IDE is quite good.

• Can program in Scala and Kotlin which compiles to java byte code

Identified Risk Areas

Oracle’s new JDK licensing model may be problematic but MLT should be ok if we do all development, testing and production releases using OPEN JDK 1.8

Developer complaints

Stay Tuned for Part 2

In Part 2 of this series where I’ll define the next level of technical requirements such as which database technology(ies), MQ, DI container that we are going to use within our growing technology stack.

Jeff Carter

Chief Software Architect

Missing Link Technologies

Find this article on published on LinkedIn