Geyfra equivelant of personal intercept

[bab5470]

Does Geyfra have the equivalent of Ambassador Telepresence's personal intercept? Where certain traffic can be forwarded to a destination developer's workstation based on something like an HTTP header passed from the client? If so can someone point me to the documentation as to how that's setup? If not are there any plans to add this sort of functionality?

Thanks!
Brad

[SteinRobert]

Hey @bab5470, thank you very much for your question!
TLDR: This is currently not implemented in Gefyra, we're strongly considering it.

Currently we're allowing one bridge per workload. This makes it hard to split the traffic for multiple users. However, this feature has been requested by quite a few users via mail or on conferences we talked at.
We're currently focusing on Gefyra 1.0.0 (stable) and adding Gefyra to common development environments (Docker Desktop, VS Code).

Personal intercepts will need some rework of the existing Gefyra architecture and implementation. If you want us to move it up the Gefyra roadmap you can reach out to us for sponsoring this feature's development.

What would also help - maybe you can describe your use case. Do you have some kind of shared development cluster? Why is it interesting for you to bridge one workload from multiple clients? Have you ever considered ephemeral dev clusters - this is something we encourage with Getdeck + Beiboot.

[SteinRobert]

Hey @bab5470 any chance you could answer my questions above? It would really help us for the further development of Gefyra.

[bab5470]

@SteinRobert sorry for the delay in replying. We have several development teams sharing two "official" development environments which run on dedicated servers.

The official development environments run on beefy dedicated servers that have way more processing power (CPU, Memory, Network Throughput) than developer laptops.

As our kubernetes environment continues to grow (we have 20 microservices and growing) + a long list of dependencies like mongodb, rabbitmq, elastic search, etc) it becomes increasingly impractical for a developer to setup and run the entire stack on their laptops. (At least without giving them all quantum computers for workstations 😆 )

Ephemeral dev clusters isn't something we've considered although that sounds challenging to setup and maintain as well as resource intensive.

If we gave every dev their own ephemeral cluster (or even just spun them up as needed) that would consume gobs of resources to run mongodb, elastic search, redis, rabbitmq etc). Not to mention they'd have to wait for all these services to be provisioned when they need to use them - which probably isn't going to be fast.

Part of the motivation behind this is to make local development as fast as possible without having to wait for an entire environment or even code deployment before a dev can test their code.

The idea with Telepresence is that you spin up a container on your local system and then can rely on the various common components in the official dev environment to function.

The devs end up running one container locally and all the rest remotely which drastically reduces the resources needed on their local system and rapidly allows them to iterate through code changes.

Not to bad mouth Telepresence - they sound fantastic on paper and they've been trying really hard to get a working solution for us. However we've been working with their sales engineering team for months now, trying to get Telepresence to work and their own sales engineering team can't seem to figure it out and its really expensive. 😞

That's why we started looking at Geyfra - sadly for us personal intercepts are our primary use case. We may have two devs working on the same code/microservice/containers simultaneously (one working on a new feature in one git branch and another performing a bug fix in a separate branch - for example) and we can't have one interfering with the work of another. At the same time we might have a QA person checking something on dev and they want to see a third git branch.

Thus the idea of being able to pass a http header with the requests and then redirect to two separate running instances of the container is appealing to us.

I hope this all makes sense but if you need additional clarification please let me know.

Thanks
Brad

[SteinRobert]

@bab5470 This is super, super helpful. We're currently evaluating how we'll continue with Gefyra after v1 - which will be released in December 2022. I will keep this issue open for now and let you know when we have further updates.
Thank you so much again.

[japareja]

+1 Here, we have exactly the same use case. More than 10 microservices containers plus REDIS, KAFKA, and multiple developers working on same microservice module on different features.

Telepresence cover this case, but licensing is a real problem, so we are looking for real open source alternative. Please consider this feature as priority, you will cover the main enterprise level development workflow.

[SteinRobert]

@japareja thank you very much! 🚀 Every voice, feedback helps us prioritize further development.

[SteinRobert]

Hey guys one thing which makes a big difference in the implementation -
Do you need a personal gefyra run or do you need a personal gefyra bridge?

We noticed that for a lot of the development use cases gefyra run is all the devs want - connect their service to the other services in the cluster. This service can be made available via the --expose flag in the run command. You can then call you service via http://localhost:<your_port>.
However - we are aware, there is a limitation concerning multiple gefyra run on the same cluster. Anyways - this is a lot easier to implement than a multi-peer gefyra bridge.

Usually gefyra bridge is only needed when you have other services talking to your local container or you have some kind of API-gateway logic which is needed for your service to process your request (or maybe some kind of sidecar pattern).

So question - is gefyra run fine for your case (react with 🚀 ) or do you need gefyra bridge (other services should communicate proactively with your local container - react with 👍 )?

[bab5470]

@SteinRobert Sorry for the lag in replying - with holidays and vacations I've been tied up.

I'd say that greyfra run would be a big improvement over how greyfra operates right now.

However to be truly useful the communication needs to be bidirectional as sometimes services need to interact and exchange with one another.

[SteinRobert]

@bab5470 no worries at all! Thank you very much for coming back with your feedback on this! We're currently evaluating different options on how to provide the personal intercept functionality.

Everyone following this thread - please feel free to provide us with your input and use cases. We'd like to build a deeper understanding of everyone's needs before pouring days and weeks of work into this feature.

You can watch the current progress within this issue #306