Integration Architecture Best Practices for Enterprise Applications

Question

Our application will integrate as a consumer into a bunch of external systems.

Most of these integrations are more than just message processing and routing. There is a lot of complex logic, for example, maintaining the current state, planned executions, and other things.

In addition, each integration does not have a common logic.

What is the best practice for creating such systems?

Should I build an all-in-one integration layer? It can be a monolithic application with different routes and apache processors for each integration:

Or should I split it up into a bunch of tiny and simple standalone applications so that they can be scaled and deployed independently?

What advantages and disadvantages can I get with every solution?

Answer 1

There are quite a few criteria to keep in mind:

• Economics : project cost, operating costs
• Throughput : data volume at a time
• Delay : message travel time
• Security : data protection
• Reliability : probability of failures
• Flexibility : easily respond to changing requirements
• Process support : data flow control, event / error handling

The choice of architecture for a good solution depends on the importance of such criteria for a given IT environment. For enterprise applications, it is quite common to use an integration platform instead of building integration logic in applications. Such a platform typically includes components for connecting, displaying messages, routing, monitoring / alerting, logging, accounting, change management, etc.

Set your favorite search engine for Integration Templates or Enterprise Application Integration .

Answer 2

Let me share my opinion. In general, as Axel Kemper said, there are many factors that can affect your decision, and there is no solution for a silver bullet.

I will try to keep it technical, so:

Monolithic application:

• Easier to deploy. In general, you only need one or more servers. From the developer's point of view, the difference may not be so obvious, but talk to your development team and they will immediately say that deploying one application is much easier for them.

• It is easier to control. Mostly for the same reason as above. Ask about it too :)

• It could be faster. If various integration applications need to connect in some way (although this is not indicated in your scheme), then they can potentially suffer from the slow "over-network" protocol. In a monolithic application, everything is inside a single JVM.

• Less servers are potentially required. If you are working in a private cloud or in some outdated environment, there may be a problem connecting a new server. You can get 2-3 servers for your application and what it is:

The architecture of “Multiple Integration Applications” (in my understanding, it really resembles the micro-service architecture in the integration domain) has the following advantages:

• It’s easier to upgrade different parts. If you have a monolithic application, there is no normal way to update only part of the API, there should be one big update for the entire application. If different "integration points" are developed by different teams, it is unclear to coordinate between releases.

• As a result of the previous bullet, it would potentially take less time to correct the error at the integration point (from the moment the error was detected until the correction was deployed during production). Just fix at one specific integration point and reinstall it. Its much easier.

• Scales "go out" better. If you are experiencing heavy use of a particular integration point, you can easily add another (or more) to another server. In a monolithic approach, you will need to install the entire application to achieve a similar effect. Another use case: if you are deployed in the cloud and you have a client who wants to pay for exclusive access to a specific integration point.

• Easier to test (maybe). If you use integration / system tests to test your integration point, you can organize a CI stream so that the system simply runs in parallel. Add to that a much easier start-up, and you get a much more flexible stream.

I may have missed some aspects of the comparison (of course), but this is the direction of IMO.

Hope this helps