Runtime architecture

An API gateway acts as the intermediary between clients and services. In the SnapLogic APIM 3.0 solution, a Snaplex is the API gateway and performs the role of Server as defined in the OpenAPI Specification. This architecture differentiates APIM 3.0 from other API Management vendors in that you don't implement the gateway yourself.

In the SnapLogic Platform, the control plane and the data plane divide responsibilities. The control plane stores the metadata necessary to process requests, such as for Snap accounts, user accounts, permissions, and assets. Snaplexes act as the data plane and execute the business logic. To satisfy a request, Snaplexes obtain the metadata from the control plane and cache it for future use.

Production Snaplexes have multiple nodes to provide resilience and scalability. We recommend the use of load balancers that distribute requests across the nodes. A load balancer provides round-robin distribution of requests. This ensures even distribution of traffic, prevents overloading of individual hosts, and improves overall performance and reliability. Snaplex execution nodes, JCC nodes, process requests and execute pipelines. To support Ultra Tasks, a Snaplex needs a FeedMaster node, which acts as a queue and forwards incoming requests to an execution node.

Snaplex deployment options include Cloudplexes and Groundplexes:

  • SnapLogic manages Cloudplexes, which require only minor configuration. SnapLogic provides the load balancer.
  • You deploy and manage Groundplexes. Provide your own load balancers and deploy them where necessary.

When choosing a deployment architecture, consider the following:

  • Security and access: Resources such as databases and internal applications behind a firewall usually restrict access. To access resources that restrict inbound traffic with a Cloudplex, you might need to you might need to add SnapLogic IP addresses to your resources' allowlists. If you deploy a Groundplex behind the firewall, it establishes outbound connections with the control plane and you can often avoid additional configuration. For Groundplexes, you can configure allowlists in Admin Manager to restrict inbound communication.
  • Performance: The length of time that it takes to complete a request increases with the number of network calls required. You can control this both in the way you design your Services and in the way you deploy your Snaplexes. Refer to Request execution flow for more information.

Every organization has unique requirements. The following examples demonstrate common deployment architectures, but we don't recommend one over another.

Example Cloudplex deployment

In the following Cloudplex deployment, SnapLogic manages the load balancer and Cloudplex. The Cloudplex only communicates with the Control Plane to obtain metadata. After the first request, the Cloudplex caches the metadata to avoid unnecessary network calls.


Cloudplex

Example Groundplex deployment

When Services are deployed on Groundplexes, the requests go directly from the load balancer to a Groundplex node. You can deploy Groundplexes in a physical network or on virtual machines in the cloud. Load balancers can be in front of, or behind a firewall. The following example shows the load balancer in front of the firewall in a deployment with two Groundplexes:


Simple Groundplex deployment

Example hybrid deployment

This example hybrid deployment meets the use case where some, but not all processing, must be behind the firewall for security reasons. In the diagram, a Cloudplex handles endpoints that can execute locally, and a Groundplex handles requests for resources behind the firewall. The same can be accomplished with Groundplexes, positioning some in front of and some behind the firewall.


Hybrid deployment

-->