Windmill - công cụ workflow engine mã nguồn mở có thể self-host nhanh chóng

• Windmill đã chứng minh qua benchmark rằng đây là workflow engine mã nguồn mở có thể tự lưu trữ nhanh nhất so với các workflow engine khác như Airflow, Prefect, Temporal
• Windmill hỗ trợ nhiều ngôn ngữ lập trình và cung cấp môi trường phát triển tích hợp giúp xây dựng, kiểm thử workflow chỉ trong vài phút mà không cần SDK phức tạp hay quy trình triển khai rườm rà
• Airflow/Prefect chỉ hỗ trợ một runtime duy nhất (Python), trong khi Windmill hỗ trợ Python, Typescript, Go, Bash và hỗ trợ truy vấn SQL trực tiếp với BigQuery, Snowflake, Mysql, Postgresql
• Khi so với Temporal, Temporal chuyên về quản lý hàng đợi tác vụ, còn Windmill cũng hoạt động như một execution engine bền vững với khả năng chờ sự kiện (reactivity)

Sự khác biệt giữa workflow engine và hàng đợi tác vụ

• Hàng đợi tác vụ là cốt lõi của workflow engine, và nhiều nhà phát triển tự xây dựng logic riêng để sử dụng hàng đợi tác vụ mà không cần dùng workflow engine
• Đã có nhiều triển khai hàng đợi khác nhau như SQS, Kafka, Redis with RMSQ, Orban
• Nhiều nhà phát triển xây dựng logic của mình xoay quanh hàng đợi tác vụ và cảm thấy đạt được mức độ hài lòng tương tự workflow engine (tức là tự tạo workflow engine của riêng mình)

Workflow engine “all-inclusive” là gì

• Workflow engine điều phối workflow trong hệ thống phân tán để hoàn thành công việc, đồng thời tôn trọng các ràng buộc phụ thuộc giữa các tác vụ
• 5 lợi ích chính của workflow engine:
  • Phân bổ tài nguyên: có thể tận dụng tối đa cụm máy, phân bổ mọi tác vụ đến các worker khác nhau với tài nguyên khác nhau (CPU, bộ nhớ, GPU), và đảm bảo toàn bộ tài nguyên của worker có thể được dùng cho tác vụ
  • Xử lý song song: nếu do các ràng buộc của workflow mà một số bước có thể chạy song song (branch, for-loop), workflow engine có thể dispatch các bước đó không chỉ tới các thread mà còn tới nhiều worker tách biệt về mặt vật lý
  • Khả năng quan sát: mọi tác vụ đều có ID riêng và có thể được quan sát độc lập, bao gồm kiểm tra input, log, output, trạng thái
  • Tính bền vững: nếu máy dừng vì lý do bất ngờ hoặc phát sinh tác dụng phụ, workflow phải được khởi động lại
    • Workflow cần có khả năng khởi động lại nhanh nhất có thể khi xảy ra sự kiện bất ngờ; một cách để đạt được điều này là tính idempotent, tức một tác vụ chạy nhiều lần vẫn cho cùng hiệu quả như chạy một lần
    • Khi không chắc chắn, có thể phát lại toàn bộ luồng mà không tạo thêm kết quả. Điều này thường được triển khai bằng cách dùng file log và SDK để bỏ qua tác dụng phụ nếu ID duy nhất gắn với tác vụ là một phần của log
    • Một cách khác là tạo snapshot giao dịch của trạng thái luồng để lưu trạng thái sau mỗi tác vụ. Khi khởi động lại, chỉ cần nạp lại trạng thái cuối cùng và tiếp tục từ đó
    • Windmill dùng cách thứ hai và giả định rằng người dùng có thể tự triển khai idempotency ở user space khi cần
  • Tính phản ứng: tạm dừng luồng cho đến khi được tiếp tục lại dựa trên các sự kiện như webhook hoặc phê duyệt

Bí quyết giúp Windmill nhanh

• Windmill tận dụng Postgresql và Rust để tối đa hóa hiệu quả thông qua thiết kế đơn giản và các tối ưu hóa

Thiết kế hệ thống và queue

• Windmill cung cấp một binary duy nhất được biên dịch bằng Rust; worker và server đều kết nối tới Postgresql nhưng không kết nối trực tiếp với nhau
• Queue được triển khai ngay trong Postgresql, và tác vụ có thể được kích hoạt từ bên ngoài qua API

Trạng thái

• Workflow engine biểu diễn tác vụ như một finite state machine (FSM), còn Windmill xử lý toàn bộ luồng như một FSM

Truyền dữ liệu

• Windmill cung cấp nhiều cách để truyền dữ liệu như biểu thức JavaScript, chia sẻ thư mục tạm thời, tích hợp S3

Hiệu quả của worker

• Worker của Windmill xử lý một tác vụ tại một thời điểm và tăng hiệu năng bằng cách chạy tác vụ mà không cần container

Kết luận

• Windmill là một runtime và nền tảng serverless mã nguồn mở có thể self-host, cung cấp tốc độ rất cao nhờ thiết kế đơn giản và tối ưu hóa dựa trên Postgresql và Rust

Ý kiến của GN⁺

Điểm quan trọng nhất của bài viết này là Windmill hỗ trợ nhiều ngôn ngữ lập trình và cung cấp môi trường phát triển tích hợp giúp nhanh chóng xây dựng và kiểm thử workflow mà không cần SDK phức tạp hay quy trình triển khai rườm rà. Những đặc điểm này rất hữu ích với các nhà phát triển phần mềm, và hiệu năng cùng hiệu quả cao của Windmill sẽ giúp họ phát hành sản phẩm tốt hơn nhanh hơn. Bài viết mang lại nhiều nội dung thú vị cho lập trình viên, đặc biệt hấp dẫn với những ai muốn tự xây dựng workflow engine hoặc tối ưu engine hiện có.

[xguru]

Windmill - nền tảng tự động hóa và viết ứng dụng nội bộ cho công ty mã nguồn mở dựa trên Python

Nó đã được hé lộ nhẹ vào tháng 5 năm ngoái, nhưng khi đó nhà phát triển nói rằng vẫn chưa sẵn sàng để công khai, rồi bảo rằng “10 phút nữa tôi sẽ phỏng vấn YC!”... sau đó còn để lại bình luận nói là đã qua YC.
Sau khi vượt qua YC và chạy nước rút suốt 1 năm rưỡi, giờ họ đã chính thức ra mắt sản phẩm.

[GN⁺]

Ý kiến trên Hacker News

• Có vẻ như các nhà phát triển của Windmill đã làm điều hoàn toàn ngược lại với lời khuyên "hãy làm thật tốt một việc". Ngay cả khi xem Windmill.dev cũng không rõ phần mềm này dùng để làm gì. Không rõ đây là đối thủ của Retool, Airflow, Temporal, là trình dựng workflow no-code, là trình dựng UI kéo-thả, là IDE trực tuyến, hay là một công cụ có vô số tích hợp.
• Không rõ tốc độ của một workflow engine có thực sự quan trọng sau khi vượt qua một ngưỡng nhất định hay không. Nhiều workflow bao gồm các tác vụ chạy dài hạn, nên điều quan trọng là multi-tenancy, tức khả năng hỗ trợ số lượng tác vụ theo nhu cầu của người dùng trong khi mỗi tác vụ vẫn được lên lịch và thực thi như thể nó là tác vụ duy nhất trên workflow engine.
• Tôi muốn chuyển các quy trình kinh doanh từ spreadsheet, email cá nhân và trí nhớ của quản lý sang web form, upload, email tự động và dashboard. Tôi đã xem qua Airtable, Smartsheet, Budibase, nhưng có vẻ chúng tập trung nhiều hơn vào quản lý dự án và chưa thực sự đáp ứng tốt về tích hợp lịch, email hay script chạy theo lịch. Nếu cần, tôi có thể viết code hoặc dùng API cho dữ liệu, và tôi thích cách tiếp cận low-code, nơi quản trị viên có thể làm một phần công việc UI với chế độ xem spreadsheet còn lập trình viên xử lý phần tích hợp.
• Tôi ngạc nhiên khi mọi người bỏ ra nhiều thời gian và công sức để viết bài mà lại không dùng trình kiểm tra chính tả dù chỉ một lần. Không biết liệu đến năm 2023 vẫn còn người dùng trình soạn thảo văn bản mặc định không có kiểm tra chính tả hay không.
• Thật khó hiểu khi nói là mã nguồn mở nhưng lại có giới hạn 10 người dùng SSO. Mã nguồn mở thường cho phép sửa mã, nhưng không rõ họ thực thi giới hạn 10 người này bằng cách nào. Tôi xem mã nguồn thì thấy có đoạn kiểm tra giấy phép. Nếu là mã nguồn mở, chẳng phải ai cũng có thể gỡ bỏ đoạn mã đó sao? Nếu không thể sửa đổi thì đó là "source-available" chứ không phải "open source". Dự án trông rất hay nên tôi muốn đề xuất với sếp, nhưng không biết phải giải thích chỗ này thế nào.
• Tôi đã theo dõi Windmill từ lúc ra mắt trên HN, và bắt đầu dùng nhiều hơn từ chưa đầy một năm trước. Máy chủ Discord rất sôi động và Ruben trả lời trong vòng vài phút, thậm chí sửa bug cả vào cuối tuần.
• Tôi muốn dùng hệ thống Windmill nhưng còn ngần ngại vì vấn đề giấy phép. Phần lớn phần mềm thuộc AGPLv3, nhưng mục giấy phép thương mại trong README gợi ý một cách diễn giải AGPL rất rộng. Nếu xây dựng tính năng thông qua Windmill thì sản phẩm của bạn cũng phải là AGPLv3, điều này hàm ý rằng ngay cả việc chỉ gọi qua API cũng có thể bị coi là chịu tác động của luật bản quyền. Về mặt kỹ thuật, việc định vị Windmill là "hoàn toàn mã nguồn mở" có thể đúng, nhưng trên thực tế nó giống "source-available" hơn. Nếu Windmill không muốn giấy phép bị hiểu theo cách đó thì họ cần làm rõ.
• Windmill rất tuyệt. Có thể self-host và cần trung thành với trải nghiệm nhà phát triển (Developer Experience, DX). Tôi không cần dùng nó ở chỗ làm, nhưng ở nhà tôi dùng nó để chạy các web crawler nhỏ và các tác vụ yt-dlp. Đây là một công cụ rất thú vị.
• Tôi thấy bối rối về giấy phép.
• Tôi vẫn chưa tìm ra cách cân bằng giữa việc lưu code trong cơ sở dữ liệu và chỉnh sửa qua web IDE với việc check in code vào Git và chỉ thay đổi thông qua quy trình phát triển thông thường cùng peer review. Windmill chủ yếu lưu code trong cơ sở dữ liệu nhưng cung cấp API để đồng bộ từ kho Git. Tôi muốn biết liệu có cơ chế nào để bắt buộc các quy tắc giới hạn một số script/chức năng/secret chỉ cho các workflow được lấy từ kho lưu trữ đã chỉ định hay không.