Apigee being #1 API Gateway as per Gartner reports, what are the advantages or features that Apigee brings in which is not available in other API Gateway such as Akana.
We would like to have this information so that we can recommend our technology team to have Apigee as the preferred API gateway.
It will help in analyzing the API Gateway and understand Apigee features.
Apigee is having both SAAS, Onprem, and Hybrid versions.
Apigee onprem version is having full customization ability of each component.
Apigee Analytics is a big advantage of Apigee.
Horizontal Scaling is easy in Apigee.
Live trace of APIs is the advantage of Apigee.
For logging purpose Post client Flow is there which doesn’t have any impact on performance.
There are more than 35 inbuilt policies available in Apigee. Other than that you have a custom script option using java, javascript, and python.
Apigee Support by Google is there to support. As well Apigee community is there to help.
Developing APIs in Apigee is very easy using UI as well as CICD.
Thanks Priyadarshi for your pointers on this. Definitely agree.
Is there a specific policy which is beneficial to users of Apigee which is not found in any other API Gateway specifically Akana?
for eg.
OAuth security policies, what would be the advantage over the client certificate authentication policy.
Logging policy in apigee, is there a tab to see logs of API calls in Apigee portal, instead of configuring with third party loggeres such as loggly, stackdriver or cloud bucket?
I am looking at specific benefits of apigee in terms of policy usage.
Policies functions are similar in other API Gateways. Yes, as I specified javascript, java and python extension policies are the out of box options in Apigee.
Apigee has Oauth 2.0, JWT, SAML, TLS, Access Control type of major securities.
Policies are there to help to convert SOAP endpoints to REST and vice versa.
Statistic Collector policy is there to add your custom property to analytics.
API versioning and revisions help to maintain inbuilt version control of the APIs.
Encrypted KVM is there to store secure information related to the environment and apis.
API traffic control policies are there like spike arrest, quota, concurrent rate limiting, and caching.
Response cache is there which helps to reduce load on backend and support as like backend when the response is unchanged.
I do not think we have a public comparison matrix of Apigee vs Competition. As you have access to Gartner and Forrester MQs, you already have 70% coverage of similarities, differences, and dimensions to compare those products made by people whose full-time job is to analyse and rank this product category by the feature.
To understand why Apigee is a product category leader and especially to explain this to your colleagues and management it is important to take a step back and look at the digital value chain forest behind the trees of separate Gateway component features.
API Management: Functional Features
Apigee is an API Management Platform. A Gateway is just one or the elements of the platform. As an enterprise, you do not just want to implement a gateway. You want to manage the entire SDLC of your APIs, not just expose aspect of it. For this, the key dimensions would be:
design and publishing APIs;
client application [aka third-party] developer management;
API traffic management;
security;
analytics;
API monetisation.
See this white-paper for comprehensive coverage of the topic:
https://apigee.com/about/cp/api-management-gateway
API Management: Non-functional Features
On top of it, there are non-functional features like
Programming model;
Extensibility;
CI/CD friendliness,
which make a specific product harder or easier to use by an API Developer on a day-to-day basis.
Choose Right Product for Your requirements
OK. To cover what to look at, was an easy bit. The trickier question is how to compare. API Management solutions are commodity products nowadays. Every vendor supposed to be biased towards her product and every product would claim to have same set of features. Besides, every customer is unique in terms of their requirements and thus a great product overall might not fit customer needs perfectly.
My advise would be do not start with just a set of product features. Start with your requirements and match them against what product has to offer. Define non-functional requirements. Both, throughput in 3-5 years and SDLC.
How other companies do it? After you define requirements and identify 2-3 contenders, arrange a hackathon and/or small POC… It’s not a cheap exercise, but that what the big enterprise would do. Talk to companies in your industry. What they use for API Management? Which use cases and how they implement them? Every company is different, but there are many similarities within company’s vertical.
If you have limited budget and cannot afford practical evaluation, use other people’s experience: Case Studies. Every vendor, Apigee including, would have a collection of showcases where customers share their experiences. Of course, those are happy customers. Look for Case Studies when customer migrated from one product to another. That would give you insights on ‘not-so-happy’ parts. Read between lines. OSINT it!
Example: Case Study of a Case Study
You want to see how Apigee and Akana compare programming-model-wise. A quick googling does not give any direct results. A brief look at Akana API Gateway web site and its snapshots tells me Akana is more configuration-heavy comparing to Apigee, which is more coding-heavy on a coding-configuration continuum.
That means, for your API Developer, Akana would be more productive on day 1 and will stay productive… as long as your requirements fit Akana configurations. As soon as you hit any limitation or rigidity, they would get you into a situation when you fight the product. Then you might spend more time on workarounds or would need to drop a requirement.
Apigee programming model is a DSL with XML configuration, but it has a bigger coding element. That means that for your API Development team the learning curve is steeper but the team would be in control and being able to adapt to a wider variety of request changes that would inevitably happen.
Looking at a Case Study at cloud.google.com site, gives me a story of Bazaar Voice,
https://cloud.google.com/customers/bazaarvoice
The study does not specify which product Bazaar Voice (BV) was migrating from. That is expected. But that product has three features that eventually persuaded BV to move:
In 2016, December, BV generated 12 billion calls and their current solution began to feel some pressure. The call volume was expending and thus in 2-3 years, would increase considerably. Apigee horizontal scalability was comfortably covering this future demand.
BV previous product has ability to add custom component, but a) only vendor PS department was able to code it (took months from conception to production); b) vendor would own the code.
Apigee’s Java Callout model allowed BV to build, fix, iterate the code in days while not depending on anyone.
API Management Platform does not expose APIs: too granular and too technical. It exposes Products: collections of APIs that solve specific business need. As BV has good in-house data intelligence unit, they saw how to stratify their customer-base to optimise published products and pricing for different brackets of target audience. Apigee’s flexibility to configure products and monetisation models allowed that to happen. Quickly. Efficiently.
See this white-paper for introduction into OSINT:
https://www.cia.gov/library/center-for-the-study-of-intelligence/kent-csi/vol48no3/pdf/v48i3a05p.pdf