What is the sideband model?
In the sideband model, traffic is directed to an API gateway, such as Apigee, Kong, or Mulesoft. The API gateway makes a backchannel call to PingAccess to determine if it should grant or deny the request and determine what modifications should be made to the request or response. The application in PingAccess is configured with the sideband client as the destination.
Pros
- 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.
Cons
- 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.