Sample Deployment Scenario

Illustration and overview for a sample deployment scenario.

Using the Admin Console Installing Tools Installing Plug-ins

Table of Contents

Introduction

There are many ways you can deploy the Akana API Platform. This document provides an illustration of a clustered environment with high availability. Your deployment might vary depending on many factors, including:

  • Database connectivity from the containers
  • Load balancing and failover requirements
  • Security and firewall restrictions

Note: It's best to consult with a member of the Akana Professional Services team to get recommendations on the ideal deployment for your requirements.

Sample deployment: clustered environment

The illustration below shows an example of a typical customer deployment with a single geographical data center (one physical location).

Sample deployment: clustered environment

Legend

The numbers in the diagram above correspond to the sequence of actions below:

  1. The consuming app invokes the OAuth server to receive the access token. See OAuth below.
  2. Authentication is validated, and then the access token is returned to the consuming app.
  3. The consuming app invokes an API hosted in the Akana API Gateway, accessing the external API Gateway (Network Director, ND).
  4. The external API Gateway, acting as the Policy Enforcement Point, reaches out to Policy Manager (PM), which is acting as the Policy Decision Point, to authorize and authenticate the consuming application. See Policy Manager (PM) and API Gateway/Internal Gateway (Network Director) below (#4 and #7 show the same activity).
  5. The containers with Policy Manager/Community Manager installed send and/or receive data to/from the RDBMS.
  6. The external API Gateway calls the internal API Gateway.
  7. The internal API Gateway, acting as the Policy Enforcement Point, reaches out to Policy Manager (PM), which is acting as the Policy Decision Point, to authorize and authenticate the consuming application. See Policy Manager (PM) and API Gateway/Internal Gateway (Network Director) below (#4 and #7 show the same activity).
  8. The internal API Gateway invokes the downstream API, physical service.
  9. The internal API Gateway saves analytic information about the request/response, to MongoDB.
  10. Policy Manager stores the analytic information in MongoDB. See MongoDB below.

The response is returned to the consuming application.

Notes:

  • For this scenario to work well, the database and the PM/CM containers must be in the same physical location.
  • The above diagram includes an external consumer, accessing the deployment from outside the firewall, and an internal consumer such as a company employee.

Components

The example deployment above includes the following components:

Policy Manager and Community Manager running in the same container

This sample clustered deployment environment includes two containers that each have Policy Manager and Community Manager installed on them. Each container should be on a different machine.

Two containers are the minimum for a clustered environment, providing some redundancy.

For information on the features you'll need to install on the combined Community Manager/Policy Manager containers in this sample deployment scenario, see Community Manager/Policy Manager container features with access to MongoDB.

Job Scheduler

This sample clustered deployment environment includes a dedicated container for the background job scheduler (Quartz scheduler). This container can run all of the Policy Manager and Community Manager scheduled jobs.

The job scheduler cannot be clustered; it runs on only one container.

It's not necessary to have the job scheduler in its own container, completely separate from other components. However, by separating it out, you can help ensure that the scheduled jobs, which can include a lot of data processing, can run without affecting other containers.

Whether the container that's running the job scheduler is on a separate machine or not, we recommend allocating plenty of memory for the scheduled jobs. For example, 2 GB of memory, 2 CPU, should be fine.

For information on the features you'll need to install on this standalone container, to add jobs to the Quartz scheduler, see Scheduled Jobs container features.

Note: There are other scheduled jobs that are run on each container. For example, Network Director has a job scheduler that is responsible for reaching out to Policy Manager to get updated information on which APIs to load. These scheduled jobs are not separate installation features, they are built in to each container.

OAuth Provider

OAuth provides the framework for authentication and authorization, whether you use the Akana API Platform's OAuth Provider or an external OAuth Provider.

Note: If you're using PingFederate or the platform's inbuilt OAuth Provider, you can use referenced bearer tokens or JWT bearer access tokens. All other OAuth Providers require JWT.

If the platform's inbuilt OAuth Provider is used, it connects directly to the database.

For information on the features you'll need to install on the standalone OAuth container, or the container where you want the OAuth component to reside, see Standalone OAuth container features.

Reverse Proxies

The reverse proxies provide a way for users to access the containers that are behind the firewall. In this example, the reverse proxies perform two functions:

  • Allowing apps and external consumers external access into the CM containers.
  • Allowing apps and external consumers to reverse proxy into the OAuth provider.

The platform doesn't provide reverse proxy functionality. You can use a third-party product such as HAProxy, F5, or NGINX.

API Gateway/Internal Gateway (Network Director)

This sample clustered deployment environment includes four Network Director containers:

  • External Gateways: an external cluster of two, outside the firewall
  • Internal Gateways: an internal cluster of two, inside the firewall.

In this sample scenario, the external Network Director instances call the internal Network Director instances before calling the API. It's not necessary to configure your deployment this way, but it's a clean approach and avoids opening direct access to your internal network from your DMZ.

The Network Director communicates with Policy Manager and relays the messages downstream to the API.

For information on the features you'll need to install on Network Director containers, see Standalone API Gateway (Network Director).

External App Developer

The external app developer accesses the Community Manager developer portal via the reverse proxy. Community Manager offers design-time features to allow the app developer to define and manage apps and request access to APIs.

Elasticsearch

This sample clustered deployment environment includes two Elasticsearch nodes, the minimum for redundancy.

The two Elasticsearch nodes should be on separate machines, for failsafe purposes; however, they needn't be dedicated machines. For example, you could run Elasticsearch along with each of your Community Manager/Policy Manager containers.

Install Elasticsearch as described in Installing and Configuring Elasticsearch.

MongoDB

This sample clustered deployment environment includes three MongoDB instances, the minimum for sharding. It's a good idea to do sharding if you have multiple data centers. For more information, see API Gateway 8.0 Multi-Regional Deployment (PDF document).

To run MongoDB, you'll need to install:

  • Akana MongoDB Support (Plug-In). Must be installed on the Policy Manager and Community Manager containers.

Note: In addition, if you're using MongoDB, the Network Director should be configured to use a remote writer. In the Akana Administration Console, Configuration > com.soa.monitor.usage:

  • usage.local.writer.enabled is true by default. Set it to false.
  • usage.remote.writer.enabled is false by default. Set it to true.

Back to top

Container features for this sample deployment

To create the above deployment, you'd need to install the features below in the various containers.

Community Manager/Policy Manager container features with access to MongoDB

In each CM/PM combo container shown in this sample deployment, install the following features:

  • Akana Policy Manager Console
  • Akana Policy Manager Services
  • Akana Security Services
  • Akana Community Manager
  • Akana Community Manager Scheduled Jobs

Install the following plug-ins:

  • Akana MongoDB Support (Plug-In) (if using MongoDB for analytics)
  • Akana Community Manager Policy Console
  • One or more of the following (at least one theme is required for Community Manager):
    • Akana Community Manager Default Theme
    • Akana Community Manager Hermosa Theme
    • Akana Community Manager Simple Developer Theme

Standalone API Gateway (Network Director)

Install the following features on each container running Network Director:

  • Akana Network Director
  • Akana API Platform ND Extensions Feature
  • Akana Community Manager OAuth Provider Agent

Required if you are using the Akana API Platform as your OAuth Provider:

  • Akana OAuth Provider Agent (deployed only if the implementation is using Akana as the OAuth Provider, and only on the Network Director)

Standalone OAuth container features

If you are using the Akana API Platform as your OAuth Provider, install the following features on the standalone OAuth container, or the container where you want the OAuth component to reside. These are not required if you're using an external OAuth provider.

  • Akana OAuth Provider
  • Akana Community Manager OAuth Provider

Scheduled Jobs container features

The installation features that are installed on this standalone container, that add jobs to the Quartz scheduler, are:

  • Akana Policy Manager Services—this feature bundle includes the Akana Scheduled Jobs feature which adds jobs to the Quartz scheduler
  • Akana Community Manager Scheduled Jobs

Note: There are other scheduled jobs that are run on each container. For example, Network Director has a job scheduler that is responsible for reaching out to Policy Manager to get updated information on which APIs to load. These scheduled jobs are not separate installation features, they are built in to each container.

Back to top