APIGW vs. v5c GW
APIC v2018 provides fundamental changes over APIC v5, including a new Gateway APIGW which provides fundamental changes over API v5's Gateway. Note that APIC v2018 actually provides two Gateway options for APIs, the v5-compatible DataPower Gateway aka v5c and the DataPower API Gateway aka APIGW.
Overall, there are a few high-level concepts that are useful for understanding the shift from APIC v5 to the new API Gateway.
The v5c GW is built on top of XSLT and GWS which are running on a DP MPGW:
The APIGW is a native DataPower service-level object, alongside MPGW, so API policies are natively implemented and run directly:
This means that the mapping from APIC concepts to Gateway implementations is direct, "What you see is what you get", which implies a much easier debugging and maintenance experience. It also yields algorithmicly faster performance.
The v5c GW is built with a request/response flow:
The APIGW is designed with a "horseshoe" flow, thus allowing first-class patterns with no backend at all, one backend, or many invoked backends all gathering data for the response to the client:
In APIC v5, the Management node knows about every Gateway in the Gateway cluster and manages the set:
In APIC v2018 (for both Gateway types), the Management node knows only about the Gateway Cluster as a whole, and the cluster is in control of members of the cluster itself. This means that the administrator in charge of the Gateways can take individual Gateways in or out of rotation, scale-up/scale-down, etc., without needing to touch the Management node.
For a comparison of the v5c GW and the APIGW, see https://www.ibm.com/support/knowledgecenter/en/SSMNED_2018/com.ibm.apic.overview.doc/rapic_gateway_types.html