How do I choose a deployment model?

Less cross-team coordination required — You can implement and maintain a gateway deployment with less coordination with application teams because the PingAccess infrastructure is installed on separate systems from the web servers.

Simpler setup — Because the PingAccess nodes are the only required components, this deployment model can be set up more quickly than the other models.

Simpler upgrade — The only components you must upgrade in a gateway deployment are the PingAccess nodes.

Simpler troubleshooting — Issues are easier to isolate because there are fewer components sharing a system with the PingAccess infrastructure.

Simpler logging — All transactions that PingAccess processes are audited by the engine node, making it easier to view logs for a specific event.

Network impact — Using the gateway deployment model requires that you restructure your existing network to route traffic through PingAccess.

Additional network overhead — The overhead of an additional network hop can theoretically exceed a latency budget. This rarely happens in practice, and the agent model often makes a similar addition to latency, but this might occur in some environments.

No network changes — Because the PingAccess agents are installed on the web servers, no network changes are required.

Minor performance improvements — In some cases, the agent can determine whether to grant access using cached data, which can reduce latency. In most cases, though, the agent must communicate with a PingAccess node, which results in latency similar to the gateway model.

Greater maintenance effort — You must maintain and upgrade agents independently on each web server.

Unavailable features — Some features can’t be used in an agent deployment. You can’t:

Cross-team coordination — Because the agents are installed directly on the web server, you might have to coordinate with other teams to install and maintain them.

Complex tracking — Keeping track of all agents can be difficult.

Difficult troubleshooting — Because the agent model involves more systems which can be varied in their OS and web server versions, troubleshooting issues can be more difficult.

Version dependencies — Because the agent must be installed as a plugin on the web server, there are dependencies on the web server and OS versions that aren’t present in the gateway model.

Less centralized logging — To view the logging for a specific transaction, you must review the agent audit log and the web server access logs.

No network changes — Because the PingAccess sideband clients are installed on the API gateways, no network changes are required.

Simpler troubleshooting — Issues are easier to isolate because there are fewer components sharing a system with the PingAccess infrastructure.

Simpler logging — All transactions processed by PingAccess are audited by the engine node, making it easier to view logs for a specific event.

Greater maintenance effort — You must maintain and upgrade API gateway integration kits independently on each API gateway.

Unavailable features — Some features may not be available depending on your API gateway.

Additional network overhead — The overhead of an additional network hop can theoretically exceed a latency budget. This rarely happens in practice, and the gateway and agent models often make a similar addition to latency, but this might occur in some environments.

Cross-team coordination — Because the sideband clients are installed directly on the API gateways, you might have to coordinate with other teams to install and maintain them.

Complex tracking — A sideband deployment has more components to maintain than a gateway deployment.

Version dependencies — Because the sideband client must be installed on the API gateway, there are dependencies on the API gateway and operating system versions that are not present in the gateway model.