Live data from Hacker News

Ask HN: How do you handle long-running workflows at your company?

news.ycombinator.com

41–50 of 84 posts

Re: Ask HN: How do you handle long-running workflows at your company?

#41
post #5

Our system is based on the Camunda process engine (in a Java EE environment). There's a central process server (or cluster) running the process engine, with events to start process instances. Workflows are defined using bpmn and then executed by the engine. Errors are reported to the process engine as "Incident", which then show up in the management ui/apis. These can be retried any number of times. We also have an o…

Interesting, I'm looking into Camunda right now for our processes. How would you describe the experience in terms of adoption and results ?

Process modeling requires some reading up front, I think. Integration into our application was relatively easy - activities implemented as Java classes with a reasonably good API.

As for results, we are quite happy with camunda. No issues with performance, incident handling, etc. We have about 100k new process instances/day, with 5-10 steps per process (3 different processes), some of which run over multiple days.

Re: Ask HN: How do you handle long-running workflows at your company?

#42
The Argo project is a workflow engine built on top of kubernetes. Workflows are written as yaml templates and support DAGs as well as loops and conditionals.

https://github.com/argoproj/argo

We use this at my company to stitch together various scientific software packages each of which can take minutes to 10s of hours to run. Argo supports retrying, resubmitting, suspending, and resuming workflows. It really is a neat project, especially if you are already using kubernetes!

Re: Ask HN: How do you handle long-running workflows at your company?

#43
post #5

Our system is based on the Camunda process engine (in a Java EE environment). There's a central process server (or cluster) running the process engine, with events to start process instances. Workflows are defined using bpmn and then executed by the engine. Errors are reported to the process engine as "Incident", which then show up in the management ui/apis. These can be retried any number of times. We also have an o…

Interesting, I'm looking into Camunda right now for our processes. How would you describe the experience in terms of adoption and results ?

Not OP, but we built a product around it and though Camunda is reliable and fast enough for our use, the developer experience is pretty gross.

The BPMN gets saved out as an XML document, but the editor doesn't do a good job of making the format consistent. This makes changes to the BPMN basically impossible to code review without downloading the old and new copies and visually inspecting, which is a chore for large workflows. Especially when variable inputs and outputs require clicking into each node.

Small code snippets in either JS or a Java plugin (jar) can be embedded and used to massage variables and track state. These are also difficult to code review and test as you essentially need to write a harness that mimics Camunda to run them.

All of our new products are using simpler workflows via FaaS and queues (RabbitMQ). If we ever needed large workflows again I'd lean towards something like Airflow.

Re: Ask HN: How do you handle long-running workflows at your company?

#44
We developed and use Argo (https://github.com/argoproj/argo), a Kubernetes-native workflow engine. Argo is currently used by companies like Cyrus Biotechnology, Gladly, Google, Intuit, and NVIDIA. Currently collecting use cases and requirements on a Kubernetes-native eventing framework for Argo (https://github.com/argoproj/argo-events/issues/1) to make it easier to kick off workflows.

Re: Ask HN: How do you handle long-running workflows at your company?

#46
post #32

Check out Pipefy.com - It is like Trello + Customizable workflow: https://d2qfyj0q2n9d96.cloudfront.net/uploads/2017/08/email-... https://downloads.intercomcdn.com/i/o/55498996/caa3b5f8a6334... https://downloads.intercomcdn.com/i/o/58246710/bf1485442ffb1...

Have you tried integrating home-grown services into their workflows? Curious as otherwise it looks pretty good.

Re: Ask HN: How do you handle long-running workflows at your company?

#47
I'm going into get-off-my-lawn mode here if you don't mind. I don't see why this requires a new-fangled technology or buzzword. Just have a status code(s) or indicator(s) on a given request. The client side or requesting service(s) can periodically check on the status using polling and/or user status update requests. For example, poll automatically every 2 minutes (to avoid flooding the network), but give user the option of clicking a button to check current status.

Give the requester an option of a time-limit, if applicable. If the process takes too long, the status changes to "timed-out". The client/requester can then issue a "re-submit" request, if applicable.

The technique is pretty much the same whether using ESB, microservices, Stored Procedures, or carrier pigeons.

Re: Ask HN: How do you handle long-running workflows at your company?

#48
In one of my previous companies, they used Airflow(by airbnb) to schedule and manage workflows. Previously they were using nothing but CRON. It turned out to be not so efficient to retry failed workflows and cancel the execution of following dependent jobs. Airflow turned out to be a great fit for our case. I highly recommend checking it out.

Re: Ask HN: How do you handle long-running workflows at your company?

#49
At LinkedIn we heavily use Azkaban for this. (Open source: https://azkaban.github.io/) Azkaban API can be used to launch offline computation jobs as necessary - Azkaban ensures monitoring, SLA alerting, failed restarts and other dependency management etc.

Re: Ask HN: How do you handle long-running workflows at your company?

#50

We developed and use Argo ( https://github.com/argoproj/argo ), a Kubernetes-native workflow engine. Argo is currently used by companies like Cyrus Biotechnology, Gladly, Google, Intuit, and NVIDIA. Currently collecting use cases and requirements on a Kubernetes-native eventing framework for Argo ( https://github.com/argoproj/argo-events/issues/1 ) to make it easier to kick off workflows.

Does Argo support recovery? In the sense that if a workflow step or the workflow engine crashes halfway, the last (idempotent) action is retried?
Post reply on HN