Selecting your orchestration conductor

When we are integrating different components and services in our software architecture, the first step is to select a good orchestration framework. On this opinionated article I will present my criteria to decide which is the right framework.

Riding the Enterprise Service Bus

As you compose services, you will notice the need for an Enterprise Service Bus to communicate with each other. But an EBS can be useless if you don’t have good ETL (extract, transform, load) tools along with it to manipulate our data. The same way that an ETL without a proper routing system can leave us orphaned.

We need to route messages and events and at the same time make sure data transformations take place so different endpoints with varied protocols and formats can interact with each other. That’s where integration frameworks come in.

The Enterprise Integration Patterns can help developers on both tasks: by providing data transformations between outputs and inputs and offering different routing strategies.

Orchestration Functionality

Our framework should be able to support not only the Enterprise Integration Patterns, but also a wide range of protocols and data formats.

Read more: Selecting your orchestration conductor

Usability

Easiness of use, specially if we have complex use cases to maintain, is relevant to keep our architecture clean. This usability should never be in detriment of the functionality or the extensibility of the framework. We want our framework to interact with a varied range of components and services.

Sacrificing features in favor of user experience will make you hit faster the ceiling of what you can do.

Multiple Orchestration Languages

Related to the easiness of use is the language we need to use to build the integration routes. We don’t want to be tied to a specific language like Java or Python. There are frameworks that allow you to build the integration route in different languages.

When our orchestration builders come from different backgrounds, or are not very tech savvy, being able to integrate on different languages may come in handy. We want them to feel comfortable in whatever language they need to orchestrate.

Tutorials and documentation

It was never the case when good usability made up for a bad documentation. We need tutorials, manuals, helpers,… Both for users and developers. And of course, we will want to have some reference to fall back when something doesn’t work as expected and we need to find why.

Customization

Sometimes we need to use some data format or connect to some service not currently supported by the framework. Whether if we do it ourselves or hire someone to do it, can the existing functionality be extended to support them?

Dependencies size

We don’t want to drag a heavy dependency to our architecture. But not only smaller in size, we also want a framework that will use a light footprint over our hardware, while at the same time, it doesn’t drag our performance.

A smaller dependency usually means less source code that can introduce bugs to your software too.

Technical Support

Maybe we don’t need help, but what if we have a problem? Can we hire someone for technical support? Are there developers to hire to implement our custom features?

Having a wide range of companies offering services around our framework will greatly improve our experience in the long run.

License

It doesn’t matter how many companies are supporting the framework if the license is restricted. Only a software with a FOSS license will warrant you will not be tied to the whims or misfortunes of any external force or private company.

If you have been following me, this will not come as a surprise. You know I already have a preferred choice that scores high on all these criteria: Apache Camel.