Unikernel từng rất khó — nhưng đó là chuyện của quá khứ, vì nay đã có AI

Unikernel từng là một khái niệm đầy hứa hẹn nhưng cũng đầy chông gai. Giờ đây, khi AI đã trở thành trợ thủ đắc lực cho lập trình viên, những rào cản từng khiến unikernel khó tiếp cận đang dần biến mất — và đó là lý do nhiều kỹ sư đang quay lại với ý tưởng này.

Unikernel là gì và vì sao nó từng khó?

Unikernel là mô hình trong đó ứng dụng của bạn chính là hệ điều hành. Không có userland, không có tiến trình nào để fork hay spawn. Nếu bạn muốn có web server, DNS hay chức năng gửi email, bạn phải viết chúng dưới dạng thư viện ngay trong ứng dụng.

Chính sự thiếu thốn đó tạo nên lực cản. Justin Cormack, người từng làm việc với MirageOS và Unikernel Systems, nhớ lại: khi xây dựng Mirage, họ có TCP stack và HTTPS stack nhưng gần như không có gì cho lưu trữ. Họ phải lấy driver từ NetBSD để chạy trong userspace. Thời đó, mọi thứ đều khó.

Nix khó. Bazel khó. Unikernel khó. Đúng, chúng từng khó. Nhưng những khái niệm khó đó giờ đã nằm trong trọng số của mô hình AI.

Điều thay đổi then chốt là: bạn chỉ cần prompt để AI viết những thứ trước đây đòi hỏi hàng tuần, thậm chí hàng tháng công sức.

Hệ điều hành là một món nợ thiết kế

Mọi ứng dụng không phải unikernel đều được xây dựng trên giả định rằng có ứng dụng, và có hệ điều hành bên dưới. Nhưng vì sao chúng ta cần hệ điều hành? Vì bốn mươi năm trước, có một người vận hành ngồi trước máy. Hệ điều hành đa người dùng ra đời để phục vụ con người đó.

Theo góc nhìn hiện đại, đây là nợ thiết kế. Ứng dụng bị tấn công, kẻ xâm nhập có được shell — và shell đó giống như dịch vụ quản gia hạng sang cho việc rút dữ liệu ra ngoài.

Với unikernel, bề mặt tấn công nhỏ hơn rất nhiều. Nếu chức năng không tồn tại trong ứng dụng (cũng chính là hệ điều hành), kẻ tấn công sẽ bế tắc — không có bước nhảy tiếp theo.

Tuy nhiên, cần công bằng mà nói: giảm bề mặt tấn công là việc mọi người còn khá mơ hồ. Bạn có thể xóa shell khỏi container Linux, nhưng gần như môi trường Linux nào cũng còn thứ gì đó hoạt động như một trình thông dịch.

Khi AI có thể chuyển đổi thư viện trong vài giờ

Lập luận kinh điển chống lại unikernel: bạn cần tích hợp Stripe, nhưng OCaml không có thư viện Stripe. Trước đây, bạn phải tự viết. Còn bây giờ? Chạy một vòng lặp để chuyển thư viện Go sang OCaml. Xong.

Justin Cormack có một ví dụ tương tự: ông cần tạo filesystem XFS. Thay vì kéo theo xfsprogs và mọi thứ đi kèm, ông ngồi với một AI agent và yêu cầu nó viết lại mkfs.xfs bằng Rust — cho ra kết quả giống hệt từng byte, với mọi cờ được diễn giải đúng. AI đã dịch ngược các định dạng trên đĩa, kiểm thử với nhiều kích thước block khác nhau. Chỉ mất vài giờ.

Nếu bạn có một "oracle" để đối chiếu, việc chuyển đổi chỉ là một vòng lặp.

Nix và kiểm thử máy ảo

Nix cũng là một lĩnh vực được hưởng lợi. Bản thân ngôn ngữ Nix bị nhiều người chê, nhưng Nixpkgs thì tuyệt vời. Đặc biệt, NixOS machine tests cho phép bạn viết bài kiểm thử khởi động cả một đội máy ảo và kiểm tra tương tác giữa quy tắc mạng với ứng dụng — điều mà ít người biết đến.

Khi có vấn đề ở thượng nguồn hoặc chuỗi cung ứng phụ thuộc, giải pháp chỉ là một overlay.

Thế giới vẫn chưa nhận ra rằng bạn có thể sửa mọi thứ chỉ bằng một overlay Nix.

Bảo mật: chỉ có hai lựa chọn thực sự

Nếu bạn quan tâm sâu sắc đến bảo mật, theo quan điểm trong bài viết, chỉ có hai con đường:

• Bạn đang phóng vệ tinh lên vũ trụ — hãy dùng seL4, một hệ điều hành được xác minh hình thức.
• Còn lại — hãy nghiêm túc cân nhắc unikernel. Đừng cố gia cố một thứ vốn dễ bị tấn công; hãy đảo ngược và thiết kế từ hướng khác.

Nhiều thiết kế unikernel ban đầu chạy mọi thứ ở cùng một mức đặc quyền. Nhưng đến năm 2026, việc tách ring bảo vệ chỉ cách một câu prompt nếu bạn muốn. Chắc chắn còn an toàn hơn việc cầu nguyện rằng cấu hình systemd cgroup của bạn đúng.

Hãy nghĩ đến thời gian doanh nghiệp bỏ ra để vá hệ thống mỗi khi Linux có lỗ hổng mới. Tuần diễn ra cuộc trò chuyện này, có người đã khai thác được KVM — thứ mà ai cũng tưởng là sandbox tốt — và nhận 50.000 USD từ Vercel cùng vài nhà cung cấp khác. Số tiền đó quá nhỏ cho một lỗ hổng có thể root mọi nhà cung cấp cloud.

Spaceleans: hệ điều hành unikernel phân tán

Trong khoảng bảy tháng, tác giả đã đào sâu vào unikernel và xây dựng một loạt thư viện: NTP client và server dựa trên RADclock, network stack, DNS, HTTP client/server, structured logging, OTel, client cho Anthropic và OpenAI, thanh toán qua Airwallex, thư viện retry xử lý back pressure, cùng một wrapper che PII ở ranh giới logging.

Và thứ "điên rồ" nhất: Spaceleans — Microsoft Orleans được chuyển sang OCaml, chạy như một unikernel.

Orleans là hệ thống actor phân tán có giao dịch. Bạn gộp nhiều máy vật lý thành một heap có thể định địa chỉ. Một actor luôn tồn tại: gọi GetCustomer(), nếu không có trong bộ nhớ, nó tự phục hồi từ storage provider. Kiến trúc n-tier được thu gọn thành actor, không cần quan tâm thứ gì nằm ở máy A, B, C hay D.

Tôi đã làm tất cả trong một tuần. Có thể sẽ không bao giờ phát hành, nhưng nó đã phủ định ý tưởng rằng unikernel là khó.

OCaml, Rust, Haskell và bài toán back pressure

Liệu thời của OCaml đã trở lại? Nó vẫn mạnh mẽ. Với AI agent, OCaml rất dễ chịu: functor giữa các module rất đẹp, file .mli — phần header có kiểu giải thích cách module hoạt động — là ngữ cảnh cực kỳ hiệu quả cho agent. opam và Dune thực sự tốt, thời gian biên dịch nhanh.

Justin chủ yếu viết Rust, và AI agent làm Rust rất tốt. Nhưng thời gian biên dịch là thuế đánh vào back pressure. Khi biên dịch chậm, mỗi lần AI ảo giác sẽ tốn kém hơn vì bạn có ít lần thử hơn mỗi phút.

Haskell có hệ thống kiểu tuyệt vời và mô hình làm rất tốt, nhưng space leak sống trong trạng thái runtime và chỉ xuất hiện ở production — điều khiến nó khó dùng trong môi trường thực tế.

Với tác giả, dependent types là người thắng cuộc cho thế hệ ngôn ngữ tiếp theo. Bất cứ thứ gì cho phép mã hóa nhiều hơn vào hệ thống kiểu đều tạo ra back pressure tốt hơn.

Ngôn ngữ dành cho AI agent

Tốc độ phát triển ngôn ngữ lập trình xưa nay bị kìm hãm bởi tốc độ con người học khái niệm mới. Operator chaining chủ yếu là đường cú pháp cho con người. Nếu AI viết code, chúng ta có thể dựa vào bốn mươi năm nghiên cứu lý thuyết ngôn ngữ lập trình.

Ngành công nghiệp đã đặt ra quy tắc "không thay đổi phá vỡ tương thích" sau vụ Python 2 lên 3. Theo tác giả, quy tắc đó không còn đúng nữa. Hãy phát hành một skill pack kèm thay đổi phá vỡ và để AI tự động di chuyển mã nguồn.

Bài học từ Cursed

Tác giả từng chạy Claude trong vòng lặp suốt ba tháng và tạo ra Cursed — một ngôn ngữ lập trình thế hệ Gen Z, nơi bạn có thể code bằng sus, slay và vibes. Đây là ngôn ngữ biên dịch duy nhất cho phép điều đó.

Cursed được xây dựng với Sonnet 3.5 và 3.7, một prompt cố tình mơ hồ, và ba tháng chạy vòng lặp. Chi phí khoảng 6.000 USD, và tác giả đã làm ba lần.

Điều đáng sợ hơn: nếu phân bổ context window đúng cách — với bảng tra cứu cấu trúc từ vựng và ngữ pháp — mô hình có thể lập trình bằng một ngôn ngữ không nằm trong trọng số của nó. Cách này thô sơ và kém hiệu quả, nhưng nó hoạt động.

Chỉ cần một nhà thiết kế ngôn ngữ lập trình dốc toàn lực với các mô hình tốt là có thể gây chấn động thế giới.

Điều gì tiếp theo?

Nếu bạn quản lý đội ngũ, hãy tạo không gian và thời gian để họ thử nghiệm ngay bây giờ, vì trong vòng sáu tháng, ban lãnh đạo sẽ yêu cầu đưa ra đường cong năng suất.

Nếu đội của bạn quá bận với "công việc bình thường" đến mức không thử nghiệm với AI, bạn đang chuẩn bị cho việc họ bị thay thế.

Việc dùng AI giờ đây đã trở thành điều kiện bắt buộc để có thể tuyển dụng. Các phòng lab đã huấn luyện trên tài nguyên chung — điều đáng tiếc, nhưng đó là thực tế. Bạn đánh đổi thời gian và kỹ năng để lấy tiền, và tiêu chuẩn tối thiểu của nhà tuyển dụng đang thay đổi nhanh hơn bao giờ hết.

Hãy tò mò, học cách xây dựng AI agent, và tạo ra những thứ đẹp đẽ. Chúng ta đang sống trong một thời kỳ Phục hưng.

Và nếu bạn muốn xây dựng thứ gì đó bảo mật, hãy nghiêm túc cân nhắc unikernel.