Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap #1308

Closed
h7kanna opened this issue Dec 5, 2018 · 5 comments
Closed

Roadmap #1308

h7kanna opened this issue Dec 5, 2018 · 5 comments

Comments

@h7kanna
Copy link
Contributor

h7kanna commented Dec 5, 2018

Hello team,

Can the team please publish a roadmap for cadence project?
I understand that preferences would be aligned to Uber's goals.
But a public roadmap may help in adoption of the project.

In particular, I personally have below queries.

  1. Are there any plans to move to GRPC for communication similar to Use Protobuf and gRPC for internal communications jaegertracing/jaeger#773.
    Currently Cadence uses TChannel which inhibits developing client side libraries in other languages.

  2. Is there a plan to support alternative interface to Frontend (HTTP/Swagger spec)?

  3. Any plans to make Cadence more cloud-native(Kubernetes friendly).
    I am working on deploying Cadence to Kubernetes and develop 'cadence-operator' to orchestrate the deployment.

  4. Ringpop is not under active development. What does it mean for Cadence?
    https://github.com/uber/ringpop-go
    Will the team accept alternative the membership logic implementations, For example using https://github.com/hashicorp/memberlist or https://github.com/hashicorp/serf.

  5. What is the plan to make SQL datastore implementation production ready?

Thanks.
Harsha

@mfateev
Copy link
Contributor

mfateev commented Dec 5, 2018

  1. Yes, we do plan to switch to GRPC in 2019.
  2. We didn't plan it as internally at Uber there is no need. But we would gladly accept external contributions in this area. I believe that after switching to GRPC it would become simpler as the proto generator is pretty pluggable.
  3. Could you specify what exactly is needed from the Cadence to become Kubernetes friendly?
  4. We plan to get rid of the Ringpop. As Cadence already uses a strongly constistent database it is natural to use it for discovery and health checks.
  5. We are actively working on it. I believe it will be production ready in Q1.

@h7kanna
Copy link
Contributor Author

h7kanna commented Dec 5, 2018

Thanks @mfateev
I will post more Kubernetes specific questions as I work on the operator.

@sagikazarmark
Copy link
Contributor

sagikazarmark commented Feb 15, 2019

I guess the main question regarding Kubernetes is the optimal way of joining new instances to an existing cluster when scaling up, as well as an optimal production setup in light of the load.

I'm not familiar with ringpop, but I'm guessing some sort of orchestrator could manage the list of existing members and pass that list as a JSON file to starting instances.

Also, here is an example with k8s headless services: uber/ringpop-go#175 (comment)

Wonder if this would work with Cadence currently.

@StevenACoffman
Copy link

I would also like to see a Cadence activity that runs a Kubernetes job to completion. For instance, in Airflow, we use AirFlow Operators to generate Kubernetes jobs, so that we can run heterogeneous finite, run-to-completion tasks in various languages. The orchestration/pipeline/workflow is the piece we do not have a great solution for.

@mfateev
Copy link
Contributor

mfateev commented Oct 29, 2019

I think that we need to start to think about libraries of Cadence activities for specific sets of use cases. For example K8s integration, gRPC activity proxies, HTTP actiivty proxies, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants