Hey Amit,
I've deployed both Python apps and Thrift apps with Linkerd in the mix, but not specifically a Python Thrift app :)
It should be straightforward to get this setup. The one issue with native thrift is that it lacks request context (as compared to say,
TTwitter). So in a typical thrift setup you would have one linkerd config with multiple routers running on different ports, one router for each service to which you're sending traffic. This is a bit more cumbersome than HTTP, where you could have one router routing all traffic based on an identifying feature of the HTTP request, but it would still allow you to take advantage of all of
linkerd's major features. Here are the ones that I think would be most useful from a thrift perspective:
- Dynamic request routing: you can rebalance traffic to your backend thrift services by updating linkerd's routing rules, instead of needing to redeploy their callers.
- Service discovery and load balancing: you can configure linkerd to talk to your service discovery backend, and linkerd will apply latency-aware load balancing over all instances.
- Universal client metrics: linkerd will export fine-grained stats (latency, requests, connections, success rate, etc.) for all of your services, which gives you great visibility into the health of your system.
And the really nice part about relying on linkerd to provide these features is that you don't have to pour a lot of effort into writing python libraries to properly implement them.
Hope that helps,
Kevin