Hacker News Reader

Comment by hintymad | Hacker News Reader

Does being fast beyond certain threshold really matter for a workflow engine, though, especially given that many workflows have long-running tasks? What I find matters is multi-tenancy. That is, can a workflow system support as many jobs as a user desires, yet each job gets scheduled and executed as if it is the only one on the workflow engine. For instance, Amazon EC2 and EBS probably have millions of jobs and job queues running at any moment, yet each job has pretty predictable and stable startup delay and execution time. In contrast, each of Nomad and k8s has a global queue that sometimes gets stuck because of bad actors or too many pending jobs (I understand that an orchestrator is far more than just a workflow engine. I'm just contrasting the user experience).

View on HN

So I agree that for most jobs taking already more than 300ms, a 50ms per job will not be perceivable anymore. What matters is the DX and even though I'm very proud of our performance, a lot of our work is focused on providing a consistently great developer experience in all aspects (vscode extension, instant deployment, etc, etc).

However, there is one big benefit to being performant which is that you can use the same stack for performance sensitive jobs such as event-streaming use cases. That remove the duplication of infrastructure. The other benefit is that it improve the developer experience overall with fast previews.

Yes. Just think of how annoying it is when you have to wait 5 seconds instead of 0.5s for a 2FA message, then multiply that by everything that you ever do with your workflow engine. That's not even to speak of cases where running the workflow (e.g. acquiring data) faster is a competitive advantage, although this thing is still probably too slow for truly HFT-level tasks.

Yes it's too slow for HFT, but anything would be too slow for HFT unless it's custom built. You likely want a streaming engine or even hand-optimize all your event handlers to shave-off any nanoseconds.

Just because I'm interested in this topic. I've been trying to shave nanoseconds on ringbuffers and barriers in C.

LMAX Disruptor can send a message between threads in 53 nanoseconds on average.

So you can essentially fork control flow in 53 nanoseconds and do 2 things in parallel.

Eyeballing my barrier I can synchronize in 42 nanoseconds and up.

As someone who works with HFT firms, they typically do everything in ASICs or FPGAs anyway, so it’s not a good example.

A workflow engine is indistinguishable from a regular interpreter or runtime, except for the fact it's suspendable (hence can run tasks long).

Ideally a workflow engine being fast means it can be just the platform you write everything in. The artificial separation between "normal" code and "workflow engines" is completely unnecessary. Our platforms are extremely fragmented, pointlessly so. Remote vs local, statically vs dynamically typed, async vs sync, short running vs long running...

If an engine is written without these arbitrary limitations, it can be more.

Speed is the number one reason I hate Airflow. It does not meet that "certain threshold".

Reply on news.ycombinator.com