Oracle API Platform Cloud Service Overview
Oracle has recently announced the release of Oracle API Platform Cloud Service.
Here the official press release.
This new platform -not to be confused with Oracle's previous solution, has been built almost entirely from the ground up to satisfy modern API management requirements.
I have been lucky enough to be part of the beta programme and have actually been implementing the product for the last 4 months or so (but trying it for almost a year now). In this blog post I share some of the insight and experiences I've gained in the process.
What is the Oracle API Platform Cloud Service?
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.
In addition with the incorporation of Apiary into the portfolio, the platform also incorporates a solid/world-class API-first solution so developers also get the tools and means to properly design APIs either using Swagger or API blueprint (Apiary's own API design notation), whilst interacting with the API consumers and therefore ensuring that before any code is built, the API contract is fit-for-purpose.
API Platform Architecture
The platform consists of 7 key components as the diagram illustrates:
The platform by default support 5 types of roles.
Tutorials and Presentations
As mentioned earlier, I've had the opportunity to use the Oracle API Platform for a while now. Below two insightful presentations based the experience implementing the platform:
API Management and Microservices, a Match Made in Heaven
Oracle Code: London, April 2017
Oracle API Platform Cloud Service Best Practices & Lessons Learnt
PaaS Community Forum: Split, March 2017
Other related presentations:
Conclusions
Since I got my hands into this product, I have been really impressed with the elegant, simplistic yet powerful architecture of the Oracle API Platform. It's a considerable step forward from it's predecessor solution but most importantly it was built with modern requirements in mind -meaning that the product doesn't really have any major baggage.
The platform in addition to be lightweight does not enforced an API implementation path. Customers will not be locked into an end to end vendor-stack. For example when using the Oracle API Platform, API applications can be implemented using any technology of choice. This is ideal in microservice architectures where the majority of developers prefer a polyglot programming style. Other vendors for example will force you into a specific implementation path to implement, test and deploy your API applications -which results in vendor lock in.
Because gateways are also fairly lightweight (although I've already heard that future releases of the gateways will be even more lightweight), they really are microgateways and cannot be compared to the traditional appliance-centric, heavy-weight, second generation API platforms.
One more feature that really makes the product unique is the "phone-home" feature of the gateways. What it means is that gateways make a call to the management service to get all instructions regarding APIs to deploy and policies to apply. Meaning that more and more gateways can be added without the typical operations burden of opening firewall ports and troubleshooting failed deployments by looking at logs...
Lastly, the acquisition and incorporation of Apiary into the solution, truly is the icing on the cake! as the solution not only has a simple -yet robust runtime environment, but also a best-in-class API-first design capability.
Well done Vikas, Jakub, Darko, and Robert and the rest of the Oracle product development and engineering team for finally releasing a world-class future-ready API platform.
If you need help or want to know more about Capgemini's Oracle API Platform offering, please refer to this link.
Here the official press release.
This new platform -not to be confused with Oracle's previous solution, has been built almost entirely from the ground up to satisfy modern API management requirements.
I have been lucky enough to be part of the beta programme and have actually been implementing the product for the last 4 months or so (but trying it for almost a year now). In this blog post I share some of the insight and experiences I've gained in the process.
What is the Oracle API Platform Cloud Service?
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.
In addition with the incorporation of Apiary into the portfolio, the platform also incorporates a solid/world-class API-first solution so developers also get the tools and means to properly design APIs either using Swagger or API blueprint (Apiary's own API design notation), whilst interacting with the API consumers and therefore ensuring that before any code is built, the API contract is fit-for-purpose.
API Platform Architecture
The platform consists of 7 key components as the diagram illustrates:
- 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 organisations 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 organisation's existing directory as the source for users and roles.
The platform by default support 5 types of roles.
- 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 responsable 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.
- Gateway runtime: Not really a user role, it's a 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.
Tutorials and Presentations
As mentioned earlier, I've had the opportunity to use the Oracle API Platform for a while now. Below two insightful presentations based the experience implementing the platform:
API Management and Microservices, a Match Made in Heaven
Oracle Code: London, April 2017
Oracle API Platform Cloud Service Best Practices & Lessons Learnt
PaaS Community Forum: Split, March 2017
Other related presentations:
UK Oracle User Group 2016 (Birmingham): Enterprise API Management
Oracle Open World 2016 (San Francisco): Microservices and SOA
Oracle Open World 2016 (San Francisco): Implementing Enterprise API Management in the Oracle Cloud
Oracle Open World 2016 (San Francisco): API Management in the year 2026
AMIS Beyond Horizon (Utrecht) Microservice Approach for Legacy Modernisation
Conclusions
Since I got my hands into this product, I have been really impressed with the elegant, simplistic yet powerful architecture of the Oracle API Platform. It's a considerable step forward from it's predecessor solution but most importantly it was built with modern requirements in mind -meaning that the product doesn't really have any major baggage.
The platform in addition to be lightweight does not enforced an API implementation path. Customers will not be locked into an end to end vendor-stack. For example when using the Oracle API Platform, API applications can be implemented using any technology of choice. This is ideal in microservice architectures where the majority of developers prefer a polyglot programming style. Other vendors for example will force you into a specific implementation path to implement, test and deploy your API applications -which results in vendor lock in.
Because gateways are also fairly lightweight (although I've already heard that future releases of the gateways will be even more lightweight), they really are microgateways and cannot be compared to the traditional appliance-centric, heavy-weight, second generation API platforms.
One more feature that really makes the product unique is the "phone-home" feature of the gateways. What it means is that gateways make a call to the management service to get all instructions regarding APIs to deploy and policies to apply. Meaning that more and more gateways can be added without the typical operations burden of opening firewall ports and troubleshooting failed deployments by looking at logs...
Lastly, the acquisition and incorporation of Apiary into the solution, truly is the icing on the cake! as the solution not only has a simple -yet robust runtime environment, but also a best-in-class API-first design capability.
Well done Vikas, Jakub, Darko, and Robert and the rest of the Oracle product development and engineering team for finally releasing a world-class future-ready API platform.
If you need help or want to know more about Capgemini's Oracle API Platform offering, please refer to this link.
Great news for the Oracle Cloud Startup Accelerator program team, mentors and startup entrepreneurs.
ReplyDelete