This is the fourth and final installment of the Axway API Management series. In this final installment we will look into the high availability Architecture, promotions process and setting up the Developer Portal.
If you haven’t read our previous blogs, we recommend you to read these first:
- Axway API Management – An Introduction (part 1)
- Axway API Management – Policy Studio (part 2)
- Axway API Management – Caching and Security (part 3)
High Availability
The Axway API Gateway Management platform can be deployed into a high availability production environment. There are multiple options available according to the need of the organization.
- Single Datacenter Deployment
- Twin Data Center Deployment
- Geo redundancy Deployment
Single Datacenter Deployment
Single data center deployment offers meets the minimum requirement of high availability, thus eliminating the single point of failure in the nodes/systems.
The above diagram depicts how we can setup the axway api gateway platform in a single data centers. There will be two racks/servers where the API gateway as well as the backend data provider/api(s) will be deployed. Both will be in active-active multi-master setup. The network between the gateways need to be open so that both the gateways can share their cached data and the events. The cache will be maintained in EHCache.
To have a fault tolerance system and prevent a service interruption, all components must be configured in this goal.
- An external client application makes inbound calls on the load Balancer.
- Load Balancer choose to route the traffic on a instance given depending of a number of characteristics including the response time or system load.
- All API Gateway of a group have the same configuration to virtualize the same APIs and execute the same policies
- Each API Gateway instance has Remote Host interfaces that specify outbound connections to back-end API systems, and which can balance the message load based on specified priorities for Remote Hosts.
Apache Cassandra is required to store API Gateway data used by the following components:
- API Manager: Client Registry, API Catalog, and quota management
- Key Property Store: Custom table definitions and data
- OAuth: OAuth token store
- Client Registry: API key and OAuth solutions using API Gateway only
Apache Cassandra have to be configured to use its own HA capabilities.
Twin Datacenter Deployment
Twin data center deployment offers high availability across the data centers. It is same as the single datacenter deployment however the nodes/gateways and the admins are deployed across multiple data centers, thus offers more protection against catastrophic disasters. With this approach we can meet almost 99.9% availability.
The above diagram depicts how we can setup the axway api gateway platform deployed in twin data centers. The setup is same as the single data center, however the traffic gets routed to one of the data center by global load balancer. The global load balancer plays the role of directing the traffic to the nearest data center based on the source of the consuming entity. This provides low latency as well as geo redundancy in case of a data center failure. The N-N stacks need to be geo redundant to get the benefit.
To have a fault tolerance system and prevent a service interruption, all components must be configured in this goal.
- An external client application makes inbound calls on the global load Balancer.
- Global Load Balancer choose to route the traffic on data center depending on the nearest location to the consumer or route to other data center in case of the closest one unavailable.
- All API Gateway of a group have the same configuration to virtualize the same APIs and execute the same policies
- Each API Gateway instance has Remote Host interfaces that specify outbound connections to back-end API systems, and which can balance the message load based on specified priorities for Remote Hosts.
Apache Cassandra is required to store API Gateway data used by the following components:
- API Manager: Client Registry, API Catalog, and quota management
- Key Property Store: Custom table definitions and data
- OAuth: OAuth token store
- Client Registry: API key and OAuth solutions using API Gateway only
Apache Cassandra have to be configured to use its own HA capabilities.
Multi Region Deployment
The multi region deployment is a complex high availability architecture where multiple api gateways are deployed across geographical regions to serve customers across the world. The architecture is complex and is needed where the backend APIs are need to be deployed to the various region to meet the data privacy and integrity requirements. Deploying region specific api gateway provides low latency to the consumer as well as high availability within the same region. The admin node managers will be deployed into one location with high availability, thus managing the api gateways from the centralized location.
The above diagram depicts how we can setup the multi-regional axway api gateway platform deployed across geographical regions. In this setup, the corporate data center is located in Europe, where high availability api gateway has been setup. Both the gateways as well as the admin node managers are running in high availability mode multi-master fault tolerant. Two regional api gateways are deployed – one in North America and the other one somewhere in Asia. The regional api gateways are connected to the regional backend API servers thus serving the data quickly. However they are managed by the admin node managers deployed in the corporate data center. The setup will be done similar to the twin data center where global load balancer will be used to manage the traffic within a zone/region. This provides seamless high availability, fault tolerant.
To have a fault tolerance system and prevent a service interruption, all components must be configured in this goal.
- An external client application makes inbound calls on the specific regional global load Balancer.
- Global Load Balancer choose to route the traffic on regional data centers depending on the nearest location to the consumer or route to other data center in case the closest one unavailable.
- All API Gateway of a group have the same configuration to virtualize the same APIs and execute the same policies
- Each API Gateway instance has Remote Host interfaces that specify outbound connections to back-end API systems, and which can balance the message load based on specified priorities for Remote Hosts.
Apache Cassandra have to be configured to use its own HA capabilities.
Deployment/Promotion
Axway API Management platform provides promotion capabilities to deploy the api configurations and policies from one environment to another environment. The promotion framework abstract the complexity of packaging the api configurations, thus focusing on the configuration of environment specific attributes so that the configuration can be deployed seamless across the environments.
To configure the promotion feature, first define the environment topology.
Each domain has separate API gateway instance.
Next comes the API gateway configuration packages. The configuration consist of:
- a) Policy package – consist of different policies applied to the api configuration like throttling, external connections, listeners, security, auditing etc.
- b) Environment package – consist of environment settings and certificates.
- c) Deployment package – combination of policy and environment package.
Finally the deployment configuration:
Promotion Cycles
a) FIRST CYCLE
A first cycle promotion refers to promoting to an upstream environment in which no previous promotions have been performed (No existing upstream environment package (.env))
API Gateway administrator have to uses Configuration Studio to create an environment and performs the following tasks :
- Specifies values for the environment-specific settings selected in the development environment (for example, policy, listener, and external connections).
- Imports or creates certificates and keys.
- Defines users and user groups.
- Exports the environment package to a file on disk. The environment package is implemented as an .env file.
- When the environment package has been created, Both .pol and .env package can be deployed with API Gateway Manager or scripts.
Note:- Each environment will have its own version of the .env file containing environment-specific settings, certificates, users, and so on. This constitutes a full deployable configuration when combined with .pol file.
Packages .pol and .env can be merge into a .fed package (.pol + .env).
B) SUBSEQUENT CYCLES
A Subsequent cycle promotion refers to promoting to an upstream environment that has already had configuration promoted to it (existing upstream environment package (.env)).
API Gateway administrator have to uses Configuration Studio to merge the previous environment package with .pol received from dev team and performs the following tasks :
- Specifies values for new environment-specific settings required by the new policy package from the development environment.
- Updates values for environment-specific settings that previously existed (if necessary).
- Adds or removes certificates and keys (if necessary).
- Adds or removes users and user groups (if necessary).
- Exports the environment package to a file on disk (if necessary).
API Portal
The key pillar of an API Management platform is the self-service developer portal which facilitates the collaboration between the developers, partners and communities with the API providers, thus help organizations create new sales channels, increase developer velocity, integrate customers and partners more efficiently, and enable new business models that help drive revenue growth.
Axway API Management plaform has a solid developer portal, popularly known as API Portal. The key benefits of enabling the API portal would be:
- Self-register and manage profile and credentials
- Register applications and request API Keys for each API service that the developer plan to integrate into apps
- Enable browsin the API catalog for APIs, API attributes and documentation
- Test APIs dynamically while leveraging complete traceability to assess what’s happening
- Test OAuth-protected APIs by including access tokens in requests, obtain access tokens from OAuth authorization service on Axway API Gateway, and consume OAuth-protected APIs
- Participate in developer communities using wikis and blogs
- Perform delegated administrative tasks
- Personalized branding
- Control API modifications and rollout through versioning
- Monitor the API usage
The api portal is based on JOOMLA CMS system. In the backend a database would be needed to store the configurations. This is done either using MySQL or Maria DB. The configuration is pretty straight forward:
- Configure MySQL or MariaDB database.
- Secure the connection to the database using SSL certificates.
- Install the API Portal software.
- Install Joomla components – EasyBlog and EasyDiscuss. This is optional.
- Link API Portal to API Manager.
Conclusion Axway API Management
Axway API Management is a rich API Management gateway and management platform which provides robust, secure, scalable platform that meets enterprise grade needs. The platform comprises of different components which can be tailored according to the organization needs.
For questions about this blog you are able to contact Arijit Roychoudhury, Integration Architect at Devoteam Netherlands (arijit.roychoudhury@devoteam.com). If you are interested in API Management as a solution for your business, feel free to contact Ratko Popovski, manager Architecture & Implementation at Devoteam Netherlands (ratko.popovski@devoteam.com).
