Kỹ sư DevOps viết các chính sách Kubernetes trong Rego. Newton viết $5 triệu quy tắc tuân thủ tài chính trong cùng một ngôn ngữ.
Lựa chọn thiết kế đó khiến tôi dừng lại khi đọc trong tài liệu chính thức của Newton tại blog.newton.xyz: "Rego là cùng một ngôn ngữ mà các nhóm CNTT đã sử dụng cho tuân thủ và thực thi chính sách trong các doanh nghiệp truyền thống."
Lý do được ghi chép rõ ràng và rất dễ hiểu. Các nhà phát triển doanh nghiệp đã quen với Rego. Các tổ chức có thể viết và kiểm toán các chính sách tuân thủ của riêng mình mà không cần học một cú pháp mới. Giảm ma sát khi triển khai giúp tích hợp nhanh hơn.
Lập luận đó là có thật. Phản biện cũng là có thật.
Rego được thiết kế cho kiểm soát truy cập trong hạ tầng phần mềm. "Cho phép dịch vụ này đọc bí mật này" và "chặn việc chuyển khoản này tới đối tác đã được chốt để trừng phạt" được viết bằng cùng một ngôn ngữ, nhưng chúng không phải là cùng một bài toán. Kiểm soát truy cập trong phần mềm khi bị từ chối yêu cầu thì chỉ là không cho phép. Còn lỗi tuân thủ tài chính khiến tiền được chuyển tới nơi không nên, kích hoạt hành động quản lý của cơ quan nhà nước và đưa các tổ chức vào rủi ro chịu trách nhiệm pháp lý. Hồ sơ hậu quả khác nhau theo bậc độ lớn.
SQL ban đầu được thiết kế để truy vấn cơ sở dữ liệu quan hệ. Khi các tổ chức tài chính bắt đầu dùng nó cho giám sát giao dịch theo thời gian thực, họ đã mất nhiều năm để phát hiện các tình huống biên mà ngôn ngữ này chưa bao giờ được thiết kế để xử lý ở mức rủi ro đó. Việc có sẵn công cụ quen thuộc trong một lĩnh vực mới không tự động có nghĩa là phù hợp với mục đích.
Newton đặt cược rằng Rego đủ khả năng diễn đạt để bao quát các tình huống biên về tuân thủ tài chính mà nó chưa từng được thiết kế cho. Điểm cộng là sự quen thuộc của nhà phát triển doanh nghiệp. Còn việc khớp với lĩnh vực chưa được kiểm chứng là phần mà không ai đang xem xét.
$NEWT #Newt @NewtonProtocol
Lựa chọn thiết kế đó khiến tôi dừng lại khi đọc trong tài liệu chính thức của Newton tại blog.newton.xyz: "Rego là cùng một ngôn ngữ mà các nhóm CNTT đã sử dụng cho tuân thủ và thực thi chính sách trong các doanh nghiệp truyền thống."
Lý do được ghi chép rõ ràng và rất dễ hiểu. Các nhà phát triển doanh nghiệp đã quen với Rego. Các tổ chức có thể viết và kiểm toán các chính sách tuân thủ của riêng mình mà không cần học một cú pháp mới. Giảm ma sát khi triển khai giúp tích hợp nhanh hơn.
Lập luận đó là có thật. Phản biện cũng là có thật.
Rego được thiết kế cho kiểm soát truy cập trong hạ tầng phần mềm. "Cho phép dịch vụ này đọc bí mật này" và "chặn việc chuyển khoản này tới đối tác đã được chốt để trừng phạt" được viết bằng cùng một ngôn ngữ, nhưng chúng không phải là cùng một bài toán. Kiểm soát truy cập trong phần mềm khi bị từ chối yêu cầu thì chỉ là không cho phép. Còn lỗi tuân thủ tài chính khiến tiền được chuyển tới nơi không nên, kích hoạt hành động quản lý của cơ quan nhà nước và đưa các tổ chức vào rủi ro chịu trách nhiệm pháp lý. Hồ sơ hậu quả khác nhau theo bậc độ lớn.
SQL ban đầu được thiết kế để truy vấn cơ sở dữ liệu quan hệ. Khi các tổ chức tài chính bắt đầu dùng nó cho giám sát giao dịch theo thời gian thực, họ đã mất nhiều năm để phát hiện các tình huống biên mà ngôn ngữ này chưa bao giờ được thiết kế để xử lý ở mức rủi ro đó. Việc có sẵn công cụ quen thuộc trong một lĩnh vực mới không tự động có nghĩa là phù hợp với mục đích.
Newton đặt cược rằng Rego đủ khả năng diễn đạt để bao quát các tình huống biên về tuân thủ tài chính mà nó chưa từng được thiết kế cho. Điểm cộng là sự quen thuộc của nhà phát triển doanh nghiệp. Còn việc khớp với lĩnh vực chưa được kiểm chứng là phần mà không ai đang xem xét.
$NEWT #Newt @NewtonProtocol