Jetic this week emerged from stealth to launch a namesake integrated platform-as-a-service (IPaaS) offering based on open source Apache Camel software that runs natively on Kubernetes clusters.

Rather than attempting to, for example, deploy a monolithic enterprise service bus (ESB) in a container, Jetic is providing an iPaaS that makes it simpler to create integrations using the same declarative approach IT teams used to manage Kubernetes.

Jetic CEO Andre Sluczka said that approach makes it simpler for developers to create integrations without having to inject integration specialists within a DevOps sprint every time software components need to be integrated.

At the same time, the iPaaS takes advantage of Kubernetes to automatically scale up and down within the context of a cloud-native application environment. In effect, Jetic is making available a serverless instance of an IPaaS environment for Kubernetes clusters that have now become a default standard in enterprise IT environments.

Integration of microservices that exist both within an application or span multiple applications is more challenging than legacy monolithic applications that typically expose a single application programming interface. Jetic is leveraging Apache Camel to democratize the creation of integrations across a modern application environment that is much more dynamic in terms of the pace at which integrations need to be created, said Sluczka.

For example, as more cloud-native applications are deployed and updated, IT teams are running into integration issues that get created as entire microservices are continuously added and updated. Rather than developing an entirely new version of a monolithic application, the capabilities of a cloud-native application are typically extended by adding additional microservices. Each additional microservice, naturally, needs to be integrated with both hundreds of existing microservices as well as legacy monolithic applications that have exposed an API. Organizations are simply not going to be able to afford to hire a small army of integration specialists to support those applications, noted Sluczka.

The only way to address that challenge is to make it easier for developers within the context of a DevOps workflow to create those integrations as needed themselves, he added.

Each IT team will need to decide for themselves whether to shift away from legacy iPaaS platforms, but as the pace at which modern applications are built and deployed continues to accelerate, it’s now only a matter of time before pressure to increase the rate at which integrations can be created will mount the more organizations become dependent of software to drive a wider range of business processes.

In the meantime, as IT teams head into 2024, they need to assess at what rate cloud-native applications are being deployed. Many of the assumptions concerning the way monolithic applications are managed will need to be reassessed as more applications that were constructed using microservices are distributed across the enterprise. The issue, of course, will be determining when might be the right time to make a transition to a different approach to application integration based on an application portfolio, that is, in terms of architecture employed, with each passing week becoming more diverse.