The open-source version of Kong does not support a dashboard, which would be very helpful. We use an open-source tool called Konga for basic dashboard needs, but it lacks support. It would be better if there was a comprehensive dashboard included in the open-source community version.
The tool needs to improve in areas like documentation and UI. The product needs to have good documentation and a good UI where we can see the other features. It was difficult for our company to understand the document when we needed to do some research and development work, which was some sort of a challenge we faced earlier. The tool should put efforts into the documentation, which can help the developer to develop products that the community is going to use in the future. Additional features like offering good analytics performance and enhancing Kong Gateway Enterprise with GenAI capabilities can be helpful.
Solutions Architect at a financial services firm with 1,001-5,000 employees
Real User
Top 20
2024-06-26T15:10:00Z
Jun 26, 2024
Upgrading Kong Gateway Enterprise should be more sophisticated and innovative. The main issue is with the update process. Our DevOps and admin teams need to update multiple files, which is cumbersome. For instance, in cases where Palantir countries are involved, they have to update many files, which is not ideal. However, for other tasks like configuring the message routing and services and handling all the configurations, the process is acceptable. The software version upgrade process should be improved. Additionally, the DevOps portal should be integrated more natively. There are a few other areas for improvement, such as implementing automatic load balancing. The status of the office team, whether it is up or down, should be checked at the API gateway level to facilitate load balancing.
Engineer at Electricity Generating Authority of Thailand
Real User
Top 20
2024-06-05T06:35:20Z
Jun 5, 2024
The main challenge, in my opinion, is the price. It's difficult to convince our management to approve the budget to purchase it from our vendor. There are no technical problems. It's expensive in Thailand (10 million baht, in Thai currency). One thing I've seen in a competitor's product is the ability to create a simple API within their platform using a low-code/no-code GUI. It connects to databases and allows you to drag and drop to create basic API functions. I think this feature would be a valuable addition to Kong Gateway Enterprise. So, they should create a single API for the platform. Moreover, if Kong Gateway Enterprise could integrate AI, that would be great. It could automatically scale itself, assess request rates for each API, or even detect attacks. That would be great.
The ease of integration offered by the tool is strong. The security is being built in the tool. In terms of the connectivity part of the tool, I haven't had a chance to comment on the challenges since we have not tried it on a large enterprise. With Kong Gateway Enterprise, since users want more readily available connectors that can be used in head offices or back offices, it is an area that needs to be considered for improvement. For example, if I give out a setup tomorrow for the systems in head offices or back offices, like SAP or ERP systems, then you should be able to provide connectors, and it is an area where my company has not been able to test the product yet. The aforementioned features should not only be available in Kong Gateway Enterprise but also across the product stack offered by others. From an improvement perspective, the product should offer more readily available connectors and also allow for more seamless AI integrations. Most of the products nowadays are becoming more AI-native because of the needs of the industry. The introduction of GenAI and the use of the integration part to make the tool more of an industry-based solution can make a difference.
Dev lead at a financial services firm with 1,001-5,000 employees
Real User
Top 10
2024-05-02T13:19:27Z
May 2, 2024
There is room for improvement in the licensing model. It charges differently for each geography. If I have to use Kong in two different geographies for the same organization, it charges me twice. When it comes to Azure, it doesn't charge me twice. Azure has a more economical model. The licensing in the Middle East, where we work. The licensing of Kong and Azure is a lengthy process. It was not readily available. We had to talk to the product owner to make the Kong Gateway available as a solution on the Azure marketplace. The licensing is only as an on-prem or separate product. The difference between billing on the cloud and outside the cloud is if I purchase Kong outside, I have to pay the AMC every year or so. The purpose of cloud implementation is to have a consolidated billing for all resources purchased on the cloud. You don't need to deal with multiple vendors. If you have purchased five applications on the cloud marketplace, you get a single consolidated bill every month. The ease of billing is lost when Kong is not available directly on the Azure marketplace. This is one area where they can improve. There could be a problem with the Middle East geography. They may have Kong available on the Azure marketplace in other geographies, but this is how it is in the Middle East.
Kong Enterprise needs to improve its pricing, which starts at hundreds of thousands of dollars. Pricing should be based on API usage rather than monthly. It should improve its documentation as well.
In comparison to Fortinet, Kong Enterprise fails to offer a huge number of ports in lower models of the solution. From an improvement perspective, the number of ports in lower models of the solution should be made available. The GUI of the product is not very user-friendly, making it in areas where improvements are required. In Fortinet, the GUI allows users to deal directly with the configuration part. The product's price is an area of concern where improvements are required.
I find that expressing information can be a bit challenging, especially for those who are new to installing email configs or using it for the first time. Understanding the configurations and knowing what needs to be done can be a bit difficult initially.
There is a tool called Apigee. Apigee has a portal where you can inspect the APIs and do a live tracing of the API, features that are missing in Kong Enterprise and Azure API Management. I am unsure if something else needs to be considered for improvement. Kong Enterprise fails to provide live tracing of the APIs, which is possible nowadays. With live tracing of the APIs, you can see how the request is going and where it gets stuck, what the actual input was, what the response is, and all that information we can see with the help of live requests, which is impossible in Kong Enterprise. The aforementioned area can be considered for improvement in the solution. With Kong Enterprise, you can examine after the fact, but why it happens can't be examined.
If Kong provides a 30-day license like other API gateways, we can promote the solution to more customers because they are willing to use it. We are unable to showcase the security and functional features during the trial period, which is an issue for us. We are facing issues with the solution's features like reports and traffic analysis.
They need to improve the developer portal. There are currently no isolated data plans for federated teams that I can manage easily, and that's something they should look at.
Kong is meant for north-south communications, so it will be interesting to see what solutions they can come up with in the realms of east-west communications, service-to-service communications, and Zero Trust architecture. I believe that if they can provide for these areas, then they will be able to solve the overall integration and security concerns for microservices architecture in general.
We would like to see an automatic data API - when we have a database table or a store procedure - we want to be able to select it and the data API will be created automatically for GET and CRUD operations in OData format. This feature already exists in other solution and it is a game changer - reducing efforts, risks, and reliability.
Vice President – Technology and Architecture at a venture capital & private equity firm with 51-200 employees
Real User
2020-11-24T16:35:03Z
Nov 24, 2020
Kong has a huge community and lot of open source implementations and satisfied users. The motivation to move to Enterprise edition is still license and cost based. Kong can look at different options like managed and Hosted PaaS, different consumption tiers to make the transition practical and easier.
Head of Digital Delivery at a insurance company with 1,001-5,000 employees
Real User
2020-03-25T07:03:00Z
Mar 25, 2020
It can be our personal, our company's issue, but when we were doing separate projects, we were facing a lot of solutions. For some of our major projects, the API was not using Kong as a group platform. Sometimes they use Microsoft Azure or AWS. That's not a problem, but I think it's wasting some of our budget. We set Kong as an enterprise standard. There should be an easier way to integrate with other solutions, even though it's the same API solution layer. Comparability will be a good improvement.
Digital Architect at a comms service provider with 1,001-5,000 employees
Real User
2019-07-28T07:34:00Z
Jul 28, 2019
Mainly, I would say they need to improve the updates. The updates of the OS for Fortinet seem to require a lot of bandwidth. It would be good if they required fewer resources. Also, they might improve the frequency of the releases. I say this because here in East Africa the Internet is not as reliable or as fast as in the UK — or other places outside Africa. The OS for the Fortinet is great — super, even — but the releases are bulky and cause some problems. Even though I like the way that both the intrusion prevention and antivirus are incorporated in this one solution, I think they should improve how you switch between one feature and the other. It's not very user-friendly for someone who's not experienced with the product. It is also quite different from other firewalls, like Check Point.
Kong delivers a next generation API platform built for modern architectures. With a lightnight-fast, lightweight, and flexible core, Kong delivers sub-millisecond latency across all your services. Kong's is deployment-, vendor-, and pattern-agnostic, allowing you to run your services how you want, where you want, and with who you want - from baremetal to cloud, monolith to microservices, service mesh, and beyond.
The open-source version of Kong does not support a dashboard, which would be very helpful. We use an open-source tool called Konga for basic dashboard needs, but it lacks support. It would be better if there was a comprehensive dashboard included in the open-source community version.
The tool needs to improve in areas like documentation and UI. The product needs to have good documentation and a good UI where we can see the other features. It was difficult for our company to understand the document when we needed to do some research and development work, which was some sort of a challenge we faced earlier. The tool should put efforts into the documentation, which can help the developer to develop products that the community is going to use in the future. Additional features like offering good analytics performance and enhancing Kong Gateway Enterprise with GenAI capabilities can be helpful.
Upgrading Kong Gateway Enterprise should be more sophisticated and innovative. The main issue is with the update process. Our DevOps and admin teams need to update multiple files, which is cumbersome. For instance, in cases where Palantir countries are involved, they have to update many files, which is not ideal. However, for other tasks like configuring the message routing and services and handling all the configurations, the process is acceptable. The software version upgrade process should be improved. Additionally, the DevOps portal should be integrated more natively. There are a few other areas for improvement, such as implementing automatic load balancing. The status of the office team, whether it is up or down, should be checked at the API gateway level to facilitate load balancing.
The main challenge, in my opinion, is the price. It's difficult to convince our management to approve the budget to purchase it from our vendor. There are no technical problems. It's expensive in Thailand (10 million baht, in Thai currency). One thing I've seen in a competitor's product is the ability to create a simple API within their platform using a low-code/no-code GUI. It connects to databases and allows you to drag and drop to create basic API functions. I think this feature would be a valuable addition to Kong Gateway Enterprise. So, they should create a single API for the platform. Moreover, if Kong Gateway Enterprise could integrate AI, that would be great. It could automatically scale itself, assess request rates for each API, or even detect attacks. That would be great.
The ease of integration offered by the tool is strong. The security is being built in the tool. In terms of the connectivity part of the tool, I haven't had a chance to comment on the challenges since we have not tried it on a large enterprise. With Kong Gateway Enterprise, since users want more readily available connectors that can be used in head offices or back offices, it is an area that needs to be considered for improvement. For example, if I give out a setup tomorrow for the systems in head offices or back offices, like SAP or ERP systems, then you should be able to provide connectors, and it is an area where my company has not been able to test the product yet. The aforementioned features should not only be available in Kong Gateway Enterprise but also across the product stack offered by others. From an improvement perspective, the product should offer more readily available connectors and also allow for more seamless AI integrations. Most of the products nowadays are becoming more AI-native because of the needs of the industry. The introduction of GenAI and the use of the integration part to make the tool more of an industry-based solution can make a difference.
There is room for improvement in the licensing model. It charges differently for each geography. If I have to use Kong in two different geographies for the same organization, it charges me twice. When it comes to Azure, it doesn't charge me twice. Azure has a more economical model. The licensing in the Middle East, where we work. The licensing of Kong and Azure is a lengthy process. It was not readily available. We had to talk to the product owner to make the Kong Gateway available as a solution on the Azure marketplace. The licensing is only as an on-prem or separate product. The difference between billing on the cloud and outside the cloud is if I purchase Kong outside, I have to pay the AMC every year or so. The purpose of cloud implementation is to have a consolidated billing for all resources purchased on the cloud. You don't need to deal with multiple vendors. If you have purchased five applications on the cloud marketplace, you get a single consolidated bill every month. The ease of billing is lost when Kong is not available directly on the Azure marketplace. This is one area where they can improve. There could be a problem with the Middle East geography. They may have Kong available on the Azure marketplace in other geographies, but this is how it is in the Middle East.
Kong Enterprise needs to improve its pricing, which starts at hundreds of thousands of dollars. Pricing should be based on API usage rather than monthly. It should improve its documentation as well.
The technical support team's response time needs to be improved. Kong Enterprise should improve its resiliency when it comes to the active DR setup.
In comparison to Fortinet, Kong Enterprise fails to offer a huge number of ports in lower models of the solution. From an improvement perspective, the number of ports in lower models of the solution should be made available. The GUI of the product is not very user-friendly, making it in areas where improvements are required. In Fortinet, the GUI allows users to deal directly with the configuration part. The product's price is an area of concern where improvements are required.
I find that expressing information can be a bit challenging, especially for those who are new to installing email configs or using it for the first time. Understanding the configurations and knowing what needs to be done can be a bit difficult initially.
There is a tool called Apigee. Apigee has a portal where you can inspect the APIs and do a live tracing of the API, features that are missing in Kong Enterprise and Azure API Management. I am unsure if something else needs to be considered for improvement. Kong Enterprise fails to provide live tracing of the APIs, which is possible nowadays. With live tracing of the APIs, you can see how the request is going and where it gets stuck, what the actual input was, what the response is, and all that information we can see with the help of live requests, which is impossible in Kong Enterprise. The aforementioned area can be considered for improvement in the solution. With Kong Enterprise, you can examine after the fact, but why it happens can't be examined.
If Kong provides a 30-day license like other API gateways, we can promote the solution to more customers because they are willing to use it. We are unable to showcase the security and functional features during the trial period, which is an issue for us. We are facing issues with the solution's features like reports and traffic analysis.
They need to improve the developer portal. There are currently no isolated data plans for federated teams that I can manage easily, and that's something they should look at.
Kong is meant for north-south communications, so it will be interesting to see what solutions they can come up with in the realms of east-west communications, service-to-service communications, and Zero Trust architecture. I believe that if they can provide for these areas, then they will be able to solve the overall integration and security concerns for microservices architecture in general.
Kong Enterprise can improve the customization to be able to do the integration properly.
We would like to see an automatic data API - when we have a database table or a store procedure - we want to be able to select it and the data API will be created automatically for GET and CRUD operations in OData format. This feature already exists in other solution and it is a game changer - reducing efforts, risks, and reliability.
The price could be lower.
Kong has a huge community and lot of open source implementations and satisfied users. The motivation to move to Enterprise edition is still license and cost based. Kong can look at different options like managed and Hosted PaaS, different consumption tiers to make the transition practical and easier.
It can be our personal, our company's issue, but when we were doing separate projects, we were facing a lot of solutions. For some of our major projects, the API was not using Kong as a group platform. Sometimes they use Microsoft Azure or AWS. That's not a problem, but I think it's wasting some of our budget. We set Kong as an enterprise standard. There should be an easier way to integrate with other solutions, even though it's the same API solution layer. Comparability will be a good improvement.
Mainly, I would say they need to improve the updates. The updates of the OS for Fortinet seem to require a lot of bandwidth. It would be good if they required fewer resources. Also, they might improve the frequency of the releases. I say this because here in East Africa the Internet is not as reliable or as fast as in the UK — or other places outside Africa. The OS for the Fortinet is great — super, even — but the releases are bulky and cause some problems. Even though I like the way that both the intrusion prevention and antivirus are incorporated in this one solution, I think they should improve how you switch between one feature and the other. It's not very user-friendly for someone who's not experienced with the product. It is also quite different from other firewalls, like Check Point.