Vì sao tôi viết một cuốn sách về BEAM (Erlang VM)

• Từ kinh nghiệm thực chiến khi duy trì các hệ thống cốt lõi của Klarna, chỉ một lần BEAM dừng 15 mili giây cũng có thể gây ra sự cố thanh toán trên diện rộng và buộc phải ứng phó khẩn cấp
• Tác giả đã dành 10 năm để viết sách với mong muốn tạo ra một tài liệu tham chiếu đáng tin cậy về BEAM
• Trong quá trình viết, tác giả nhiều lần trải qua thất bại và làm lại do đổi nhà xuất bản, vấn đề kỹ thuật và việc tái cấu trúc liên tục
• Sau khi mã nguồn được mở, phản hồi và sự tham gia của cộng đồng, số sao tăng lên và những lời động viên đã trở thành nguồn khích lệ bền bỉ
• Nội dung cốt lõi tập trung vào cấu trúc và vận hành của BEAM VM, được xây dựng để thực sự hữu ích cho các kỹ sư làm việc thực tế

---

Động lực viết sách về BEAM

Post-mortem, cà phê và 10 năm kiên trì

• Khi vận hành hệ thống thanh toán cốt lõi tại Klarna, tác giả đã nhiều lần trải qua tình huống mà chỉ 15 mili giây gián đoạn của BEAM dẫn tới hàng triệu giao dịch thanh toán thất bại, các cuộc họp khẩn lúc rạng sáng và cả việc CEO bị gọi vào xử lý
• Tác giả luôn thấy tiếc vì thiếu tài liệu có thể giúp giải quyết nhanh những khủng hoảng như vậy, và đã viết The BEAM Book với hy vọng kỹ sư tiếp theo có thể xử lý vấn đề nhanh hơn

Quá trình viết ban đầu

Khởi đầu và thất bại

• Tháng 10/2012, dự án bắt đầu với một file DocBook cùng rất nhiều tham vọng
• Các commit trong 2 tuần đầu chủ yếu tập trung vào cấu trúc và cập nhật metadata, còn nội dung thực tế thì rất ít
• Sang tháng 11, tác giả chuyển sang AsciiDoc và custom build script và kỳ vọng hoàn thành trong 6 tháng, nhưng tiến độ rất chậm do liên tục viết lại và thay đổi cấu trúc

Hợp tác với nhà xuất bản

• Năm 2013, sau khi ký hợp đồng xuất bản với O’Reilly, tác giả di chuyển sang Atlassian Atlas nhưng liên tục gặp vấn đề mất file và quản lý chương
• Lịch sử Git dày đặc những lời than phiền và các lần chỉnh sửa cấu trúc
• Tháng 3/2015, tác giả thử các biện pháp tình thế như ép tách nội dung theo từng chương chỉ để build có thể chạy qua
• Hai tháng sau, hợp đồng bị chấm dứt một cách lặng lẽ, để lại cảm giác vừa tự ti vừa nhẹ nhõm
• Nỗ lực thứ hai với Pragmatic Bookshelf cũng dừng lại trong bối cảnh tiến độ chậm chạp

Thiết lập lại và sự tham gia của cộng đồng

• Tháng 1/2017, toàn bộ nội dung được chuyển sang repo mới bằng một massive commit (6622 file, 1 triệu dòng), nhưng việc viết lại vẫn tiếp tục đình trệ
• Tháng 3/2017, tác giả bắt đầu lại trong một repo GitHub riêng tư dựa trên Asciidoctor, chỉ sao chép những phần cần thiết
• Hai tuần sau khi chuyển sang công khai, các đóng góp từ bên ngoài như sửa typo, thêm sơ đồ và hỗ trợ về giấy phép đã xuất hiện rất tích cực

Những yếu tố tạo động lực bền bỉ

• Về bản chất, động lực lớn nhất là sự tò mò và mong muốn cá nhân nhằm hiểu BEAM thực sự hoạt động như thế nào
• Phản hồi và đề xuất từ cộng đồng giúp tăng quyết tâm viết tiếp, còn số sao trên GitHub tăng lên tạo ra hiệu ứng khích lệ kéo dài
• Các issue động viên như “Please continue being awesome” cũng đóng vai trò hỗ trợ tinh thần rất lớn
• Việc cuốn sách ngày càng được trích dẫn thường xuyên tại các hội thảo và conference liên quan tới Erlang và BEAM đã chứng minh nhu cầu thực tế của nó
• Những lần được nhắc đến và chia sẻ liên tục trên Twitter và các nơi khác cũng thúc đẩy tác giả tiếp tục viết

Cấu trúc sách và đối tượng độc giả chính

• Nội dung được viết xoay quanh những phần mà tác giả thực sự thấy cần thiết khi trực tiếp thiết kế và vận hành các hệ thống Erlang quy mô lớn
  • Scheduler và quản lý process: nguyên lý scheduling process, độ ưu tiên và cân bằng trong tải thực tế
  • Bộ nhớ của process: cách quản lý heap, stack, message, binary và tác động tới vận hành
  • Garbage collection và mô hình bộ nhớ: cách GC theo từng process/toàn cục hoạt động, rò rỉ bộ nhớ và cấu trúc tham chiếu
  • Hệ thống biểu diễn dữ liệu: cấu trúc tagging nội bộ của dữ liệu như số nguyên, số thực, tuple, binary
  • Compiler và cấu trúc bên trong VM: luồng thực thi lệnh thực tế trong VM sau biên dịch
  • Tracing và debugging: dbg, erlang:trace, theo dõi message và event
  • Tối ưu hiệu năng: profiling mã thực tế, phân tích nguyên nhân độ trễ, cách hiểu reduction
  • Kiến trúc hệ thống: nguyên lý phối hợp hoạt động giữa ERTS, BEAM VM và các subsystem
• Sách có tác động rất thực tế với người vận hành Erlang/Elixir trong môi trường production, và mục tiêu cốt lõi là trở thành một cẩm nang tổng hợp đáng tin cậy thay cho các tài liệu rời rạc

Bài học rút ra từ quá trình viết

• Sự bền bỉ thắng chủ nghĩa cầu toàn. Ngay cả hai lần bị hủy xuất bản cũng dẫn tới kết luận rằng hoàn thành vẫn tốt hơn để dang dở
• Tập trung và thiết lập ranh giới là rất quan trọng. Việc dành riêng thời gian viết, tắt thông báo và quản lý thời gian nghiêm ngặt là nguồn gốc của tiến triển thực sự
• Công khai và phản hồi là chìa khóa để nâng cao chất lượng. Hiệu đính, động viên và kích thích đều đặn từ bên ngoài giúp ích rất nhiều
• Quản lý phạm vi là điều bắt buộc. Nhờ điều chỉnh phạm vi, các chủ đề khó như Dirty Scheduler hay JIT được chuyển sang phụ lục sau này
• Chiến lược cải tiến lặp lại sau khi phát hành là rất quan trọng. BEAM thay đổi mỗi năm, và một repo Git sống có thể tiếp tục được bổ sung
• Việc đặt ra deadline thật sự là động lực thực tế. Mốc phải in xong trước sự kiện Code Beam Stockholm đã buộc tác giả chọn lọc những nội dung thiết yếu

Định nghĩa của sự hoàn thành

• Chỉ khi thực sự cầm bản in trên tay, tác giả mới cảm thấy đó là lúc có thể gọi là “hoàn thành”
• Những commit rời rạc cuối cùng đã được gom lại thành một thực thể là một cuốn sách, và tính tới hiện tại tác giả tuyên bố hành trình này đã kết thúc

Cách tham gia

• The BEAM Book 1.0 hiện có thể mua bản giấy trên Amazon
  • Liên kết Amazon
• Nếu phát hiện lỗi chính tả, điểm cần cải thiện hoặc muốn tìm hiểu về cấu trúc bên trong, bạn có thể dùng star, fork, đăng issue và pull request trong repo GitHub
  • Tên thật của người đóng góp sẽ được nhắc tới trong phần cảm ơn
  • GitHub: theBeamBook
• Vì review thực tế ảnh hưởng lớn hơn tới thuật toán nên tác giả cũng tích cực kêu gọi viết nhận xét
• Tác giả cũng có thể tổ chức workshop về BEAM internals xoay quanh các hệ thống thực chiến; liên hệ qua email [e-mail]

[GN⁺]

Ý kiến trên Hacker News

• Có thể xem kho git tại đây

• Động lực của tác giả khi cứ tiếp tục đào sâu chỉ vì muốn thực sự hiểu BEAM gây ấn tượng mạnh. Tôi nghĩ chính kiểu đam mê này tạo ra những thành quả tuyệt vời. Vì vậy tôi quyết định mua ngay. Chia sẻ từ trải nghiệm của mình thì tôi đã nhiều lần nhận được đề nghị viết sách từ nhà xuất bản, nhưng chưa lần nào thành vì định hướng hai bên khác nhau. Ví dụ, tôi không muốn viết sách nhập môn Java cho đối tượng 14 tuổi, còn nhà xuất bản thì lại không quan tâm đến những chủ đề tôi thích đào sâu, như classloader. Tôi tò mò không biết người khác tìm giao điểm giữa đam mê cá nhân và nhu cầu độc giả như thế nào

  • Từ kinh nghiệm viết ba cuốn sách, tôi thấy либо là tự xuất bản, либо là viết cuốn sách mà nhà xuất bản muốn. Mỗi nhà xuất bản theo đuổi một phong cách sách khác nhau, và nhiều nơi tập trung vào sách thực hành cho người mới bắt đầu, nên nếu muốn viết về chủ đề không đại chúng thì thực tế là nên chuẩn bị tự xuất bản. May là giờ việc tự xuất bản đã dễ hơn và cũng có thể bán online. Nói cách khác, nếu chủ đề nhắm vào một thị trường ngách thực sự hẹp thì đừng kỳ vọng vào nhà xuất bản, mà phải tự lo cả xuất bản lẫn quảng bá
  • Nếu bản thân bạn kể một câu chuyện thú vị, cuối cùng độc giả sẽ tự tìm cách để hiểu nó. Hồi đầu sự nghiệp tôi đã đọc “Essential .Net” của Don Box, và anh ấy cũng không có cảm giác đang nhắm tới một tệp độc giả cụ thể nào. Đó đơn giản là một cuốn sách đào rất sâu vào nội bộ CLR, và để hiểu hết từ đầu thì phải đọc đi đọc lại nhiều lần
  • Tôi đang băn khoăn liệu có nhất thiết phải phụ thuộc vào nhà xuất bản hay không, hay là mình hoàn toàn có thể tự viết sách một cách độc lập. Không rõ là vì tên tuổi của nhà xuất bản hay những lợi ích đi kèm khác
  • Tôi đồng ý rằng việc dạy người khác là phương pháp học tốt nhất. Tôi học được điều đó khi làm gia sư toán ở trường phổ thông, và trải nghiệm viết sách cũng tương tự. Đây là cách tốt nhất để biến những nội dung cốt lõi thành kiến thức thực sự của mình, vượt xa mức chỉ đơn thuần hiểu nó
  • Hơi giống khoe khoang một chút, nhưng tôi cũng từng đào rất sâu vào chủ đề này rồi viết hẳn một cuốn sách về rèn luyện sức mạnh cho leo núi. Ban đầu tôi định tự xuất bản, nhưng cuối cùng đã tìm đến nhà xuất bản và chỉnh lại cho dễ đọc hơn một chút. Chủ động tiếp cận nhà xuất bản cũng là một cách

• Trải nghiệm làm việc với BEAM và Erlang/OTP là một trong những trải nghiệm phát triển tốt nhất của tôi trong suốt năm qua. Tôi đã dùng cuốn “Programming Erlang: Software for a Concurrent World” của Joe Armstrong và rất muốn khuyên người mới nên đọc. “Designing for Scalability with Erlang/OTP” cũng được đánh giá cao nhưng tôi vẫn chưa bắt đầu. Tuy vậy, xét về độ sâu thì cuốn sách lần này áp đảo hoàn toàn. BEAM thực sự giống như công nghệ ngoài hành tinh do một nền văn minh cổ đại để lại. Cuốn sách này xuất hiện đúng thời điểm nên tôi mua ngay. Tôi thật sự khâm phục tiến sĩ Erik Stenman vì đã hoàn thành cuốn sách dù đã hai lần bị hủy xuất bản

  • Tôi tò mò không biết bạn đã phát triển phần mềm gì bằng BEAM/Erlang/OTP

• Elixir và BEAM là lựa chọn ưa thích nhất của tôi khi xây dựng các hệ thống dựa trên mạng hoặc có nhiều pipeline. Tôi đã dùng chúng mỗi ngày trong production suốt nhiều năm, và dù ở các dự án gần đây việc lựa chọn không còn dễ dàng nữa, tôi vẫn luôn theo dõi xu hướng. Cảm ơn vì cuốn sách này đã được xuất bản. Vài năm trước, khi debug Elixir trên production, đây chính xác là cuốn sách mà tôi rất muốn có. Tài liệu sẵn có khi đó либо quá khó, либо lại quá đơn giản nên khá đáng tiếc

• Có thể xem thông tin về BEAM (Erlang virtual machine) tại liên kết Wikipedia

  • Ngay trong tên sách đã giải thích khá rõ rồi

• Tôi nghĩ BEAM là một trong những công nghệ bị đánh giá thấp nhất trong thế giới mã nguồn mở. Ví dụ điển hình là whatsapp. Thật khó hiểu vì sao Elixir và Erlang lại không phổ biến hơn trong các dự án đòi hỏi đồng thời cao

  • Chỗ làm của tôi là một công ty chuyên về Erlang. Giá trị thật sự của Erlang nằm ở lưu lượng quy mô lớn như hàng triệu DAU. Bạn có thể chạy một website Elixir với vài nghìn DAU, nhưng bản chất của Erlang và BEAM nằm ở quy mô đó. Không có quá nhiều công ty thực sự cần cỡ này, và vấn đề lớn hơn là bản thân hệ sinh thái Erlang vận hành gần như một hệ điều hành riêng, nên thiết lập môi trường và các thành phần khá phức tạp. Cũng không cần những công nghệ hạ tầng khác như container hay k8s, và ngược lại vì cách làm riêng của Erlang nên nó tạo cảm giác không quen thuộc. Nếu được trải nghiệm Erlang trong một tình huống thực sự phù hợp, tôi nghĩ nó giống như ma thuật. Đó là một trong những đỉnh cao sự nghiệp của tôi
  • Cuối cùng tôi nghĩ đó là ảnh hưởng của marketing. Java, C#, Go có hậu thuẫn doanh nghiệp rất mạnh, còn Erlang thì ngược lại doanh nghiệp hoặc là cản trở, hoặc gần như chẳng quan tâm ngoài phần tài liệu kỹ thuật. Elixir là lần đầu tiên đi theo kiểu marketing của một ngôn ngữ khác, mô hình kiểu Ruby, nhưng thời điểm và hoàn cảnh lại khác. Các lập trình viên có thể bị thuyết phục bởi sự xuất sắc của BEAM, nhưng có vẻ nó không truyền tải tốt tới những người ra quyết định bên ngoài nhóm kỹ thuật
  • Tôi nghĩ khác biệt về đầu tư là rất lớn. Rust, Go, Python... đều được đầu tư mạnh nhờ hỗ trợ từ doanh nghiệp vào static analysis, type checking, trải nghiệm lập trình viên và nhiều thứ khác, trong khi Erlang chưa nhận được đủ sự ưu ái như vậy, và những người dùng lớn cũng dần tự xây giải pháp bên ngoài BEAM hoặc chuyển hướng
  • Gần đây chúng tôi đã chuyển một website Squarespace sang ứng dụng Phoenix, và đó thực sự là một trải nghiệm rất thú vị
  • Đồng thời đây cũng là thứ “bí quyết bí mật” ít bí mật nhất. Gần đây BBC cũng đã chuyển sang Elixir, nên tôi có cảm giác mức độ phổ biến của nó đang tăng dần

• Tôi thích phần giải thích rằng “Erlang Runtime System (ERS)” là cách gọi chung cho runtime Erlang nói chung, còn “Erlang RunTime System (ERTS)” là cách gọi chỉ giới hạn cho bản triển khai của Ericsson

  • Tôi không nghĩ định nghĩa đó là ngớ ngẩn

• Tôi đã mua sách ngay. Có thể đọc miễn phí online, nhưng tôi vẫn muốn ủng hộ tác giả một chút nên đã mua

• Tôi không làm các hệ thống quy mô lớn như Klarna nên khó cảm nhận, nhưng thật lạ khi độ trễ 15ms lại trở thành một vấn đề phải viết postmortem

  • Trong BEAM, phản hồi ở mức micro giây (μs) là chuyện bình thường, nên nếu bật lên tới mili giây (ms) thì có thể báo động sẽ kêu ngay
  • Trong các hệ thống BEAM, tình huống này hoàn toàn có thể xảy ra. Nếu bạn tạo một gen_server để bảo vệ shared state thì về cơ bản nó giống một mutex khổng lồ. Nếu gen_server mất 20us để xử lý một yêu cầu, thì độ trễ 15ms đồng nghĩa với việc 750 message đã bị chất vào hàng đợi. Nếu lại dùng message queue theo pattern kém hiệu quả thì hiệu năng sẽ giảm rất mạnh. BEAM chỉ tối ưu hóa message queue cho một số pattern nhất định, còn với những pattern khác thì thời gian xử lý tăng theo độ dài hàng đợi. Nếu bên trong thư viện có dùng receive không an toàn thì có thể phát sinh suy giảm hiệu năng ngoài dự đoán. Gần đây BEAM đã thêm tính năng alias để khắc phục vấn đề message queue, nhưng nhiều thư viện vẫn chưa dùng. alias chủ yếu nhằm ngăn mất message, đồng thời ngăn hàng đợi bị ô nhiễm bởi timeout message. Thông thường các process sống lâu sẽ xử lý hàng đợi theo vòng lặp
  • Nếu ai biết liên kết tới postmortem của sự cố được nhắc đến thì tôi rất muốn xem. Tôi không tìm thấy trên mạng

• Tôi tò mò liệu có VM nào tương tự BEAM không. Không biết là vì BEAM quá xuất sắc nên không có đối thủ, hay vì nó khó làm đến mức đó

  • Tôi cho rằng nhiều chức năng mà hạ tầng Kubernetes hiện đại cung cấp khá giống với BEAM. Ngày nay người ta có thể xây các hệ thống self-healing quy mô lớn bằng kiểu hạ tầng này mà không bị ràng buộc bởi ngôn ngữ. Ngoài Erlang/Elixir còn có nhiều hệ sinh thái, nguồn nhân lực và mối quan tâm khác nữa
  • Cũng có một bản triển khai riêng tên là AtomVM dành cho các thiết bị bị hạn chế tài nguyên như IoT. Đã có nhiều nỗ lực nhằm hiện thực hóa BEAM hoặc OTP trong các hệ sinh thái khác, nhưng đa số không ở cấp độ VM
  • Ở giai đoạn cuối thập niên 1990, đầu 2000 khi BEAM ra đời thì nó khá độc đáo. Còn bây giờ, dù cách triển khai khác nhau, người ta có thể giải quyết tốt cùng một loại vấn đề bằng nhiều ngôn ngữ và công cụ khác nhau. Cộng đồng Erlang cũng có kiểu thái độ khá đặc trưng rằng “chỉ cách của BEAM mới là đúng”, nhưng ở năm 2025 thì thực sự có rất nhiều lựa chọn. Cũng có những bản triển khai tương thích BEAM, nhưng hầu hết ở các ngách khá nhỏ. Nếu không cần tham gia vào hạ tầng BEAM sẵn có, thì với một dự án greenfield, tôi nghĩ các giải pháp hiện đại trong hệ sinh thái ngày nay thường phù hợp hơn. Cũng có những dự án nhỏ như ergo
  • Có lẽ Dis VM là thứ giống nhất, rồi đến Smalltalk VM. Thực ra giá trị của BEAM không chỉ ở bản thân nó mà ở chỗ có OTP đặt lên trên mới phát huy hết sức mạnh
  • Trong thực tế sử dụng, thứ giống nhất có lẽ là Go. BEAM là một hệ sinh thái được tối ưu cho các “ngôn ngữ kiểu Erlang”, nên với Elixir hay Gleam thì hành vi cốt lõi vẫn tương tự Erlang. Go cũng cung cấp các primitive mang phong cách Erlang như goroutine trong xử lý đồng thời, nhưng không có một quan điểm rõ ràng về cấu trúc ứng dụng như OTP