Kitproxy Web Accelerator FAQs (Frequently asked questions)

Yes, it comes by default with the CDN component

Customer need not use any other data provider

• The data stored is not permanently stored, its ephemeral storage as its caching the origin application response.
• Along with that the cached data is on a blob / S3 storage with secured access on separate VPN of the cloud.

This is the eventual goal for the kit-proxy.

TCurrently its in learning stage.

Yes, we could provide on a case to case basis.

With kit-proxy you can check all the request analytics from Grafana dashboard.

From the response header, check for x-kit-source header.

• kitsune asset storage : From the cache.
• kitsune origin proxy : from origin server.

kitsune framework is built on top of serverless/cloud native framework.

Since the application isn’t hosted on any specific server, it never exposes any IP or any port (apart from 80/443) to the external users.

Since the data access is handled server side, and only plain HTML is the output, hence no one can access the business logic and database.

Riverbed Steelhead is majorly used within the WAN network. The performance and accelaration is limited to the the network latency within WAN network. It doesn't provide caching, compression or any customization at application level.

F5 - AAM: Is the competition with respect to Caching and compression. But it only provides caching at LoadBalancer level.

kit-proxy provides the caching at edge locations like CDN. F5 only caches at single location.

kit-proxy additionally provides edge compute to customize request and response

If it comes through UI, it would come to kit-proxy.

It would get held at the WAF itself.

Generally POC shold be sufficient for 2 weeks, but it can vary on a case to case basis and the application architecture

Yes, with kit-proxy customer will get the realtime monitoring dashboard where they can verify the latency and response time.

Yes, kit-proxy can be configured to block/black list/whitelist the traffic based on

• Country,
• IP address or
• Specific client type / browser.

kit-proxy can provide:

• All the customization power of caching (multi tanent, header based etc..)
• Custom security(CSRF),
• Addition of custom functionalites like access control, dynamic ad insertion, A/B testing, image manipulation and more.
• Brotli Compression as standard.

Limelight and BitGravity: Are competition at some some level. Refer competition analysis for more details

Cloud Native proxy architecture without changing a single line of code in their existing applications or to their orginal architecture.

Pre- meet requirements shared is to ensure we gather all the details required from the customer.

Cloud Native proxy architecture without changing a single line of code in their existing applications or to their orginal architecture.

Yes, sendbox testing is highly recommanded befor go live to the production.

Less to commence with, but with time customer usually asks the internal team to learn the functions because they would not want to pay external vendor for every customisation.

Since Akamai CDN is providing all the values of CDN, kit-proxy can provide:

• All the customization power of caching (multi tanent, header based etc..)
• Custom security(CSRF),
• Addition of custom functionalites like access control, dynamic ad insertion, A/B testing, image manipulation and more.
• Brotli Compression as standard.

In case of dynamic request(insert data to db), kit-proxy will provide tunnel directly to the end application, there won't be any accelaration.

But since the request is passing via kit-proxy, it will be trasfered via dedicated private network of Cloud, hence the latency would be decresed(in miliseconds)

kit-proxy is purely on cloud with cloud native components.

Customer does not need to provide any memory or processing requirement, it will scale automatically based on the requirement.

kit-proxy expects the meta-data info, as it gives customer control to define the caching properties at kit-proxy level.

If meta data is not provided kit-proxy would assume a default configuration for that application.

All the request / data will travel via kit-proxy middleware.

CDN will only check against the request path and parameters for the response to be served from Cache or Origin

kit-proxy customers can customize the logic to cache the content based on various parameters (i.e Headers, Browsers, Location, Cookies etc)

With respect to LoadBalancer, kit-proxy can be setup on top of LoadBalancer. Kit-proxy and LoadBalancer's purpose are different.

kit-proxy is used for performance improvement via caching and security via customizations where LoadBalancer's task is to distribute the request + standard security features

The data stored is not permanent storage, its ephemeral storage as its caching the origin application response.

Moreover the cached data is on a blob/S3 storage with secured access on separate VPN of the cloud.

Riverbed Steelhead is majorly used within the WAN network. The performance and accelaration is limited to the the network latency within WAN network. It doesn't provide caching, compression or any customization at application level.

F5 - AAM: Is the competition with respect to Caching and compression. But it only provides caching at LoadBalancer level.

kit-proxy provides the caching at edge locations like CDN. F5 only caches at single location.

kit-proxy additionally provides edge compute to customize request and response