Hoop is a proxy for high-speed connections: databases, VMs, containers.
Therefore, latency is key: add too much overhead and users feel it immediately.
Queries take longer.
SSH sessions feel laggy.
The whole experience gets worse.
But we’re removing gRPC from our product. And here’s why:
Hoop adds a lot of functionality at the wire, while trying to stay under single-digit millisecond overhead.
Therefore, gRPC solved networking really well for us:
• Bidirectional streams enabled users to access resources in private networks without firewall rule changes (reverse tunnel)
• Protobuf encoding helped keep latency low across network hops
• HTTP/2 gave us a strong transport foundation for long-lived, high-performance connections
But Hoop interacts with highly sensitive customer data. Therefore, we changed to a self-hosted model
But when customers install Hoop, they need to set up gRPC. And this is where the problem starts.
Most companies are not really using gRPC as a standard ingress pattern yet.
Therefore, they often do not have existing processes for HTTP/2 ingress traffic, gRPC load balancing, observability, debugging, and ownership.
But we decided to automate it. Therefore, we made the setup as close to one-click as possible, including every bit of infrastructure code customers needed to deploy the new standard.
But it only kind of works. Because “one-click” is not really one click when different teams own different parts of the stack.
While the data platform team wants to POC Hoop, they may need:
• The Kubernetes team to deploy the container
• The database team to set up a DB instance
• The networking team to set up ingress
• The IAM team to set up a new Okta app
But that would still be fine if the ingress team had already deployed gRPC apps before. In many cases, they had not.
Therefore, they had to figure out a new process. Sometimes this added weeks. And we cannot add weeks to our POC lead time. This is a number we work hard to drive down.
The protocol was fast.
The rollout path was slow.
Therefore, we had to make a tough decision:
Removing gRPC is the single biggest item that can reduce the time it takes to set up Hoop.
But it’s not free: the raw connection layer will become slower.
We’re working with WebSockets to push performance as close as possible to what we had with gRPC.
It will not be exactly the same.
But the tradeoff is worth it if customers can deploy Hoop faster, with less coordination, fewer blockers, and fewer new infrastructure patterns to support.
The biggest lesson for me:
Infrastructure choices are not just technical choices.
They are adoption choices.
The best protocol is not always the one with the lowest latency.
Sometimes it’s the one your customers can actually deploy this week.
I’ll share in the next few days how we are replacing gRPC with WebSockets while keeping performance close to what we had before.