App Connect

 View Only

What is an IntegrationRuntime

By Rob Convery posted Wed March 15, 2023 04:37 AM

  

In the App Connect Operator released in November 2022 (v6.2) we introduced a new resource type called an IntegrationRuntime. The intention of the IntegrationRuntime is that it offers everything that the IntegrationServer does and more. 

New features will now typically only be made available in the IntegrationRuntime, with the long-term strategy of dropping support for the IntegrationServer resource type in a later release. An example of some of the new features we already have are:

  • Automatically enable TLS on HTTP Input nodes

  • Use OpenTelemetry to track and correlate data as it passes between disparate applications

  • Run API flows authored in App Connect Designer in serverless mode (only in non-production deployments)

  • Automatic discovery of the types of flows in BAR files when using the BarURL to configure the appropriate containers

  • Support for NodeSelectors to enable you to run your IntegrationRuntime on specific workers (handy if you want to use worker licensing to enable you to over-commit on limits)

One of the most important points to highlight is that the IntegrationRuntime is still based around the same App Connect Enterprise runtime that was also used in the IntegrationServer, so it still benefits from all the quality and heritage that comes with a mature application.

Why did we not just update the IntegrationServer? This enabled us to more align the Spec with ever changing industry standards. 

Many of the fields are similar if you are migrating from an IntegrationRuntime, meaning it should be fairly easy to take an existing IntegrationServer and convert it into an IntegrationRuntime.

If you’re starting a new project please consider using IntegrationRuntimes so you can benefit from all the improvements mentioned above and easily take advantage of future additions. 

To start using IntegrationRuntimes just create an instance of the Dashboard resource with the value spec.displayMode=IntegrationRuntimes and you will have the same dashboard you know and love, but have the ability to create IntegrationRuntimes instead of IntegrationServers.


#AppConnect

9 comments
201 views

Permalink

Comments

armando ruiz
Mon January 22, 2024 02:30 PM

Hi @Rob Convery.  If the intention is to move towards integration runtimes, how should the strategy be managed when dealing with 80 services that were originally distributed across business lines and were grouped into 12 execution groups in IIB10? When migrating to ACE within appConnect using CP4I, we created 12 integration servers to continue adhering to best practices by separating and not consolidating everything into a single integration server.

Now, I understand that the idea is to use a single integration runtime and place all 80 services there. Is this the recommended approach, or what would be the deployment strategy for these 80 services using integration runtime? Would it still be the same as the one applied in the deployment used for the integration server?

Thank's a lot.

Jan Frederik Sorge
Fri September 22, 2023 07:06 AM

Hi @Rob Convery

Thanks a lot for your quick and detailed reply! As I am starting completely new with the CP4I it really seems to be the best approach to directly move my configuration from IntegrationServer to IntegrationRuntime instead.

Kind regards
Jan

Abu Davis
Wed September 20, 2023 02:52 PM

@Rob Convery I see. In the LTS version, we tried to set nodeAffinity on the IS, but that does not stop other apps from spinning on ACE workers. I think we will use Open Policy Agent to inject the "toleration" into the IS pods as a painful workaround for now.

Rob Convery
Wed September 20, 2023 02:47 PM

@Abu Davis - The LTS release won't pick up these new capabilities until the next major release. These typically happen between 18 months to 24 months after the previous release although we have no confirmed dates on when the next LTS update will be. 

Abu Davis
Wed September 20, 2023 02:26 PM

Hei @Rob Convery, that is great news! We have CPU throttling problems right now in production due to other pods ending up on our dedicated ACE workers. Any idea when the taint feature is coming to ACE Operator in the LTS release?

Rob Convery
Wed September 20, 2023 12:42 PM

Hi @Jan Frederik Sorge

We don't have a full comparison of all the features in each type of resource. As mentioned the IntegrationRuntime is the future and where all our efforts are in terms of enhancements. 

On the roadmap is a tool to assist in moving from IntegrationServer to IntegrationRuntime but there is no ETA for it at the moment. Most of the options are available with either the same or very similar spelling. The biggest change is the move from using a key-values for the containers vs using an array (which better aligns to deployments/pods) 

There are no negative side effects per se from moving to IntegrationRuntimes that spring to mind.  The key thing to remember is that the the underlying runtimes is still the same ACE runtime

@Abu Davis

FYI - Taints are now available on the IntegrationRuntime (along with support for Priority) This should enable you to create a 1 of mode worker nodes that run purely App Connect workload. 

Jan Frederik Sorge
Wed September 20, 2023 11:39 AM

Hi @Rob Convery

Thanks a lot for your blog article which has even been referred to within one of my current open Cases!

Is there any full comparison of the features available within the IBM documentation or the steps that are required in order to migrate an existing yaml of kind: IntegrationServer into an Integration Runtime?

Which negative side effects will I see when I migrate to Integration Server into Integration Runtime?

Thanks a lot in advance!

Kind regards
Jan

Rob Convery
Wed May 31, 2023 11:33 AM

We are aware of the additional requirement to add support for Taints. This is on the RFE backlog but we have no ETA for delivery of this capability at the moment. 

Abu Davis
Wed May 31, 2023 05:01 AM

Of much interest to us is the node selector option. 

We have implemented worker node based licensing using node-selectors on the openshift namespace where ACE pods run. But the issue is other non-ACE pods continue to be scheduled on ACE worker nodes reducing the total available CPUs for ACE.

As per REDHAT the only way to prevent this is to have taints on the worker nodes and then set a corresponding toleration for the taint + node-selector label on the application which in this case amounts to the ACE IS CR/ACE operator is what we think.

Is this something you would be looking at as part of a (near) future release? The RFE is currently set to "Future Consideration" but we really need this now.
https://integration-development.ideas.ibm.com/ideas/CIP-I-209