Apigee Reviews

I mainly use Apigee to allow partner applications to consume services outside their organizations, for security, and for creating API proxies.

Apigee's best features are flexibility and breadth of capabilities.

I've been using Apigee for three to four years.

Apigee is stable.

Apigee's scalability is one of its main advantages.

Apigee's technical support is really good, and they have a community forum where we can ask questions and get help.

We previously used WSO2.

The initial setup for the on-prem solution is a little complex, but the hybrid setup is very easy because detailed steps are provided. The hybrid version takes one or two days to install, but the on-prem version takes a minimum of a week.

For on-premises, a consultant is required to install.

Apigee is a good product, and I would recommend it to others. I would rate Apigee eight out of ten.

Our organization currently has twenty Apigee end-users. We use the solution for API management of financial and e-commerce domains.

Apigee is relatively easy to use for developers.

I have been using Apigee for six years.

Apigee is a stable solution.

The SaaS version of Apigee is quite scalable. The hybrid version is also scalable depending on your requirements.

I am satisfied with the support offered by Apigee.

The initial setup is not straightforward, particularly for hybrid solutions. It is easier to manage the managed services or SaaS-based versions.

The implementation takes time. The production setup includes TLS among other things, and the management and operationalizing take time as well.

We implemented the solution in-house.

Apigee's licensing costs more than other solutions. Some add-on packages are sold separately. For example, monitoring is not included in the standard package of Apigee Edge.

Anyone considering Apigee as a solution should start small and increase usage with experience. Start with a centralized small team and expand based upon the maturity model that Apigee has and recommends. I would rate this solution an eight out of ten.

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.

I've been using Apigee for a year.

Apigee is stable.

Apigee is scalable.

The initial setup was easy - there was an onboarding document with steps that we followed.

I would rate Apigee eight out of ten.

The solution is used for exposing the APIs mainly.

The organization has benefited from the development of fast, new APIs and new integration points.

The usability is one of the best aspects of the product. It's broadly used in different functional areas. There is no specific one. It's used broadly almost in all the contexts that we have.

It's easy to set up.

Technical support is helpful and responsive.

The stability is great.

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. 

I've been using the solution for two and a half years. 

The solution is stable and reliable. There are no bugs or glitches. It doesn't crash or freeze.

We have 20 to 30 people using the solution. 

We've used technical support in the past and they were pretty helpful and responsive. 

We previously used Mashery. We switched as Apigee was working better.

It's easy to set up the solution. It's a SaaS. The deployment can be handled by just one person. It's very simple. 

We did not use an integrator, reseller, or consultant for the deployment.

I'm not sure if we've seen an ROI.

The licensing cost is quite in line with the other solutions. It depends on which perspective you see it. It could be affordable or expensive. It depends on the company. For the big companies maybe it's more affordable, for the smallest ones probably not.

There are packages that you can buy or add-ons that you can add, depending on the usage, depending on what you have to do with it.

We did look at other options, however, this solution was more fitting for the purpose that we had.

We're a customer and an end-user.

I'd advise potential new users to understand if there is a fit as a product like this is pretty much covering the same functionalities as others on the market. There are not so many huge differences. It depends on what you have to do and what your capabilities are and what your vision is. 

If you need more freedom, you can use other things like Kong or other products. Usually, all those products, at least the big players on the market, have the same functionalities. At that point, it's just a matter of questioning if the product is fitting the needs and the purpose that the company has or not. 

New users need to question what they want to achieve and how they want to achieve it, how they're structured if they're working on the cloud or if they're working on-premise. They have to make some questions about the needs, the wishes, and the setup that they want to have.

I'd rate the solution an eight out of ten.

Essentially, we have our own product where we have hosted the APIs and Apigee for consumers to consume. We have an airline domain and our own product.

We provide services to our clients, who are end users.

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.

I have been working with Apigee for a few years.

Apigee is quite stable.

The initial setup is complicated. There is a lot involved, and many teams are involved.

When attempting to apply a new host, they are setting up the DNS network, which takes some time.

We already have Apigee in our system, but we're trying to evaluate APM based on the differences between Apigee and APM.

Right now, I don't have any experience with Apigee. The only task I've been assigned is to evaluate the APIM. So far, I've only explored APIM. And all I'm doing is defining the features and differences between Apigee and APM.

I'm still evaluating, but in terms of overall performance and stability, it's quite good. As a result, we have not failed any of the issues in that regard.

For the technical capabilities, I would rate Apigee a seven out of ten.

We have a legacy and non-legacy databases that are both on-premises and off-premises.

Apigee is used to connect to any Google-based applications that are available. In addition, we are experimenting and testing in other environments.

I'm a CIO in consulting.

Apigee has proven to be one of the best of the breed. Others are attempting to innovate and are succeeding. So we don't know how innovations will be distributed, Azure, Amazon. Amazon, without a doubt, is lagging, but I've recently heard in the reinventing that they're working on a lot of API-related innovations. So you can't say that they'll be lagging behind as they are catching up.

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.

I have been dealing with Apigee for quite a long time before it was part of Google. It's been approximately three years.

The stability of Apigee is one of the best of the breed.

The scalability of Apigee is good.

Apigee will be implemented in over 100 hospitals.

We have been working closely with technical support, and everything is fine.

We are also collaborating with Amazon teams and some of the standardization committees to help standardize APIs.

The integration of Apigee was straightforward.

It is not an installation, it's an integration. Apigee is integrated rather than installed.

The number of people needed to maintain this solution is determined by the project's, and the complexity of the situation.

Apigee is subject to licensing fees.

Typically, the customer is internal, so it is accounted for in the integrated budgets.

I have other affiliations. Like, I am associated with Cloud Security Alliance, which is a nonprofit organization. And I am also part of ISO SC 38. SC38 has a PWI, a preliminary work initiative on API management. And that goes as the advisory at a global level for a standardization. This topic is not only of my interest, but it is my passion.

I would recommend this solution based on the use case they have.

I would rate Apigee a nine out of ten.

I work for a medium to big size IT consultancy firm in Mexico, and I am in the innovation and interoperability division. Our main work here is to develop projects on interoperability platforms and KPI management, et cetera, and transition from a legacy system to micro-services. In the last year, I have worked on a project on migrating a very big telecom firm from several API gateways and API exposures to Apigee. They're centralizing all their API gateways into Apigee.

We are hoping to lay out the plan for migrating the first sprint of about 200 APIs starting in January. Originally, the plan was to start in December, but the project is so big that it was suffering from delays.

We are going to start doing the actual proxies and migration in January next year. The project consists of about 10-month long sprints. We are going to use all of next year on this first phase. During the course of the next year, we are going to lay out the plan for the next phases. At this point, the total number of APIs to be migrated to Apigee is not clear, but we're thinking that it's about 300, 400 APIs that are going to be migrated.

The solution is deployed on-premise. They're thinking that in the second phase, they're going to go hybrid to have some of the features in the public cloud and some in the proprietary. 

We are integrators.

I think the most valuable features are the security features. Of course, the user access control is the same as the security. The other very important issue is the sandboxing capability of Apigee.

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.

I have been using Apigee for one year.

Right now, in the development area of Apigee, we have about 20 developers, architects, et cetera. We are in the process of training because our expected growth drives us to have about 100 developers by the end of next year. I think that by the end of Q1, next year, we're going to double our capacity. By mid-year, we have to have 20 more, and so on, until the end of the year. We are planning to have about 100 trained developers, or configuration experts, in Apigee.

All the infrastructure, the enablement, is being done by another company. They are in charge of all the dimensions and actually creating all the infrastructure to host the platform. I have never installed Apigee as a proprietary cloud. I have been working either on the pure cloud environment or hybrid environment. I didn't phase the deployment of the tool, just the configuration.

In Latin America, Apigee is expensive. It's not for small businesses; it's more for big businesses. That's why I was trying to compare, for example, WSO2 against other API management tools. We are trying to create an inside practice in our company to also recommend WSO2 for a mid-size or small-size company where maybe the Apigee pricing for them is too heavy.

Apigee prices are targeting medium to large companies in Mexico. In Latin America, it's basically the same.

I would rate this solution 9 out of 10. 

I think the correct roadmap should be first an approach to Google to create a partnership. Then create a team of developers and an architect, and then start adding more resources as the demand grows.

One of our use cases for Apigee was when we were exposing a legacy application that we were using in the past.

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.

It has been two years that I am using Apigee.

It is stable.

It is scalable.

We have around four users.

There is a team of less than five people for deployment and maintenance.

As of now, we are going through a consolidation process within the company. Oliver Weyman is part of a larger group of companies. We are among the first ones to use it, but the plans for it are still not outlined for the next year, at least. This is something that we will finish figuring out within the next few quarters.

Support is good.

At the beginning the initial setup was very straightforward, but the fine tuning during the setup is something that needs some improvement. The initial setup was pretty straightforward because we were trying not to do very complicated things. The initial setup was easy. But then as we started to grow, we realized that there was some room for improvement, but overall the initial setup was easy and we liked that.

Since it initially started as a POC and then we started moving forward from there, it was not complicated. But had we started with a real life application or with more complex applications or requirements, it probably would have been more difficult for us. But the way that we decided to start and also because of the complexity level, it allowed us to go very smoothly with the first setup and deployment.

The implementation was all internal.

Normally the company tends to do agreements with the vendors, where we are trying to get everything in one single license so as not to add complexity to the licensing. That's what I recommend.

The company started evaluating solutions and we found that we have three other options. One of them was Mashery, the other one I don't remember the name, and the last one was SAP. The company decided to go for Apigee and now there are no plans to go to something else because the process that we take to evaluate and assess the solution is a very thorough process. We try to spend as much time as possible evaluating the pros and cons of the solutions and what issues might come up.

My advice to anyone considering Apigee is to start small and then grow from there. Try not to start migrating big, meaning to consolidate many applications into one single one. I would say to start small and try to run some POCs to make sure that they understand the fine tuning. Because the initial setup was easy but the one thing that needs time is the fine tuning of the setup. That, as I said before, is something that is really important for security. The security is something that I would recommend people look at.

On a scale of one to ten, I would give Apigee a nine out of 10.