API Gateway Policy Plugin Overview

Contents:
2
Introduction to the Gateway Policy Plugin
The Gateway Policy Plugin helps policy development teams manage the full cycle of policy development. The plugin is designed to optimize a GitOps-centric Continuous Integration and Continuous Development (CI/CD) workflow. It is offered as an alternative to the existing documented limitations of what can and cannot be migrated with the Gateway Migration Utility (GMU) tool alone.
The Plugin is designed to simplify this process in several ways:
  • Seamless and easier policy migration and promotion across environments.
  • Provides granular control in policy migration, as you can migrate a single policy to a target Gateway.
  • Automatic dependency management helps you migrate a policy with all its dependencies.
  • Helps enterprises by segregating environment parameters from static policies, ultimately resulting in a consistent deployment across environments and clusters.
  • Metadata generation enables deployment tools to resolve and deploy policies easily.
  • Allows Policy Authors to define Gateway configuration (policies and services) offline and deploy to running Gateway(s) from any source control system like GIT eliminating the need to maintain additional databases.
  • Externalization of Gateway policies in a Source Control System enables management of deployment configurations as code and enables CI/CD.
  • Provision multiple Gateways from the same exported configuration.
  • Easier to manage as teams and promote policies across environments such as from Development to QA to Staging to Production.
  • Enables simpler APIM artifacts management.
  • Works on all Gateway form-factors.
The following diagram explains the overall workflow of Gateway Policy Plugin:
plugin_workflow.png
GMU Tool vs Gateway Policy Plugin
Before the introduction of the Gateway Policy Plugin, the Gateway Migration Utility (GMU) tool was the preferred solution to migrate Layer7 API Gateway policies, services and entities, if the following conditions were met:
  • Your Gateway depends on an external MySQL database
  • You only need to migrate a subset of your database
Even with the GMU tool, the migration effort requires careful planning, coordination, and maintenance of mapping instructions. This is especially true if you are moving large volumes of policies and services from a source Gateway to multiple target Gateways. Unexpected changes to either the source or target Gateway can throw a completed migration or migration plan off course.
With the Gateway Policy Plugin, the Gateway migration process is no longer required as policies are treated as code using the GitOps paradigm. This plugin can also free your development process from an external MySQL database to store Gateway artifacts, which can become a performance bottleneck for large-scale Gateway implementations. And because the plugin is based on the Gradle Build Tool, you get to tap into Gradle versatile capabilities.
The following table summarizes a general comparison between the GMU tool and Gateway Policy Plugin:
Feature
GMU Tool
Gateway Policy Plugin
Provision a New Gateway
Yes
Yes
Moves Policies and Services between Gateways
Yes
Yes
Moves all entities between Gateways
No; see GMU Limitations for more information.
Only two migration limitations compared to GMU; see Known Limitations for more information.
Migration Templates Required
Yes
No
External DB Required
Yes
No
Has a Dependency Management System
No
Yes
Version Controlled Build Environment Configuration
No
Yes
Supports Continuous and Composite Builds
No
Yes
CI/CD Ready
No
Yes