You're right that there are a number of proxy solutions out there, but most are focused on exposing an API for external consumption (i.e. API producers). We think that by focusing on outbound API calls we can go deep on features that make less sense in those products. The same is true for the analytics solutions (i.e. Newrelic). For example it wouldn't make sense for them to add automatic retry or request caching, but its still a common pain point with integrations and makes a lot of sense for us to build. Finally, some of the tools (i.e. Runscope) are meant for development debugging and don't solve the production pain point.

What you described in the first sentence is commonly referred to as an API gateway - protecting ingress traffic into a publicly accessible service/app (e.g. Kong, AWS API gateway, Ambassador, etc). Lately there's been a lot more generalized solutions in this category for inter-process communication via service meshes like Istio, Gloo, AWS AppMesh, and others - all of which seem to offer a solution that works for both internal traffic routing as well as external (when whitelisted).

Can you offer a description of your product that differentiates it from service mesh solutions? Did you build your own proxy software, or are you built on top of Envoy like many of the other available solutions?

We are not built on top of Envoy and have built our own proxy.

Many of the service mesh solutions require you to deploy and manage them as an on-premise installation. Our primary offering is a hosted solution, but also offer a managed service for on-premise installations.

As you've correctly pointed out the service mesh solutions can allow routing of external traffic, but by focusing on the external calls there are features that make sense for us to build that wouldn't make sense in something like Istio/Gloo/AppMesh. For example, we can build an enhanced experience around third-party APIs to better understand the calls, errors, quotas, etc that are specific to that provider.

That last paragraph is an interesting addition I handn’t considered actually, so great answer! While I’d be hesitant to use a 3rd party, hosted solution for this use case, I can also see how that affords you the ability to optimize fullfilment of requests per destination across all your users. Is it safe to assume that long term you’ll offer this to larger customers via private installation to alleviate security and latency concerns while still benefiting from the destination knowledge of the central hub to configure routing rules?

Congratulations on the launch!

And thanks for your explanations on how your proxy is similar to and different from API gateway or service mesh solutions.

Having worked on both production monitoring and an API gateway for a Fortune 100 company, I would consider monitoring and proxy to each be valuable in its own right and can envision scenarios where I’d want a standalone product offering for one but not the other.

Why did you build your own proxy instead of using envoy? What short comings did envoy have?

We wanted to architect a system that made it easy to deploy proxy nodes to multiple regions and clouds. We also wanted it to be easy to add functionality specific to our feature set. While we might have been able to achieve our goals by modifying an existing proxy, it made more sense to us to build our own. I have built proxies in previous companies and this was something I was very comfortable doing.

Can you expand on what specific part of envoy prohibited that?

Additionally, as other commenters mentioned, almost every company has rallied around Envoy and is spending considerable time/money making it better. If your solution isn't as performant as envoy, it seems like a poor architecture choice to roll your own, especially given the time/money constraints startups have.