Connect everywhere with Serverless Integration

Abstraction of infrastructure for developers with the help of an Enterprise Integration Pattern (EIP) and 300+ built-in components.

Cloud-native but can also integrate with classic (legacy) applications. Provides consistent experience with on-premise and hybrid deployments.

Reduces horizontal scaling costs with automatic scaling. Helps developers avoid random, arbitrary predictions.

Operator patterns minimize effort in many phases of the application lifecycle, including building, deploying, and configuring.

Event-driven architecture (EDA) nature handles best with the fluctuating flow of events/data and failure isolation. The application can be implemented in a more modular way.

Cuts time to market significantly. No more complicated build and deploy processes to roll out new features. Gives developers a quicker turnaround.

Serverless integration is always event-driven. The application is either a consumer or a publisher of the events. The initial events predominantly come from sources that trigger changes, and the states are broadcast across systems. It orchestrates the event if needed with external sources, or retrieves events from the event mesh to transform or process the payload.

The majority of integration applications are stateless, and you'll want to keep them that way. A highly distributed, loosely coupled environment demands free scaling and the ability to run multiple instances in parallel. The best practice is to just keep the application reactive to states, not store the state. Doing so will prevent future problems. States should be managed at a higher business level.

Breaking the integration into small modules will help to optimize resource usage, and keeping the integration nice and small will allow faster boot time at its initiation. Plus, the integration will be easier to maintain in the future.

Typically, collectors do source to sink, converts none cloud events into one, and passes it to the system. They don’t do a lot of processing, keeping them simple is the key.

Like any event-driven architecture, not all consumers are created equal. There's always a need to orchestrate events and do content routing. With connectors, developers can filter unwanted parts in the payload for more efficient processing. Aggregating or splitting content helps manage these events and send them to the right consumer in the right format.

Typical business process tasks, that is more CPU bound, or web/API front end handling user requests. These change quite frequently so managing the revision is the key.