Oracle API Platform Cloud Service Reviews

In our organization, we use Oracle API Platform Cloud Service primarily to host and manage our middleware APIs. Our middleware APIs are registered on this platform and exposed to a fixed domain, which supports our organizational goals effectively.

Since our enterprise has many APIs, Oracle API Platform Cloud Service helps us maintain all of our APIs, secure them, and build our applications around that. We are able to monitor the APIs with the features that the platform offers. The cost and maintenance aspects are quite manageable.

The security mode and the deployment process are significant assets, offering simplified deployment and effective troubleshooting options, including Docker support. This solution simplifies API management and security with common mechanisms such as WAF and basic authentication.

Currently, there is nothing in particular that we feel needs improvement. However, in future updates, we might be interested to see more enhancements after exploring the existing features over the next year.

I have been using Oracle API Platform Cloud Service for over 15 years.

With regard to stability, I would rate Oracle API Platform Cloud Service between eight to nine on a scale of ten. It is quite stable for our use cases.

Oracle API Platform Cloud Service is quite scalable, although there is always room for improvement. As our APIs grow, there is potential for enhancing scalability further.

We receive good support from Oracle, and there have been no delays in responses or issues with the resolutions provided.

Positive

Previously, we explored MuleSoft. The pricing and licensing were prohibitive. Also, I have worked with APG. However, Oracle API Platform Cloud Service is simpler.

The initial setup was relatively simple and not very complex for our technical team.

We have a DevOps team consisting of four members who are involved in the deployment and maintenance.

There is a financial benefit from using Oracle API Platform Cloud Service as it allows us to maintain and secure our APIs efficiently, contributing to cost management and maintenance.

The pricing and licensing are considered competitive, especially since our enterprise uses multiple Oracle products, which makes the integration seamless and cost-effective.

We evaluated MuleSoft and considered others like EdgeMix. We found those solutions not as cost-effective as Oracle.

I would recommend Oracle API Platform Cloud Service to others as it provides a comprehensive solution for managing APIs, especially for enterprises. My overall rating would be nine out of ten.

Oracle API Platform Cloud Service's UI is quite user-friendly and supports a hybrid deployment model. Oracle API Platform Cloud Service was picked up by some of my former colleagues some years ago before I started working on that product.

The product has features like it can run hybrid. With Oracle API Platform Cloud Service, you can run gateway nodes wherever you want to. I personally feel that the product is quite heavy. Its policy package is nothing beyond or more exceptional than any other vendors in the market.

Oracle API Platform Cloud Service has this gateway which runs as an application inside the WebLogic server. The WebLogic server itself is quite huge. They should have something very lightweight to run this gateway, like NGINX. Right now, it's quite heavy. Oracle API Platform Cloud Service provides an API documentation tool, which is quite outdated. They support more of a blueprint while the market goes with OpenAPI.

I have been using Oracle API Platform Cloud Service for two and a half years.

Oracle API Platform Cloud Service is quite an unstable product for us. We have seen the product behave unevenly in several scenarios. Since Oracle scrapped its product development team, we usually try to solve issues ourselves.

I rate Oracle API Platform Cloud Service a three out of ten for stability.

I rate Oracle API Platform Cloud Service a five out of ten for scalability.

We've been struggling with the solution's technical support. Each time we raise a support case, we first have to convince some first-line support team that it has to be checked by some technical person or the development team. Then we have to wait a while before somebody from the development team joins.

Then usually, the standard answer is that they are not making any enhancement to this product. They will say that they will try to find a workaround. Later, they will try to sell the native gateway they have within Oracle Cloud.

Negative

I rate Oracle API Platform Cloud Service a seven out of ten for the ease of its initial setup.

Oracle API Platform Cloud Service's deployment model is not fancy and does not support Kubernetes-based deployment. So Oracle gateways can be set up in VMs. So even if it is on-cloud, you need to get your virtual boxes, have a Linux box inside, and then set up a gateway.

We have deployed the solution on VMware virtual machines. We have some nodes in the Azure cloud, but they are not in production. The ones which we are running in production are on-premise.

If things are automated, one server engineer can do the deployment in an hour, but it will take at least two hours if it has to be done from scratch.

Oracle API Platform Cloud Service is a cheap solution. I have never seen any other product which is as cheap as Oracle API Platform Cloud Service.

There are no additional costs apart from the standard licensing fee. We also received a discount.

On a scale of one to ten, where one is cheap, and ten is expensive, I rate Oracle API Platform Cloud Service’s pricing one out of ten.

We are using the latest version of Oracle API Platform Cloud Service.

Oracle API Platform Cloud Service is a cheap solution. It supports hybrid installation, and it's got the required policies. The solution also supports a single sign-on. We got Oracle identity cloud service for free, which we use for authorization servers.

The solution is good, given the cost and basic things, but its performance, maintenance, and setup have not been good. We would have liked it if they hadn't scrapped the product and worked with us to enhance it a little bit.

Overall, I rate Oracle API Platform Cloud Service a six out of ten.

We use it for both internal purposes and in cases where there are third-party integrations.

We primarily use it for logging with a third-party logging tool, log notifications, and some custom functions.

API security features within Oracle API Platform Cloud Service are okay. I am satisfied with the API security features within Oracle API Platform Cloud Service.

The analytics features are also helpful in the Oracle's API platform. The log analytics are quite good. They provide detailed logs, making it simple to pinpoint issues and troubleshoot. The analytics are well-presented.

Additionally, I find the customizable dashboards convenient. When you have a privatized dashboard, it's easy to log in, get an immediate snapshot of what's happening, and quickly address any problems.

One thing I find personally valuable in OCI (Oracle Cloud Infrastructure) is the ability to completely privatize API access through the console if desired. This level of control is streamlined and well-defined. 

I feel it's an area where this product has an advantage; for example, Azure doesn't offer the same refinement with private subnets. Others are developing, but OSI has a nicely designed architecture for this.

Even when an API is functioning correctly, there seems to be a glitch within OCI (Oracle Cloud Infrastructure). We occasionally need to refresh and wait; then the same API starts working again. I'm not sure why this happens. This can be frustrating as it takes time to refresh and get things working properly. That's the main difficulty we face; otherwise, it's fine.

The internal portal functions well. However, when it comes to connectivity with internal photos or DNS domains, there's room for improvement. It could be a bit more user-friendly.

I've been working on this for the past three years now.

In terms of core infrastructure, the stability is quite good. But, there's always room for improvement, especially in areas like DevOps or other services outside the core infrastructure. Since I enjoy working with OCI, I'd like to see those areas developed further.

Overall, I would rate the stability of infrastructure a ten out of ten.

It is scalable. We primarily work with enterprise customers.

OCI support can take a long time to respond. Sometimes, when working on deployments, we need faster resolutions and have to find workarounds ourselves. 

Neutral

Since we are familiar with OCI, it's easy for us to install and handle the other processes. However, if someone has limited knowledge, it can be a bit difficult.

I find OCI to be highly professional yet understandable. If someone has the technical expertise, it's easy for them.

Sometimes, if there are glitches, it can take a while. We occasionally face situations where we're unsure if the installation is completed. Refreshing the page is often necessary, and sometimes it installs correctly afterward. This can feel like a lag. Aside from those glitches (I'm not sure what's happening on the backend), the processes, policies, and security aspects are all quite good.

However, maintenance is easy.

In comparison, platforms like Azure might be a bit more user-friendly, even for those without extensive technical knowledge.

Pricing depends on the specific services used. Some services are more affordable compared to other platforms, while some are more expensive. It also depends on the client's budget.

For the infrastructure side of OCI, I'd rate it a nine out of ten. There's always room for improvement, but it's a solid solution.

There are aspects they could work on to make the experience even better. I'd recommend focusing on the convenience of the infrastructure, the robust networking capabilities, and the excellent security features for full privatization. Also, be aware that while some platform services have occasional glitches, they can offer cost-effective solutions.

We use the solution to manage APIs.

The solution's cost in terms of scaling could be better.

We have been using the solution for more than a year.

It is a stable solution.

I rate the solution's scalability a ten out of ten. However, it is costly to scale.

The solution's technical support is good.

Neutral

The solution's initial setup process is easy.

Our vendor helped us implement the solution.

The solution is expensive to scale.

The solution is stable. But, additional costs are involved in case of an increase in usage. I rate it a seven out of ten.

API management to public and internal services. Supporting a microservice model so that the microservices dont get accidentally bound together.

The primary goals are:

-Security

- Audit

- Measurement of service utilization

- Accelerate digital enablement

Agility and ease of establishing new APIs and configuration.

Deployment processes far simpler than other Oracle middleware tech such as SOA for example

Neutrality of where you can deploy a gateway. I have had gateways running in AWS and on-premises running the same API policies. Deployment is pretty easy once you understand what the configuration properties do. The ease by which you can define policies to manage is impressive.

The product continues to improve and becomes more feature rich.  We know that there are tools to more closely integrate with Configuration Management.  Features to make more of Identity frameworks.

3 to 5 years.

The product has been very stable. The challenge is the product is getting new features at rapid pace. Earlier versions of the gateway element need to be done manually, although this has been automated more recently.

None encountered so far (the deployment model). If anything the procing model lends itself well to scale. The core engine is very high performance as it has drawn capabilities from the telco.

Customer Service:

Like all Oracle solutions, it is often about building a relationship with knowledgeable contacts.

Technical Support:

Technical support has been great, but the contacts developed being a beta user have made a difference.

We have used previous Oracle solutions combined with non-Oracle products.

Compared to older products the setup was very simple, for example SOA Suite. Although, as a cloud solution, it is more complex than ICS.

Implemented ourselves.  Talking with Oracle product management and A-Team has helped understand how to get the most out of the platform. This knowledge uis slowly becoming available.

The value proposition is more about what has enabled.

Oracle have switched to a new consumption based model - if you're an existing Oracle PaaS customer - migrate to that as it also brings additional benefits.

Look at the best practise for deployment - more than likely reduce your cost forecast

Yes, a wide range of products, including IBM Power Systems and others.

Think about how many environments you will need and managing how you progress from development to production.

We are using this solution for our providers in Sweden.

Several business functions are exposed to various customers, suppliers, and partners. Oracle API is used to expose their critical business functions to the stakeholders.

We were using an interface for orders where all of the orders that we were receiving were through text-based files from different suppliers, and partners. Now, we have created one order API and exposed it to our various customers. It is also available for our web-based application portal that the other customers were connected to, directly.

They can place orders directly using this API. 

We were not using real-time ordering before this. All orders are now in real-time and we are adding extra features that can tell us who is placing the order and the different levels of access to different types of customers. We can also do direct limiting with API PCS. We have improved our order module with the use of this API.

The most valuable features are the easy integration with the Oracle cloud, and that it's easy to use.

The on-premises connectivity can be improved because it is still not at it's best. I still have to install a gateway on-premises, then a firewall API management portal on the cloud. 

In the next release, I would like to see more security policies and for it to include an on-cloud gateway. 

I have been working with this solution for approximately one year.

This solution is quite stable.

This solution is very scalable.

We have approximately 300 end-users who use this solution.

The technical support is good. We contacted them a few weeks ago.

Previously, we did not use another solution.

The initial setup was ok, it was not complex.

The deployment was pretty quick, but it took a couple of days to complete the setup. We have a team of two people who are in IT to maintain this solution.

We used a consultant to help us with the implementation. The experience was good.

Not very expensive as compared to other API products.

We did not evaluate any other products. We were already using Oracle, which is why went with this solution.

I would suggest that you evaluate a few products before you choose. Oracle API is good; it's not the market leader, but I would say that the most up-to-date functionalities that you would be looking for in an API are in Oracle. It's also quite stable and their cloud data centers are very stable.

I would also suggest that you define the API before you start implementing any large program. An API strategy is very important before you start setting up a platform. If you don't do API applications, then it doesn't make sense to go with this solution or platform. It will only help when you have a well-defined principle for the API in your organization.

I would rate this solution an eight out of ten.

API Platform is used to manage and monitor APIs as they are published to consumers, both internally and externally to the organization. The cloud service allows us to register all of our APIs as a catalog, link to the Apiary documentation for each API, apply policies (security and usage restriction) to the runtime endpoints, and monitor usage through analytics.

The API Platform has provided a consistent place to administer OAuth 2.0, Access Key, and other policies across groupings of APIs. It has also allowed standardization in the definition and documentation of the APIs. Rather than APIs being documented in a Wiki and shared through ungoverned Postman collections, we can have more fine-grained access and authorization rules as to who can use which APIs. All API usage is now governed and tracked.

The linkage to Apiary and the validation between the API documentation and the resource endpoints has ensured our documentation and implementation stay aligned.

There is an API Gateway for which all runtime traffic routes through to access the API endpoints. The fact that this gateway can be deployed on-premise is an important feature for our financial services projects.

The Call Home pattern that the gateway employs allows the security team to be comfortable with the link between the on-premise runtime and the cloud definition of the policies.

The APIs to retrieve the list of APIs should be improved. The need to allow token-based authorization with grant types other than the current password types, allowing us to integrate the API more easily into our public facing custom developer portal. Currently, only tokens generated by the Oracle Cloud login screen can be used.

There should be closer integration between the API Platform Cloud Service and the Identity Cloud Service to allow IDCS Applications, protecting backend systems, to be linked to the API Applications that consumers use to access APIs.

We have no current production issues with stability.

The gateway is lightweight and highly scalable in our experience.

Oracle Product Managers are open to feedback through partners and support of API Platform has been swift. Challenges arise when issues fall between two cloud teams, e.g. API Platform and Identity Cloud Service, so precision and patience are needed with the definition of the problem for Oracle Support.

We used a Service Bus previously. The API Platform has better native support for REST and the Gateway is more lightweight.

Once the architecture is understood, it is simple to configure and setup. The instructions for gateway setup are clear and concise.

We implemented this solution for our client using the Griffiths Waite development team.

This is part of our new digital offering for customers and has helped with new prospects to offer a modern secure API solution. Therefore it is having a real impact on the business adoption of API integration for customers.

The pricing is for each logical gateway (a logical gateway can have multiple physical nodes).

The cost is very competitive for the average load that we expect. However, there is a minimum charge of one gateway, even if no gateway is active, so make good use of the trial before subscribing to check that the product is suitable.

We looked at Kong and IBM API Connect.

There is a clear roadmap for support of standards in documentation and policies. I am keen on the fact that modern consumption protocols, like GraphQL, are also considered. At the moment you can have one policy per GraphQL service, but it would be good to have better granularity. How the platform links in with events is also a topic to consider on the roadmap.

Since I see API Management as a key enabler for digital transformation and for growing new digital economies, an consistent API Management strategy is important to define. Consequently, an API Management platform is an essential architectural component in today's applications architecture, which needs to be capable for covering the complete API lifecycle from definition to retirement, supporting an API-First development approach, because with that development of new services and functionalities can be done more efficient.

With API-first, the platform provides a consistent and comprehensible philosophy. It definitely influences:

• The way we think how APIs should be developed.
• What API Management means from a implementation perspective.
• What API Management means from an organizational perspective.

Oracle's APIP CS is a platform capable for consistently covering the complete API Lifecycle from design to retirement, supporting an API-first approach. The platform provides a strong and intuitive API Design platform, which allows the collaborative creation of new API Designs in an efficient API-first manner.

Furthermore, APIP CS provides a lightweight, flexible architecture and offers a hybrid deployment model, where the API Gateway components can be installed either to Oracle Cloud, third-party cloud providers (Amazon, Azure), or On-Premises.

This allows the creation of very flexible, agile API-driven architectures. This Micro Gateway approach, is especially valuable in Microservices architectures. The Gateways are communicating with a Management Service, which lives in the Cloud, to send usage information or to fetch changes for the deployed APIs. The advantage of this "Calling home" mechanism is that there's no need to define firewall exceptions, since it is an outbound communication.

APIP CS Management Service is a cloud-based application, running only on Oracle Cloud. The Management Service has been built following the API-first principal and is a cloud-native application. The corresponding UIs (Management Portal, API Catalog) are very intuitive and therefore easy-to-use. The implementation and management of new APIs is straightforward. There is not a high learning curve.

I would like to see enhanced support for SOAP Service and the corresponding WS-Security policies.

We did not encounter any issues with stability.

We did not encounter any issues with scalability.

Technical support is good, as far as we can see. The community around the platform is growing and is sharing knowledge.

We did not use a different solution before.

Since it is a cloud-based platform, there isn't that much of an initial setup. The only things that really need to be installed are the corresponding API Gateways. This might be tricky the first time, but afterwards, it shouldn't be a problem.

Thinking about the general Gateway architecture is essential, especially with respect to the potential number of API Calls. Typical questions that should be answered in this context are:

• Where should the Gateways be deployed?
• Do we only need Gateways for external access (DMZ) or do we also need internal Gateways (Green Zone)?
• Which APIs need to be deployed to which Gateways?

To guarantee high availability of your API Gateway components, corresponding solutions should be established (Implementation of Load Balancers). This is especially important when you have critical SLAs like guaranteed availability.

We also evaluated the MuleSoft AnyPoint Platform.

The API-first approach should be used, since it provides a lot of benefits, like consistent API Design or increased development agility. I recommend to adopt this approach and the philosophy provided by APIP CS to get the most value out of APIs.