Few scenarios 1. For viewing API analytics, I think it is best in the market 2. For earning money via API monetization 3. Securing API 4. Onboarding legacy APIs to provide modern REST endpoints
K8s should be avoided - If your application works well without being converted into microservices-based architecture & fits correctly in a VM, needs less scaling, have a fixed traffic pattern then it is better to keep away from Kubernetes. Otherwise, the operational challenges & technical expertise will add a lot to the OPEX. Also, if you're the one who thinks that containers consume fewer resources as compared to VMs then this is not true. As soon as you convert your application to a microservice-based architecture, a lot of components will add up, shooting your resource consumption even higher than VMs so, please beware. Kubernetes is a good choice - When the application needs quick scaling, is already in microservice-based architecture, has no fixed traffic pattern, most of the employees already have desired skills.
Prohibited from using JSON.stringify on Apigee objects (tokens)
Debugging is difficult
Unable to rename or delete policies without bumping revision
Why would anyone give a js policy one name, display name something else, and script a different name?
'Trace' limited to only 20 transactions
UI allows users to add target servers, but users must utilize the api to turn on SSL.
I'm sure there's more, they just aren't coming to mind right now.
Apigee forgets (expires?) your password at random intervals without notice. Every few weeks, or days, sometimes even three times in one day, I'll attempt to login to Apigee and my password will be 'wrong'. I've reset my password and Apigee still claims it's wrong. I've had to reset my password three times before it finally let me log back in.
Local development, Kubernetes does tend to be a bit complicated and unnecessary in environments where all development is done locally.
The need for add-ons, Helm is almost required when running Kubernetes. This brings a whole new tool to manage and learn before a developer can really start to use Kubernetes effectively.
Finicy configmap schemes. Kubernetes configmaps often have environment breaking hangups. The fail safes surrounding configmaps are sadly lacking.
I am not the one deciding whether to use apigee or not really. But personally, I would recommend the use of it as developing APIs on it is easy. And as a mediator between backend servers, we could easily modify request and responses in it without touching any backend code while having a centralize gateway to access our backend APIs too.
It is an eminently usable platform. However, its popularity is overshadowed by its complexity. To properly leverage the capabilities and possibilities of Kubernetes as a platform, you need to have excellent understanding of your use case, even better understanding of whether you even need Kubernetes, and if yes - be ready to invest in good engineering support for the platform itself
Quite hard to get support, at least on the coding side, when we encounter blockers. But general concerns, they would schedule a call to you for them to get a whole picture of your concern. Albeit in my experience, bad really as they haven't replied about the progress, but otherwise seems to have been fixed.
Apigee is the best in the market in terms of API Analytics Apigee is having wonderful Documentation with short videos Security is a major concern and Apigee provides an easily configurable policy to secure API Quota and rate-limit is again very easy to configure on every API basis It provides various policies to transform the response from one form to another form e.g. JSON to XML or XML to JSON
Most of the required features for any orchestration tool or framework, which is provided by Kubernetes. After understanding all modules and features of the K8S, it is the best fit for us as compared with others out there.
As a public entity it is hard to say how much ROI we can have. We have yet to create a billing and ROI plan. We are thinking of other ways to create ROI, possibly through data/service barter.