Differences Between the Container Gateway and Appliance Gateway

The Container Gateway is similar to the traditional Appliance Gateway, with the following notable differences:
The Container Gateway is similar to the traditional Appliance Gateway, with the following notable differences:
Operational Differences
Container Gateway
Appliance Gateway
  • Kubernetes
  • Best Effort Support: Docker Engine/RedHat OpenShift Origin
For more information on compatibility, see Container Gateway Platform Support.
  • Hardware
  • VMware ESXi
  • Amazon AWS
  • Microsoft Azure
  • The Policy Manager is available on the Support site. For access to the site or to obtain a license, contact your sales representative
  • Hardware Appliance Gateway is shipped to customer's place of business. Virtual Appliance Gateway is downloaded from the Support site that requires an account to access
  • Shorter (about a minute) since the container PaaS is already running
  • Two database options available: an external MySQL database or cloud-based MySQL
  • Deploys directly onto a Docker host that could be held either inside Docker Engine or OpenShift OR Kubernetes cluster
  • See Container Gateway reference architecture
  • Longer (2+ minutes) since an operating system needs to be booted first before the Gateway starts
  • Includes a MySQL server
  • Deploys directly onto a cloud computing and platform virtualization software and services such as VMware, ESXi, and Hyper-V server
  • Through the
    Layer7 API Gateway
    's Main menu (Gateway Main Menu (Appliance)) and/or the Policy Manager
  • Supports management tooling compatible with Kubernetes, Docker Engine and RedHat OpenShift
  • More limited integration with virtual machine management systems
  • Release Builds
  • Monthly Certified Builds
  • Locally updated images by users
  • Gateway Patches
  • Monthly Platform Patches
Health Check
  • Performs health checks through scripts. The script response determines the container's health. It is highly recommended that you design a health check script that is customized for your Container Gateway.
  • Depending on the environment the Container Gateway is running on, see System Health Tests (e.g., liveness and readiness probes, pod status check, etc.)
  • Performs a health check and report the Gateway's health by using ICMP ping tests and SNMP monitoring. 
  • Saved in various files
  • View logs on another node from the Policy Manager
  • Customized bash command logging with tracing features
  • Greater flexibility for integration with app and system monitoring solutions.
  • Service metrics is set to disabled by default when operating the Container Gateway in embedded database mode.
  • Self-contained solution; integration requires more customization or design choices.
  • Data Collection Tool (full module set)
  • A limited set of pre-installed tools
  • Smaller attack surface with few installed packages and no services other than the Gateway.
  • Larger attack surface due to the larger package set and inherent additional services.
CA Single Sign-On
  • Installed and enabled by default
Firewall rules
  • Firewall rules managed by the container platform.
  • Configuration of Firewall rules
  • Full ports management. This includes ports used by customizing the Container Gateway.
  • Support for multiple network interfaces. This is a limitation on Docker. Use routing and firewall capabilities provided by the container platform instead.
  • Not supported
  • Connectivity to the
    Layer7 API Gateway
    - XML VPN Client
  • Single node support
  • Cluster-wide protection
  • Container resource management should be done using platform tools
  • Management using the Enterprise Service Manager (ESM) including any administrative task items associated with ESM (Manage ESM User Mappings)
Hardware Security Module (HSM)
  • Not supported
Supports these HSMs:
  • nCipher nShield Solo and nShield Connect
  • SafeNet Luna SA
Cluster management
  • Stale gateways are visible from the Policy Manager Dashboard until a scheduled job refreshes the cluster state.
  • Nodes are not added and removed from a cluster constantly
  • Stale gateways are less visible
  • Back up by creating derived images and saving your configuration files (for example, the Helm Chart)
  • Restore by launching the derived image
  • External database is outside of the Container Gateway and maintenance is the responsibility of the customer.
Custom Assertions
Architecture Differences
While the Container Gateway operates largely similar to the Appliance Gateway, differences exists at the architecture level due to the different deployment architectures.
  • When running a container, each container gets its own private file system that differs from the one on the host.
  • Each container gets exactly one network interface that uses Network Address Translation (NAT) through the physical interfaces.
  • There is no MySQL server running in the Container Gateway. Instead, you need to run their own server (such as handling replication setup, backup/restore, and monitoring).
  • The Container Gateway cannot access the hardware layer of the machine. This prevents the use of Hardware Security Modules (HSM).
The differences in architecture result in a change in what you build and/or configure. See the latest Container Gateway reference architecture for cloud deployments.