Finding the right software components for your project

The need of sub-systems in software projects

If you look at large open source software projects nowadays, most of them do not consist of a monolithic front- and backend, but rather of many interfitting building blocks of individual software, which interacts with off the rack software components. Whether and which kind of building blocks must be used in new software projects, can be derived mostly from the quality attributes, e.g. on the basis the ISO/IEC 25010. But what is the next step when you know which kind of software you need? And how do I know which software is available on the market for which case?

One thing is certain: There is no general toolbox or template that can always be used. However, one strategy has proven itself in my work and I would like to present it to you today.

Apache Project List

After I have divided the project into smaller systems, I first consider which systems are already being used in my company To approach the topic a bit more practically, let's construct an example. The target system needs a message broker. The company's strategy specifies that, if possible, only cloud software should be used for new projects, a so-called cloud first strategy. My first port of call for such questions is usually the Apache Project List. Projects from the Apache Software Foundation are usually open source and published under the Apache license. Accordingly, there are no license fees, so it's a good starting point for initial research.

Since not every Apache product name is immediately obvious to me, I use the filtering by category. This way I get a list of potential projects and can choose the most suitable one. In the case of the Message Broker, the category "network-client" contains "ActiveMQ" as a product. Of course, I have already heard about ActiveMQ and used it in projects, but this step is first about finding suitable candidates for our portfolio. Since ActiveMQ meets our requirements, I look for alternatives and come across RabbitMQ pretty quickly. So I include it in our selection catalog as well.

ThoughtWorks technology radar

There are many good products in the Apache Project list but they do not guarantee state of the art systems and may be a bit from the trend. Thankfully an expert committee at ThoughtWorks offer a tech radar that is being updated every now and then and gives a good overview of different techniques, tools, platforms and languages/frameworks. Blips, the points representing an entry, from the adopt and trail ring can be a good starting point for further research. As time goes by, many blips in these two rings are also cloud first offerings.

Looking at Cloud

Since the requesting company has chosen a cloud-first strategy, it now becomes interesting to find a comparable solution on AWS, Azure and in the Google Cloud.

Azure offers the Azure Service Bus. At Google, the product is called "Pub/Sub" and AWS offers us the Amazon Simple Queue Service (SQS) and Simple Notification Service (SNS), two similar but technically different products. In addition, on AWS we also find the AmazonMQ service, which is a managed Apache ActiveMQ solution.

We have now identified two established but different open source solutions (ActiveMQ, RabbitMQ), four cloud first solutions and one interesting hybrid, for a total of seven candidates so far.

Alternatives

But what if we have forgotten something? Another good place to start is Docker Hub. There are verified images, which provide some pre-qualification for us. When searching for the term "broker", we are thus made aware of eclipse-mosquitto which is an MQTT broker. We also find the officially verified rabbitmq image, which would make it relatively easy to run RabbitMQ in the cloud as well, for example in a container runtime PaaS-Environment.

Every broker has advantages and disadvantages. So does its operating model, which is why I don't want to go further into the decision-making process in this article, or even make a recommendation.

Conclusion

The procedure for finding suitable candidates for message brokers, for example, can be replicated to any other service. Often, the differences in software products are what crystallize the important decision factors in the first place, which is why it is important to perform a good pre-qualification.

This process is intended to show how to work through the jungle of different software sources as efficiently as possible.