Apigee Reviews

We are using Apigee as our API gateway.

The most valuable features are scalability and technical support.

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.

I have been using Apigee for four years.

We are working with a SaaS model and we install the on-premises model version also.

Apigee is a very stable product.

The scalability is incredible. We make an average of 22 million API calls.

We have less than ten people who are developers.

We have plans to increase usage in the future.

The technical support is very good and we are satisfied with it. They respond very quickly and I like it.

I have used several solutions previously, such as IBM API Connect, WSO2 API Manager, and many other API solutions.

It is not suited for small companies. It's expensive.

For a bank, it would not be expensive, but to implement this solution for a smaller company such as an insurance company, it would be too expensive.

The pricing is complicated and not flexible.

The older versions are more suited for small to medium-sized companies. You can no longer pay €20,000 per year.

This is a very good API tool.

I think that this solution is very good in some use cases but not very good for some small companies. It can be complicated for licensing and pricing. This is a product that I can recommend otherwise.

I would rate this solution an eight out of ten.

We are a solution provider and this is one of the products that we implement for our clients. We also it it ourselves.

Our use case involves accessing functions on our backend systems through a portal used on mobile devices. The app on the mobile device uses the internet portal, and we have the API as a security layer to pass the functions through to the backend.

It is very easy to implement and the configuration of the API is very simple.

It is easy to upload a Swagger file and build an API.

The user interface for building APIs is very simple. Anyone with basic knowledge can build an API.

Disaster recovery capabilities are included.

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

We have been working with Google Apigee for almost one year.

Apigee has high availability and we have not faced any problems in regards to stability.

We have not had to scale as of yet. Our license allows for 125 million messages and we have not yet reached that stage.

We have been in contact with technical support and we are fully satisfied. I would say that they go out of their way to support us. For a priority-one issue, Google commits to having it resolved within 24 hours.

There are also community blogs where you can find other people that are working with it. These are independent sources and people where we can get information about implementation as well as customization.

A new version is released every six months and if we don't upgrade in one and a half years, the old version will be deprecated or be out of support. For example, they recently upgraded the Edge UI. The old one was not integrating with Active Directory to allow for centralized control of users. However, the new one requires authentication from ADFS before implementing it, which was a feature that was previously lacking.

The entire set of documentation is available online. You can follow it step-by-step to install the application.

We have an in-house team that handles deployment and maintenance.

It is administered by two people and we have another person to handle the analytics.

The cost of the licensing is based on the number of API calls that are made. This is good because we don't pay for the number of nodes that we are installing. They also do not charge you for non-production transactions, which is extremely good.

Everything else is included as a package. For example, ZooKeeper, Cassandra, and PostgreSQL are part of the product, so we don't need to purchase any additional licenses apart from the OS.

We had evaluated Software AG at the same time as Apigee. The initial setup cost for an on-premises deployment of Software AG is less than that of Apigee. For example, if I require four cores to operate Apigee then it would be a two-core system for Software AG.

We chose Apigee because of its high availability and disaster recovery. Google Apigee uses ZooKeeper with an unstructured Cassandra database. This is different from Software AG, which uses a structured database like Oracle. Having to purchase Oracle licenses increases the cost.

My advice for anybody who is considering Apigee is that it is has a very easy and intuitive GUI to build APIs, and I can also import Swagger files. It is built on a high availability model, so if anything goes down then another node will automatically take over. We can build an active-active across the DR site.

The primary site is active, the DR site is active, and they are synchronized. It is easy to build, customize, install, and implement.

The support is also extremely good. We get immediate responses and support is available every day of the week. Google commits on the resolution time for priority-one issues as 24 hours. No other software today can commit to resolution time. I have only seen such a service with Google Apigee.

Overall, I am satisfied with this product and it is aligned to all of my needs.

I would rate this solution a ten out of ten.

We are a solution provider and Apigee is one of the API management products that we implement for our customers. Most of our clients want to expose their APIs to their consumers and they need to have a generic infrastructure for it. At the same time, they want it to be scalable as well as highly secure.

We have been able to fulfill all of our use cases with Apigee.

Tracing in Apigee is a very good feature.

The scalability and performance are both very good.

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.

We have been working with Apigee for five years.

The last time we had a disturbance was a year and a half ago, and it was due to an AWS infrastructure failure. Apigee was not to blame for it. For the most part, it has a very high availability.

We have some very large customers that make a billion API calls a month and we have never heard any complaints about scalability. It's not an issue.

About half of our clients are mid-sized companies, with approximately 5,000 employees, whereas the other half is made up of companies that are bigger than that. 

We have engaged multiple times with Google's technical support. I can't say that they're necessarily very quick in their response. It can take a couple of days. That said, they're very knowledgeable and to the point. In the five years that we have been working with them, we have built a big network with them.

We use several similar solutions including Mulesoft, SAP, and Azure. Mulesoft is the one that we use the least and try to replace it with other systems. Out of ten customers, we have two using Azure, six using Apigee, and the final two using SAP.

The initial setup is very straightforward and we perform it as a service for our clients. Normally, it takes us about a week to get it fully operational with all of the rules in place, and fully onboarded.

When it comes to deployment, we have variety with our customers. 60% of them will use a cloud-based deployment, while the remaining 40% work on-premises. We are now just engaging the first customers using the new hybrid model from Apigee.

We perform the deployment and maintenance of Apigee for our clients.

My advice for anybody who is implementing Apigee is to use it as an API platform, and not as a full-stack integration platform.

I would rate this solution a nine out of ten.

The primary use case for this solution is to integrate both external applications as well as internal applications. We use some to integrate other applications, but most of them are just proxies that are for fronting the backend APIs.

We want to create one API to be used by different clients. In terms of management, even though the proxying of an API is not a lot of work, it is better to create a single API that can be reused. When the API version changes, you only have versioning for a single API, rather than in several places with the same capability.

Moving forward, if you change or update the version, the underlying functionality of the application needs to fashion the APIs correctly. This solution is created for the same capability. To prevent that, we just create the same API, and then we productize it and you are versioning a single API and not going back and versioning different APIs that do the same thing.

One of the concepts offered with this solution is called Productization. This concept allows you to bundle the APIs together and present them to clients as products, which allows you to configure the API with restricted access for different clients. An example of this would be Client A is granted access as read-only and able to do a few updates, whereas Client B would have full access to the APIs. You can configure different products for them in such a way that one of the products would have limited access, and the other would be granted full access. You are not creating another API, rather you are using the same proxy with limited access to the proxy. This is one of the features that has helped us a lot. 

We have APIs that we use internally and externally for clients outside of our network using the cloud with a SaaS solution that needs to access our API. The same API we use internally is the same API we expose externally. The level of security is different for internal applications and for external applications. To accommodate both we use the same API but add additional security features to the APIs.

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

I think that this solution is pretty stable, but when the open-source vendors upgrade their software, Apigee doesn't conform with the upgrade of the open-source vendor. They require patch releases and an upgrade for on-premises users. The component is always late.

I think it's pretty scalable. Currently, we are doing about sixteen million calls per quarter. As we are not using it on a large scale, we don't usually have latency issues whatsoever. We have a clustered environment and there is little to no downtime, even when we are running patches on the operating system. We have between twenty-five and thirty regular developers that use this platform. We have four nodes in the cluster that are serving internal traffic, and then we have another four nodes for external traffic so that way we don't really require any upgrade.

At this time there is no immediate need to scale up the environment. We have four servers with four nodes in the cluster that service the internal traffic, and we have another four gateway nodes for the external traffic.

The support is lacking. One of the main reasons it is lacking is because they have different applications bundled together. As an example, they are using Apache ZooKeeper and Drupal from different open-source vendors. We have two critical security updates that require support. A claim had been opened in May and did not receive any support.

Compared to other vendors that we deal with, I would have to rate this solution a five or less in terms of support.

We are currently looking for other alternatives because of some issues we are facing.

We believe that they do not want to continue with their on-premises version of the product, as they are not responsive to support cases.

We have MuleSoft, but we are only using their ESB, not API management. Apigee is the first solution we are using for API management.

The initial setup is not straightforward. It is very complex. They use different open-source applications in this solution. When installing this solution you have to be knowledgeable in the different applications, what the different applications do, and how they behave with each platform.

The documentation they have available is very good and available online.

Using different applications bundled together in this single product makes the maintenance and installation a challenge. 

The deployment took three months. We had many different environments including development, test, QA, and production environments. For the QA and production environments, we had both an external and an internal gateway. We did this ourselves in conjunction with the Apigee team.

Most of the maintenance is being done by two of our offshore colleagues in Chennai, India. They maintain the platform.

It's a good return on my investment. In the past, we were struggling with the way we would interface with external clients, where we would open a firewall and do many network-level configurations before we were able to open an API. Now everything goes through Apigee and we only open the first ones for Apigee. After that, all other communication goes through Apigee.

We evaluated three different products, including API management from Apigee, API management from CA, and MuleSoft. This evaluation was three years ago, and at that time the Apigee platform was more mature than other platforms.

For on-premises I would not suggest this solution. Generally speaking, the product is a good one, it is matured and the features are okay. If anyone wants to use this solution they should first consider the cloud-based version.

Because the support is lacking, we would have considered a different product. I would rate this solution a seven out of ten. If the support was better, I would have given them a nine.

This solution provides us with a good gateway for API Management and versioning. It gives us easy to map backend version services, and additional security and policies can be adopted.

We are achieving five thousand TPS (Throughput per second) on peak load, and managing thousands of proxies against K8s cluster services.

I have found the most valuable features to be tracing a proxy, and managing proxy versions and revisions via the Edge UI component.

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

We use this product for exposing API's to the digital platform and for B2B.

I think it is the most functional tool on the market. The security is a valuable feature. 

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

I have not encountered instability with the product. 

I do not have experience with tech support. 

API gateway tool and management of API solutions. This tool is extremely helpful for discovery, self-service of API solutions.

• Allowed us to convert from SOAP to RESTful patterns
• Improved security/throughput/management
• Throttling is also useful as well as management console tools to track performance.

• API gateway tool
• API developer tool
• Visualization tools to measure and manage the performance of APIs. 

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.

We use it to build API proxies for securing targeted back-ends with an emphasis on Continuous Integration/Continuous Development (CI/CD).

It has been a potential source of mission-critical customers.

We expect to gain new business opportunities upon providing Apigee services to customers.

• Pragmatic RESTful
• Developer portals
• Continuous Integration/Continuous Development
  
• Tracing tool

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