Oracle launched API Platform Cloud Service with true hybrid Model

Oracle launched API Platform Cloud Service with true hybrid Model

Oracle has released a new Oracle API Platform Cloud Service that satisfies all the Modern API management requirements.

“This is a 3rd generation API Platform that delivers a ‘true hybrid’ model that allows for APIs to be created, deployed and managed centrally (from the Oracle Cloud) whilst API gateways (engines that run the APIs) can be deployed in any cloud (i.e. Amazon, Azure, Oracle Cloud, IBM Softlayer/bluemix, etc) and/or on-premises.” — Jürgen Kress from Oracle wrote in a blog post.

Oracle has also incorporated Apiary into the portfolio along with the solid/world-class API-first solution to provide developers tools and means to properly design APIs either using Swagger or API blueprint.

The platform includes seven components as described in blog

  • Management service: The management service is the cloud-based system that underpins the management console, developer portal and platform API. It’s the engine of the entire platform. The brains.
  • Management Console:  As the name suggests this is where APIs, Gateways and User/Roles are managed. It’s a role-based application so what a user can do pretty much depends on the role the user belongs to.
  • Developer Portal: A web-based application where developers can search and subscribe to APIs. This is where all of the API documentation can be found and also where application keys are provided after a subscription to an API takes place.
  • Platform API: The entire platform was built following an API-first model. In fact, it can be argued that management service is in fact an API, as everything that can be done (and more) via the management and developer portals can be done by directly invoking the Platform API. The platform API is also consumed by the gateways when phoning home to retrieve new API’s, policies and also send analytics information.
  • Apiary: As previously mentioned, Apiary is a platform for designing APIs that encourages API designers to maintain an active dialogue with API consumers. Both the management and developer portals are already integrated with Apiary so when a user finds an API in the portal, the API specification (i.e. API blueprint) can also be accessed from one single place.
  • API Gateways: These are the engines that run the APIs and can be deployed anywhere. In any vendor’s cloud and/or on-premises. Gateways communicate to the management service iby making API calls (feature known as “phone home”). In this model, it’s the gateways responsibility to establish the communication to the “mother ship” (management service) and not the other way around. Because of this, the management of gateways becomes a lot easier as there is no need to open firewall ports (i.e. opening firewall ports) as all communications are outbound triggered.
  • Identity Cloud Service: Most organizations already have their own LDAP directory (i.e. MS Active Directory) where users and roles are managed. The Identity Cloud Service is used to allow the API platform to use an organization’s existing directory as the source for users and roles.

Also, the platform supports five user roles (Described in blog by Kress)

  • Administrator: Super user of the platform. Has all rights to deal with user settings and also create/manage APIs and configure gateways.
  • Gateway manager: Role responsible for the gateway operations including deploying, registering, and managing gateways.
  • API manager: The API implementers roles as it gives users full lifecycle rights, including design, create and deploy APIs and also manage the API grants.
  • API designers: Individuals who take on a full or part-time responsibility (i.e. an architect or developer) to define APIs (either in swagger or API blueprints) using Apiary.
  • Application developer: In other words, these are the API consumers. Users with this role can log into the portal and search/subscribe to APIs.

The platform also supports service account used by the gateways to communicate with the to the management service via the platform API. Users assigned this role can’t sign into the Management Portal or the Developer Portal. This is named as “Gateway Runtime”.

The platform allows users to be created and assigned to any of the above role except Gateway Runtime.