Comparison of ESB solutions that are popular on the Russian market

The winner in the competition is the one who can quickly scale, quickly implement partnership projects and invest a minimum of money in growth. The traditional view of integrations is diametrically opposed to these priorities. The timing and cost of implementation are unclear, the effect is unpredictable, and instead of the expected advantage, there is uncertainty.

The low-code paradigm is much closer to business priorities. Software that works in this paradigm makes it possible to accelerate the development and implementation of new systems, integrations and features significantly.

One of the products that work in the low-code paradigm is ESB system (abbreviated from English enterprise service bus, Russian. “enterprise service tire”). ESB is a suite of software that works as a single center for exchanging messages between information systems and applications. The service bus makes it easy to configure message routes, stores the history of messages, and records the path of each of them.

ESB does not require complex and time-consuming development every time it is necessary to connect systems that were not originally designed to work together. Moreover, most of the work is provided by visual development tools. When integrating, business analysis is the main thing, rather than the technical aspects of this integration.

ESB is not a monolithic system, but a layer in the company's IT infrastructure that consists of several products. Each of them takes on one or more of the functions of a service tire. In this article, we will break down the ESB layer into functions and explain how these functions are implemented in products that are popular on the Russian IT market.

What does the ESB layer consist of?

ESB is roughly divided into five components or functions: studio, message broker, logging, monitoring, and hosting.

1. Studio — a graphical environment for developing quick integrations. The systems, parameters and actions are visualized and are as clear as possible. The studio's functionality is enough for most of the actions, such as transmitting and receiving information, transforming and collecting attributes from one stream to another. Here you can also set the parameters that the ESB bus should monitor, consider an integration error, etc. If the integration requires a unique action, you can write it in a couple of lines in traditional languages (for example, Java) or specially developed ones.

Without a studio and, accordingly, without visualizing integrations, ESB cannot be considered a low-code solution.

‍

2. It is used to exchange messages between systems message broker. This is an active component that “picks up” and “gives” messages, keeps them in order and eliminates the load on the systems that generate and receive messages (the so-called producer and consumer). Developers often make the mistake of calling an ESB system a message broker, such as Apache Kafka or RabbitMQ.

‍

3. Logging is a record of everything that happens to the message. Which system generates it, how it is processed, where it ends up (or doesn't) end up. Logging allows you to clearly understand whether the message is moving along a given route and at what stage and why the problem occurred.

‍

4. Important events that happen with messages and queues are necessary monitor and work it out in time, responding to them. The monitoring component allows you to specify events that need to be responded to and report them to support.

Each ESB solution offers several accommodation options to choose from. For example, some systems allow you to publish the integration to the Kubernetes, OpenShift, Amazon private cloud without any configuration at all. Publishing within your unique cluster will require the work of an architect.

In this article, we'll look at how ESB components are implemented in solutions that are most often offered on the Russian market: Talend, Mule, WSO2, Red Hat Fuse. Sometimes developers add message brokers to the list Apache Kafka (plus Kafka Connect) and RabbitMQ, but these two solutions are not ESB and it is not advisable to consider them as part of this analysis.

Studio

‍

Message Broker Support

None of the systems have internal message brokers. But the “box” contains connectors that support the simple integration of external message brokers. The connectors are systematized and included in manuals.

How logging is organized

As you can see, internal logging in ESB systems is implemented almost identically — with minor features that are specific to each product.

Additionally, logging is provided in external systems that are connected via connectors. A business analyst must write down key events as part of the integration so that reports about these events are logged.

Logging in an external system gives ESB additional flexibility. Most likely, an enterprise-scale business already has a logging component in its IT architecture, and the systems will not duplicate each other's functions.

Monitoring

Event monitoring is sent to external systems through a universal component. The monitoring system can be any of those that are convenient for the operation department: Checkmk, Prometheus, Zabbix, etc. The business, together with developers, is creating a manual that describes the metrics that need to be monitored, acceptable and unacceptable deviations, as well as the actions necessary to correct the situation.

The cost of licenses

Resume

Talend, Mule, WSO2 solve the problem of integration speed and comply low-code paradigm→.

Red Hat Fuse is similar in functionality to the previous three products, but it can no longer be considered a low-code solution: even ordinary operations require a developer. However, it maintains the principle of self-documentability.

Apache Kafka and RabbitMQ are not ESB systems but message brokers. They are not enough to create a full-fledged ESB layer; they do not offer any advantages in terms of simplifying integrations and scaling, but they can also become part of the ESB layer.

It is clear that each implementation is individual and should take into account the specifics of the business, product and IT strategies. But among the existing solutions, low-code is the fastest way to carry out digital transformation, scale, and integrate with partners. Therefore, for companies that are interested in rapid growth with the associated optimization of development costs, we recommend low-code solutions: ESB, BPMS, CRM.

Let us separately note that the very implementation of low-code ESB does not happen instantly. Like any large-scale integration, it takes time and resources: costs for the development team, servers (if necessary), etc. In this regard, low-code solutions are no different from the usual ones. Development savings begin only after they are implemented.

‍