On-premises versus cloud deployment

Before you move workloads from an on-premises deployment of IBM® App Connect Enterprise to App Connect in IBM webMethods Hybrid Integration, understand the differences in responsibility, architecture, configuration, and runtime behavior.

Responsibilities

App Connect is a fully managed software-as-a-service (SaaS) offering. IBM is responsible for providing and maintaining the infrastructure. As an App Connect user, you're responsible for your integration content, including designing and deploying your integration runtimes and message flows. You share responsibility with IBM for creating, configuring, and upgrading integration runtimes. With this shared-responsibility model, the service automatically handles some operational tasks that you controlled previously. Other tasks are managed through the service APIs and user interface.

For more information, see Responsibility overview for webMethods Hybrid Integration.

Solution architecture

App Connect is deployed on Amazon Web Services (AWS) and Microsoft Azure, and separates management functions from integration workloads. The service provides a multi-tenant control plane for management and authoring. A data plane provides workload isolation through dedicated runtime components for each tenant. The service is deployed across three availability zones, which provides high availability and automatic failover.

Runtime model

In an on-premises deployment of App Connect Enterprise, integrations are typically deployed into integration node-managed integration servers. In App Connect, you create one or more integration runtimes, which are functionally equivalent to integration servers.

Integration runtimes in App Connect are container-based and declarative, meaning that they're managed through defined runtime configuration. When you create or update a runtime, you define an appropriate configuration. The service then provisions or updates the runtime by using a blue-green deployment approach. Under this approach, the service creates a new version of the runtime and switches traffic to it without disrupting processing.

For more information, see Creating a runtime.

Runtime restarts and reconciliation

App Connect uses a zero-downtime reconciliation process when you update integration runtimes or deploy new integrations.

When you update a runtime configuration or deploy another integration, the system creates a new instance of the runtime with the updated configuration. The existing runtime continues to process requests while the new instance starts. When the new instance is ready, the system routes new requests to it and gracefully shuts down the previous instance. During shutdown, the system sends a signal to the previous runtime instance, allowing it to complete in-flight requests before it exits. This behavior makes sure that existing flows finish processing without interruption. Most flows complete within the graceful shutdown period. However, long-running flows might be stopped before they complete.

Container-based deployment

App Connect in webMethods Hybrid Integration is built on App Connect in containers. Container-based deployments behave differently from traditional software installations and these differences can affect how integrations are grouped, managed, and scaled.
Deployment isolation
In container deployments, groups of integrations are typically deployed independently into their own container runtime instead of a more traditional singular, centralized broker deployment. This approach has advantages but also requires planning considerations.
Resource allocation
CPU and memory are configured for each runtime. Runtimes are configured and scale independently to match your workload requirements and control resource consumption.
Runtime versioning
Each runtime includes its own product runtime so that you can create runtimes at different supported versions and upgrade them independently.
Declarative configuration
You configure your runtimes before you deploy integrations to them instead of using post-deployment commands.

When you migrate existing integrations, decide how to group and deploy them to integration runtimes in App Connect. A common starting point is to mirror your existing on-premises deployment. For example, you might deploy the integrations from an integration server or execution group into a single runtime.

App Connect also enables more flexible deployment patterns. You can separate integrations into multiple runtimes based on factors such as workload characteristics, availability requirements, upgrade cadence, or cost considerations. Each runtime has an associated cost, so you must balance operational isolation with efficient use of resources.

Configuration mapping and dependencies

In an on-premises environment, integration runtimes are often configured by using commands such as mqsichangeproperties and by relying on files that exist on the host system, such as ODBC configuration files or keystores.

In App Connect, all configuration is provided declaratively by creating configuration resources and associating them with integration runtimes. The following configuration types represent resources that message flows commonly reference.
  • server.conf.yaml configures most of the things that you configure by using App Connect Enterprise commands such as mqsichangeproperties.
  • setdbparms.txt provides details of mqsisetdbparms commands to run for the integration runtime.
  • Policy project creates policies in a policy project to control the behavior of message flows and nodes at run time.
  • Keystore and Truststore provide keystores and truststore for the runtime or message flows to use.
  • Generic files provides general files for the runtime or message flows to reference.

Before migration, identify any external file dependencies or runtime properties and make sure that they're mapped to the appropriate App Connect configuration types.

For more information, see Configuration types.

Connectivity to on-premises systems

Many integrations that are deployed to App Connect need to interact with applications and systems that remain on-premises. App Connect supports hybrid connectivity scenarios through port forwarding, callable flows, and AWS PrivateLink. (You can also configure DNS mapping to route traffic from an application domain to a private network endpoint.)
Port forwarding
You can configure port forwarding to provide secure connectivity to applications and systems in your private network. Each tenant in App Connect has a dedicated switch server, which communicates with runtimes in App Connect. You download and run a secure agent in your private network. The agent creates an outbound connection to the switch server that is associated with your service instance. This connection enables bidirectional traffic without the need to open inbound ports in your firewall. The connection is secured with mutual TLS.

A common scenario for port forwarding is to interact with a database or IBM MQ on premises. However, you can also use port forwarding to integrate with applications and systems in other networks or public clouds.

For more information, see Connecting to a private network through a switch server.

Callable flows
Callable flows also use the switch server to connect flows that are running on premises and in App Connect. For example, you can run an App Connect Enterprise flow in your private network, then call that flow directly from a flow that is hosted in App Connect. You can add a Callable Flow Input node to a flow and deploy the flow to a runtime with connection details for the switch server. The flow is then registered and becomes available for use by other flows that are connected to the same switch server. Callable flow nodes and connectors are available in App Connect Designer and the IBM App Connect Enterprise Toolkit so that Designer flows can call Toolkit flows and the other way around. Callable flows are commonly used for SAP integration, or where you want to process data closer to the application.

For more information, see Callable flows overview.

AWS PrivateLink
AWS PrivateLink provides a private network connection between App Connect and a Virtual Private Cloud in your Amazon Web Services (AWS) account without using public IP addresses or the internet. To use AWS PrivateLink, you create an interface Virtual Private Cloud (VPC) endpoint and an Amazon Route 53 private hosted zone. Data is routed privately by using the AWS network rather than the internet. App Connect supports the use of AWS PrivateLink for inbound and outbound communication. Communication is one way so you must create separate connections for inbound and outbound traffic. A common scenario for AWS PrivateLink is to enable AWS services in your Virtual Private Cloud to trigger App Connect integrations through an inbound private link. Similarly, App Connect integrations can call AWS services through an outbound private link.

For more information, see Connecting to AWS services with AWS PrivateLink.

If you don't use the secure agent, you can configure firewalls to enable connectivity into your private network or to applications that use IP allowlisting. For a list of IP addresses that App Connect uses for outbound connectivity, see Outbound IP addresses in the webMethods Hybrid Integration documentation.

Availability and scaling

App Connect is deployed across multiple availability zones within each region to provide high availability and automatic failover. For improved resilience, you can configure multiple replicas of an integration runtime. The service attempts to distribute replicas across availability zones and automatically reschedules runtimes if a zone becomes unavailable.

When you plan your migration, review the availability requirements of your integrations and, if appropriate, configure multiple runtime replicas to meet those requirements.

Upgrade behavior and version control

IBM manages the installation and upgrade of the underlying App Connect platform. You control the version that each integration runtime uses by selecting from the supported runtime versions when you create the runtime.

Depending on the version option that you choose, runtimes can be upgraded automatically when new fix packs or modification releases become available. Decide whether you want automatic upgrades or greater control to test new versions before you apply them to production runtimes.

For more information, see Updating the version of your integration runtime.

CI/CD pipelines

The API for App Connect API provides all the capabilities that you need to deploy and manage your integrations and runtimes. For more information, see API overview.

Product limitations and behavioral differences

Some capabilities that are available in on‑premises deployments of App Connect Enterprise are not available or behave differently in App Connect. One example is the absence of a default local queue manager in container-based deployments. For more information, see Known limitations and Supported resources in imported BAR files.