Jetic emerged from stealth this week to launch its eponymous integrated platform-as-a-service (IPaaS) product, based on open source Apache Camel software that runs natively on Kubernetes clusters.
For example, rather than trying to deploy a monolithic enterprise service bus (ESB) into containers, Jetic makes it easy to create integrations using the same declarative approach that IT teams use to manage Kubernetes. We offer iPaaS that allows you to
Jetic CEO Andre Sluczka said this approach makes it easier for developers to create integrations without having to bring integration experts into DevOps sprints every time a software component needs to be integrated.
At the same time, iPaaS leverages Kubernetes to automatically scale up and down within the context of cloud-native application environments. In fact, Jetic makes available serverless instances in his IPaaS environment for Kubernetes clusters, which are now the default standard for enterprise IT environments.
Integrating microservices that reside within an application or span multiple applications is more difficult than traditional monolithic applications that typically expose a single application programming interface. According to Sluczka, Jetic leverages Apache Camel to democratize the creation of integrations across modern application environments, making them more dynamic in terms of the pace at which integrations need to be created.
For example, as more cloud-native applications are deployed and updated, IT teams are faced with integration issues that arise when entire microservices are continually added and updated. The functionality of cloud-native applications is typically extended by adding microservices, rather than developing an entirely new version of a monolithic application. Naturally, each additional microservice must integrate with both the hundreds of existing microservices and traditional monolithic applications that expose APIs. Organizations just can’t afford to hire a handful of integration specialists to support these applications, Sluczka points out.
The only way to address this challenge, he added, is to make it easy for developers to create those integrations themselves as needed within the context of a DevOps workflow.
Each IT team must decide for themselves whether to migrate away from traditional iPaaS platforms, but as the pace of building and deploying modern applications continues to accelerate, pressure to increase the speed of integration increases. It is also a matter of time. This will become more likely as more organizations rely on software to power broader business processes.
In the meantime, IT teams should assess the rate at which cloud-native applications are being adopted as they move toward 2024. As applications built using microservices become distributed throughout the enterprise, many of the assumptions about how monolithic applications are managed must be reevaluated. The challenge, of course, becomes determining when is the right time to move to a different approach to application integration in terms of an application portfolio that is becoming more diverse by the week, and hence the architecture being adopted.