The product offers numerous features, but our organization primarily utilizes only a few of them. While I focus on the essential features required for my work, I'm aware that there are many other features within the product that I rarely or never use. Therefore, when evaluating the overall performance and capabilities of the product, it's not outstanding. The features we do find valuable work well, but there might be shortcomings in other areas. To provide meaningful feedback or identify weaknesses, I would need to have a comprehensive understanding of how the product supports a diverse range of customers and their experiences. Otherwise, it wouldn't be fair or practical to pinpoint specific issues.

I am still struggling to understand how we can use Apigee as a hybrid system. The pricing of this solution could also be improved as there are multiple new products coming onto the market at competitive price points. Many of our customers are trying to move away from Apigee. They are considering open source platforms like Akana, Kong, Boomi and Mulesoft. 

One feature they have to invest time into is the developer portal they use. They do not have a good development portal. It's not easy to use, and you can not take advantage of the developer portal. You have to start creating your own developer portal and use the old API management to publish your API market.

Technical support could be better and more local.

We have looked at MuleSoft as well, which is a competitor. MuleSoft has a richer set of integrations for an iPaaS solution. There's an IP gateway that we're using Apigee for, however, it cannot be used as an iPaaS, whereas the MuleSoft solution can be used as both an API gateway and an iPaaS. We've started talking to Google about their iPaaS solution, however, it doesn't play nice yet. 

They have an external developer platform that was a little bit painful. They do have some built-in developer tools, however, you can build an external development portal. It would be nice to have a built-in bundle that was more complete.

Our focus on improvement primarily revolves around security, differing somewhat from the Connect endpoint. We've encountered challenges in leveraging Connect functionality, prompting us to explore additional tools, such as Fergus, to address implementation and security issues.

The only concern overall, with the organization, is cost-wise. I believe there is already a plan, within our organization, for moving to Azure API Management. The main reason is one of the features is a cloud-based, pay-per-use. And then, because a lot of our services are moving towards Azure, why have another network of API gateway.

The testing feature is one additional feature that I see is in APIM and it is not here. We can build our own demo web service and test your proxy. That feature has been provided in APIM, not in Apigee.

Apigee could improve by integrating with more identity providers and offering a default authentication module. This would streamline user authentication processes, allowing for easier integration with directory providers like Ping Server or Active Directory.

The technical support could be improved because their response time is slow.

We started using the solution not so long time, however, it still started from scratch. So far, we have no improvements to note.

The solution could add even more functionalities. 

Some customers are moving away from Apigee to other tools like Kong. The product’s licensing model is very expensive. Apigee is completely SaaS-hosted. We do not have control over the installation. API management solutions like Kong have a very good separation of concerns between the control and data planes. Apigee does not have such features.

I don't see any problems in Apigee where improvements are required.

Apigee is not a solution compatible with public clouds, making it one of its shortcomings where improvements are required.

In the future releases of Apigee, I would like it to offer more cloud compatibility features.

Compared to its competitors, such as Axway AMPLIFY API Management and Layer7 API Management, Apigee could benefit from having more policies to cater to various use cases. This would reduce the need for writing custom JavaScripts. If more features come straight out of the box, we can leverage them instead of writing custom code to achieve the same functionality.

The product has a few restrictions I'd prefer weren't there.

We have trouble finding use cases. For example, when we google "data locator" we can't find a use case scenario at all. We can't find more than, approximately, five use cases, however, we need more.

We needed to do more than 20 configurations, and we weren't able to do that as the limit is 20 on the solution.

The solution tends to hide the limitations to keep selling the product. I can't blame them for doing it, however, it makes it difficult for those of us who eventually sign on.

The solution is expensive.

An area for improvement would be to provide more information while troubleshooting. In the next release, Apigee should allow product owners to use its tools instead of just platform engineers.

The analytical aspect of it could be better. I think it is fair if Apigee lets you configure some of the metrics of the key details you want to monitor in terms of analytics.

In terms of the functionalities of a typical API gateway, Apigee is actually doing its job, but when it involves integration with backend applications, which some gateways have, I don't believe it has this functionality. You have to do Java or do some other low-level coding before you are able to do the integration.

Apigee has a lot of components, which means that management will be a bit difficult. It probably has ten different components, and all of these components leverage open-source utilities, such as NGINX. When those open-source vendors upgrade their utility, Apigee usually lags behind because they need to do a lot of tests and any required development in their own platform. They need to do rigorous testing to make sure that nothing breaks. Because of that, it takes them a while to upgrade whatever components have been upgraded by the open-source vendor that owns the utility. We've been chasing them for a particular upgrade for well over a year and a half, and they have not done that upgrade. It is creating a security risk for us as an enterprise, but that upgrade has not been done, even though the open-source vendor, the owner of the utility, has upgraded it a long time ago.

The number one area this solution could be improved is by implementing support. Support is not a part of this solution.

I would like to see the support improved. I think the time frame should be shorter for responses when it comes to technical support. This is not the ideal situation you want to be in when you need support.

The caching capabilities are somewhat limited. This is more on the developer-oriented capabilities.

At this point, we aren't sure of what else could be improved since we are migrating some pieces of code that are really legacy and really difficult to model as a standard REST API. We are not sure in which areas Apigee is going to fall short. I think that next year we will have a more clear picture of some issues that we are going to find that could be addressed by a new feature, or by enhancing some existing feature in the next versions of the tool.

When compared with other products and tools in the market like MuleSoft or other API management solutions, I see some lagging in regards to integration capacity — where we don't have all of the connectors. It's not the perfect ESB, it's only for API management solutions. For example, MuleSoft will provide you with the API management solution as well as ESB, allowing you to integrate with large, complex IT systems. So, there is some lagging there that needs to be fixed. 

The main area they should improve is the integration capability. They should have useful connectors that we can use to provide code so that we can integrate with other systems. This needs to be improved.

When compared to other products, such as MuleSoft and other tools in the market, Apigee has some lagging issues. 

I'm not a fan of the developer portal. It should be simplified. There is an excessive amount of customization required. 

When compared to Azure, Azure is more user-friendly to customers.

Monitoring could be improved. Google Cloud provided better monitoring than Apigee. 

I still prefer monitoring in Azure or Anypoint MuleSoft.

It also requires additional tools to assist in the deployment of Apigee.

I would like to see the monitoring, dashboards, and reports improve.

The only disadvantage with Apigee is that they lack market presence. I think they may have limited resources. IBM's strategy is stronger on the marketing level. 

I believe they're working on adding some integration features that are currently lacking. 

Right now we can create custom policies using Java scripts and other supported languages. That's the good thing. But if you are supposed to have created some APIs that are available on the market as public, it would be good if you can share it. It would give a bit more flexibility and then connect configurations that you can do on your own which are not supported by APIs.

From a connector perspective, it would be good if it could allow you to create a custom connector, or it could provide out-of-box connectors, or some in the backend. That would be great.

They need to work on the cost of the solution. But again, it depends on the use case. The use case which I have installed serves the intended purpose. I don't have any negative feedback on it.

The solution can be improved by simplifying the account creation process.

We are experiencing issues with automation; the production in Apigee is quite time-consuming. 

The integration with serviceability also needs improvement. It gives our developers access. We have a developer who can deploy the APIs to the platform. As a result, they are encountering some difficulties in automating those processes. Stability relies on whether those issues can be addressed in any other API gateway.

I'd like to see the automation, time to release, time to market the new APIs, and pushing the APIs from one environment to another, to production, improved in the next release.

It is time-consuming; according to the information I have received, it can take up to two months for any new API to be published for production. I'm not sure what the difficulties are in between, but this is what I'm dealing with in this segment.

While I don't have the hands-on experience, in my opinion, and based on my research, it is not very user-friendly in terms of user experience, or UIUX.

The company needs to better support webhooks. It used to support webhooks and their policies and they have since stopped. They had some issues in the product and they abandoned the support for them. It's not come back since. Webhooks are still used by some of our production partners. It would be nice to see the support for them come back. Right now, we have to pull the API instead of using a webhook to do the notification.

Apigee deals with APIs. However, most of our clients need more tailoring done to the solution.

Google isn't enthusiastic about supporting older versions. Google is now trying to move all of its clients to X within the cloud. However, some still want on-premises. 

I would like to see better integration and some architectural improvements in future releases of the solution. 

We are considering scalability regarding using a centralized environment, and the documentation seems to indicate it's not easy to integrate with Kubernetes or deploy into a cluster. 

It's not using SPA, single page applications, like Angular. 

There isn't very good monitoring right now. We need better performance monitoring.

We need it to offer better debugging, so if there is slowness in the flow, it's not easy to fix. You have to use other tools to debug.

I have heard there maybe be some security issues that need to be addressed. If this is the situation I would encourage taking a look at the security matters.

The cost of this solution could be improved and it would be better if it were on private cloud. 

They should improve the solution's monitoring tools for on-premises environments. Also, they should make all the essential features available for the private cloud.

I would like to see SOAP services and socket-based connectivity developed. Apigee is known for exposing the REST API but not the SOAP API. Our clients are requesting these two features and we do have a workaround we use, but an upgrade in these two areas would be great. I would like to see more integration for example Enterprise Service Bus and this will help Apigee gain more popularity.

The solution is pretty expensive. 

The developer portal's adoption of the OpenAPI standard needs to be improved. In the latest version of the developer portal, they have adopted the OpenAPI standard. This feature, however, can be improved by supporting more characteristics of the OpenAPI standard.

It is a user-friendly solution, but it would help if Google could provide a container-based solution instead of just a standalone one. With a container-based deployment and support for Terraform, it would be better for our deployments and that would be great. Right now we have to configure different areas manually. Some areas can be automated, but the deployments are not as fully automated as they could be otherwise. 

so, they currently have a software as a service offering or a standalone offering. I want to see something like a hybrid cloud deployment. I also want to see a private cloud deployment. 

I'd like this solution to improve on releasing new features; I'd like it to be more frequent.

In my opinion, I think that they should start thinking about improving the solution so that they can compete with open source. You get the support in the paid version, but open source features are being introduced much faster than Apigee's. New open source features come out every week. 

We found a glitch in Apigee, and we raised it with them: It's the response overlapping from the API with high traffic.

They have been working on that, and they have shared a patch with us, but I'm not sure if that is publicly available for all users. It was made available to our organization: one single patch of Apigee.

If the budget is not a concern then I will choose to go with Apigee over WSA-2, but if it is then I would prefer the latter solution. Apigee is quite pricey. The price is a thorny issue as there is little room for negotiation. 

Unlike WSA, Apigee does not have a partnership model, something which makes it a bit easier for companies such as ours to go with the former solution. 

While I cannot comment definitively on the partnership issue, as the company has yet to get back to me, I can say that this issue and the one of the pricing are why I choose to rate the solution as a six out of ten. 

The solution’s scalability could be improved.

When it comes to the rate limit, we don't have a specific category for rate limits for a particular customer.

Access restrictions can be improved. For example, you can't restrict access to some people or some groups. You have to give them total access. 

I would like to see a long-term direction for the overall architecture (similar to what WSO2 has done), in that all three areas — pub/sub, events, and APIs — are treated as part of a continuum, instead of treating each as separate topics.

The hardware is extremely high compared to other similar products. The entire user across all the layers should be singly authenticated through an external authentication system.

We are experiencing some performance issues. Except in terms of performance, we can't find anything that needs improvement. This is something that we are trying to understand, and we will fix it soon.

I'm dealing with the Google and Apigee teams directly, so I can't go into specifics. But I believe we will be able to fix it sooner rather than later. It will be one of the most extensive implementations. And while we did not find any performance issues during testing and development, we did find some in production. We will be in a position to fix it soon.

Our environment consists of multiple clouds. The usual question is whether you have a single environment or a multi-cloud environment. What I've answered is applicable to all multi-cloud scenarios. I haven't specifically mentioned the Apigee-related issues. In CA Cloud, that is Google, I am working in a multi-cloud environment with settings and cross-components.

More platform integration, lower prices, and improved performance are all potential improvements; however, when it comes to standardization, all of them are converging on standardization, but, my criteria are more performance-based.

Either one is focusing on the API or on alternative exchanges that can improve performance. As a result, making a choice of API and the use cases that surround it, as well as how the implementation is done for scale, can be difficult at times. When we talk about the scale, there are definitely a lot of considerations that must be understood, and one of them is performance, which is our primary focus area.

If you are going to use APIs or even exchanges, you should be more concerned with performance.

As of now, we have not found anything major that needs improvement. It is not something that we are heavily using, it's something that is still in the process of being adopted company wide.

Maybe securing the APIs could be a little bit more straightforward. There might be some room for improvement in the process of securing the applications that we're exposing through the API. We would like additional documentation on this or some examples of how to do it. Overall, we have had to invest more time than expected to do that setup.

It would be good if the Apigee management allowed us to be able to consolidate many operations into a single one for the gateway functionality.

The ability to work across different management solutions in a plug and play fashion would make it easier for faster uptake.

Pricing is an area that can be improved, as it is a little on the higher side. It is more expensive when you compare to open-source products or other vendors.

I think it would be helpful if Apigee had support for voice-activated activities, rather than having to type.

More intelligence in terms of being able to learn from previous activities would be a good addition in the future.

Apigee's user interface could be more straightforward and have more options. Also, it would be nice if it were ready to work out of the box without so much configuration. Regarding features I'd like to see, they could add self-recovery from the last hour, the last day, etc.

I don't have any notes for improvement. I don't need any extra features. 

I think the portal could offer a better user experience. It's functional and does what it's supposed to but it's not user friendly. I'd also like to see better routing features. Currently routing is limited and the setup is complicated. From a VPN management perspective, I think we would like to have more user training available, particularly for advanced users, without having to pay. There is generally a learning curve for advanced usage and configuration, and troubleshooting is a steeper curve. Whenever we have an issue, we're dependent on support. We'd like our personnel to be better trained by Apigee so we can handle issues in-house. 

Initial setup was not trivial for customer-managed topology.  Proxy versioning seems a bit confusing/buried in the publishing experience, especially for the URI-based versioning approach.

Integration should be improved as we'd be able to use solutions such as NewSoft or Del Boomi. It would be helpful if Apigee would lower their licensing costs. I'd like to see a cloud-based solution and some new features similar to those available with TD cloud or Salesforce.

Support of integration is what is most challenging in Apigee, as well as the complexity of the components. When setting up an environment, you have many components with open-source content.

When there is an update on a new version or an automatic update, you have to be present and double-check that the update is reflected in the environment with no issues.

The implementation should be easier.

It is best to ask a developer about the areas for improvement in Apigee, as I'm a content writer, though the pricing for the product was a bit higher.

Apigee would also need developers or a dedicated team for deployment. I also found it challenging to manage sometimes.

There should be an integrated continuous integration and continuous deployment approach with Apigee. Currently, for development at a more integrated level, you have set it up yourself.

It lacks the connectors and connectivity. That's something that would be good to have. 

iPaaS is something that we would like to see. For example, MuleSoft is kind of an integrated platform as a service (iPaaS), and it provides a lot of out-of-the-box connectors and other such things. This is where Apigee lacks. I'm not sure if that's the roadmap for Apigee, but any improvements on those lines would be helpful where things become easier to implement.

The Apigee cloud admin UI could be more user-friendly by adding a few more features.

More documentation on the Open Banking Standard will help. For example, WSO2 supports the Open Banking API, but I can't find relevant documentation from Apigee. I'm not sure whether Apigee even supports the Open Banking Standard. If they do, then I think they have left out the documentation for that. For example, WSO2 has extensive documentation and training available to everyone. In that sense, I think, Apigee can improve.

Apigee is demanding on the infrastructure so the setup cost is very high for an on-premises deployment.

Drag and drop of features would be more beneficial, rather than manually working on the configuration and updates.

The integration could be improved within the solution. There is a need to pay more attention to this. 

It would be ideal if the solution could provide publishing capabilities as API middleware.

The definition of the APIs should improve because you can't easily validate the inputs and outputs. Better functionality for validating inputs and outputs would be helpful.

The pricing of the solution could be improved upon. We'd like it if it was less costly.

The solution needs something that supports real-time streaming.

What my clients don't like is that the on-premises solution is not being treated and maintained as well as the cloud solution.

I know that they are working on the integration of no-code and low-code solutions to make it more accessible to users that have no technical background. This is something that I find very interesting and they should continue working on that.

As it is now, the rotation of certificates is a manual task and is something that can be improved. It only has to be done once every two or three years, but I would state that there is still room for improvement.

The solution isn't really lacking any features.

The user interface could be better. It could be easier to navigate and more user-friendly.

The pricing model could be improved. Things can get expensive for larger companies, or organizations that are growing.

The solution should offer more training to partners. It would help in the understanding of the product by quite a bit.

The installation and management of this product are still a clumsy task. They are developing the monitoring feature based on influx DB and Grafana, but it still has a way to go before it can be used in a production environment. The documentation for OPDK on different component integration is not available or not sufficient. Since it is based on various open sourced projects, we might have to depend on the fixes provided by those components rather than Apigee directly fixing the issues.

Areas like traffic handling of incoming requests, security features between third-parties and Apigee, and between Apigee and internal network servers, resources, or JSON areas, etc.

Role-based access management needs to be improved. It would also be nice if the solution could be integrated with code versioning systems like Git/Bitbucket.

Development IDE, especially for Architect Review.

Maintaining and deploying revisions need to be more defined.

It would be better to have access to the PostgreSQL Database Tables on monetization.

It would help with Apigee if we could make a list of our assets. If the client knows more about all the extensions they can use to work with through the Google cloud and we have an extensions database it would be easier to let them know what is available and we could do more to recommend Apigee for all different kinds of customer needs.  

Technical support model for OPDK should be more exposed and mature in terms of providing support during installation, run, and debug of Apigee in production on OPDK mode.

I would like them to add features, such as caching and mediation policies.

• Predictive analysis of consumption
• Identification of attacks
• Identification of operational errors
  

Apigee on premise is quite complex and it is always moving faster. I would advise anyone who is interested, to use the SaaS implementation.