Rails 8 được phát hành với tiền đề táo bạo:“Không cần PaaS”. Khi nền tảng đám mây ngày càng tốn kém hơn, Ruby on Rails đã chuyển sang giảm sự phụ thuộc vào cơ sở hạ tầng bên ngoài để các nhà phát triển có thể triển khai và chạy các ứng dụng với ít sự phụ thuộc dịch vụ hơn bao giờ hết.
Theo truyền thống, việc triển khai ứng dụng Rails lên internet có nghĩa là cung cấp máy chủ cơ sở dữ liệu (ví dụ:PostgreSQL) và các dịch vụ bổ sung như Redis để lưu vào bộ nhớ đệm, tác vụ nền hoặc WebSockets. Với Rails 8, nhóm cốt lõi hy vọng sẽ thay đổi điều đó bằng cách tạo ra các giải pháp về bộ nhớ đệm, hàng đợi công việc và WebSockets thời gian thực - tất cả đều được hỗ trợ bởi cơ sở dữ liệu của ứng dụng của bạn.
Trong bài viết này, chúng ta sẽ khám phá cách Rails 8 thực hiện lời hứa “Không cần PaaS”, bắt đầu bằng phần tổng quan về “Solid Trifecta”.
Solid Cache giúp bạn lưu vào bộ nhớ đệm mà không cần Redis
Một trong những bổ sung yêu thích của tôi trong Rails 8 là Solid Cache , một kho lưu trữ bộ đệm mới thay thế nhu cầu sử dụng Redis hoặc Memcached . Solid Cache sử dụng cơ sở dữ liệu để duy trì dữ liệu được lưu trong bộ nhớ đệm thay vì lưu trữ khóa-giá trị trong bộ nhớ. Mặc dù việc lưu trữ các đối tượng được lưu trong bộ nhớ đệm trên đĩa về mặt kỹ thuật chậm hơn RAM nhưng vẫn có một số lợi thế đáng kể.
Đầu tiên, bộ lưu trữ trên đĩa mang lại cho bạn nhiều dung lượng hơn và rẻ hơn nhiều so với bộ nhớ. Với Solid Cache, bạn có thể lưu trữ nhiều dữ liệu hơn (và lưu giữ lâu hơn) mà không hết RAM. Tại 37signals (công ty đứng sau Basecamp và HEY), việc chuyển từ Redis sang Solid Cache cho phép họ mở rộng bộ nhớ đệm lên hơn 10 terabyte dữ liệu, cuối cùng giúp giảm 50% thời gian kết xuất P95 của họ.
Có, đọc từ bộ nhớ nhanh hơn đọc từ đĩa. Trong nhiều trường hợp (chẳng hạn như cách sử dụng Basecamp), việc đánh đổi nhiều dữ liệu hơn vào bộ nhớ đệm khiến tốc độ đạt được là xứng đáng.
Theo mặc định, Rails 8 sử dụng Solid Cache (được hỗ trợ bởi SQLite). Tất nhiên, như thường lệ đối với các quy ước Rails, bạn vẫn có thể chọn một tùy chọn khác như Redis nếu đó là lựa chọn tốt hơn cho bạn. Tuy nhiên, việc sử dụng mặc định này cho phép bạn lưu vào bộ nhớ đệm mọi thứ mà không cần hỗ trợ dịch vụ sản xuất khác như Redis, giúp đơn giản hóa gánh nặng cơ sở hạ tầng của bạn.
Hàng đợi vững chắc giúp bạn thực hiện các tác vụ nền — không cần Redis
Phần yêu thích thứ hai của tôi trong bộ ba “Solid” là Solid Queue, một phần phụ trợ Active Job mới xử lý việc xử lý công việc nền mà không cần Redis hoặc thậm chí là một phần phụ thuộc hệ thống công việc riêng biệt như Sidekiq.
Nhiều nhà phát triển Rails sử dụng các gem như Sidekiq (dựa trên Redis) hoặc Delayed Job cho các công việc nền. Hàng đợi vững chắc là nỗ lực của Rails nhằm loại bỏ nhu cầu cho một sự phụ thuộc khác. Nó tích hợp hàng đợi công việc vào cơ sở dữ liệu ứng dụng của bạn, do đó bạn không cần giải pháp bộ nhớ hoặc hệ thống xếp hàng.
Solid Queue lưu trữ các công việc dưới dạng bản ghi trong bảng cơ sở dữ liệu và sử dụng các tính năng SQL hiệu quả để quản lý hàng đợi công việc. Nó có thể chạy được nhúng trong quy trình web Rails (dưới dạng plugin Puma để thiết lập một máy chủ) hoặc trong các quy trình riêng biệt.
Như một thành viên nhóm cốt lõi của Rails đã lưu ý, mục tiêu là cho phép nhà phát triển "cài đặt Rails, thiết lập cơ sở dữ liệu và xử lý công việc nền ngay lập tức mà không cần phải quản lý bảy loại đá quý khác nhau và các hệ thống khác."
Solid Cable giúp bạn làm web socket (ngạc nhiên thay, không cần Redis)
Phần thứ ba trong câu đố “Không cần làm lại” của Rails 8 là Cáp rắn — một bộ điều hợp Action Cable mới, như bạn đoán, sử dụng cơ sở dữ liệu. Trước đây, Action Cable yêu cầu máy chủ Redis để phát các tin nhắn giữa nhiều quy trình Rails. Với Solid Cable, bạn có thể tận dụng Action Cable cho chức năng WebSocket thời gian thực, mở khóa các bản cập nhật trực tiếp cho các tính năng của ứng dụng như trò chuyện và thông báo—mà không cần chạy các dịch vụ bổ sung.
Tôi hy vọng lợi ích của trifecta “Solid” hiện đã trở nên rõ ràng. Bạn có thể lưu trữ dữ liệu dài hạn vào bộ đệm, xử lý các tác vụ nền có thông lượng cao và triển khai các tính năng theo thời gian thực mà không cần thiết lập máy chủ Redis hoặc dịch vụ pub/sub khác. Cùng với nhau, các tính năng này làm giảm độ phức tạp cho các ứng dụng nhỏ (bạn có thể chạy mọi thứ trên một máy chủ với một cơ sở dữ liệu) và phù hợp với triết lý của Rails 8 là giúp việc triển khai dễ dàng hơn.
Việc loại bỏ nhu cầu sử dụng Redis có phải là vấn đề lớn không?
Sau khi thấy Rails 8 tập trung nhiều vào việc loại bỏ sự phụ thuộc vào Redis, bạn có thể tò mò rằng điều đó thực sự quan trọng đến mức nào. Câu trả lời tùy thuộc vào ngữ cảnh của bạn, nhưng chắc chắn có một số lợi ích đáng chú ý.
Ít bộ phận chuyển động hơn có nghĩa là ít phức tạp hơn, đặc biệt là trong việc triển khai. Mỗi dịch vụ bổ sung (Redis, trình chạy công việc nền riêng biệt, v.v.) là một thứ khác có thể bị hỏng hoặc cần mở rộng quy mô. Bằng cách sử dụng cơ sở dữ liệu để biết thêm thông tin, bạn sẽ đơn giản hóa hoạt động sản xuất của mình. Bạn không cần phải giám sát bộ nhớ Redis hoặc đảm bảo phiên bản Redis luôn chạy.
Nhiều nhà phát triển Rails đã gặp phải tình huống trong đó, trong quá trình phát triển, bạn không chạy máy chủ bộ đệm hoặc có thể sử dụng bộ điều hợp hàng đợi khác, nhưng trong quá trình sản xuất, bạn sử dụng Redis/Sidekiq. Với các giá trị mặc định mới của Rails, bạn có thể chạy thiết lập tương tự trong quá trình phát triển và sản xuất, giảm thiểu những bất ngờ. Ngăn xếp khép kín hơn và “chỉ hoạt động” ngay lập tức mà không cần cấu hình đặc biệt để sản xuất.
Ít máy chủ hoặc tiện ích bổ sung hơn cũng có nghĩa là hóa đơn lưu trữ rẻ hơn. Ngay cả ở quy mô lớn hơn, việc củng cố cơ sở hạ tầng sẽ mang lại hiệu quả về mặt chi phí. Dung lượng cơ sở dữ liệu rẻ hơn bộ nhớ!
Rails không ngăn cản bạn sử dụng Redis hoặc các dịch vụ khác. Nó chỉ khiến chúng trở nên tùy chọn . Bạn có thể bắt đầu với bộ điều hợp Solid tích hợp sẵn và nếu cần, bạn có thể giới thiệu Redis hoặc các giải pháp khác sau này.
SQLite loại bỏ nhu cầu xử lý cơ sở dữ liệu
Một sự thay đổi có ý nghĩa khác trong Rails 8 là việc sử dụng SQLite như một cơ sở dữ liệu sản xuất có thể sử dụng được, được hỗ trợ bởi nhiều cải tiến đối với bộ điều hợp SQLite của Rails. Nếu ứng dụng của bạn có thể sử dụng SQLite trong sản xuất thì bạn không cần chạy máy chủ cơ sở dữ liệu riêng. Thay vào đó, dữ liệu của bạn tồn tại trong một tệp đơn giản trên đĩa do chính quy trình ứng dụng quản lý. Những cải tiến của Rails 8 đối với SQLite khiến điều này trở nên thực tế hơn trước đây.
SQLite có thể khiến việc triển khai trở nên đơn giản hơn nhiều. Bạn không phải cài đặt hoặc quản lý MySQL hoặc Postgres trên máy chủ hoặc sử dụng (và trả tiền!) dịch vụ DB được quản lý. Nó chỉ là một tệp mà ứng dụng Rails đọc và ghi.
Tất nhiên, nếu bạn phát triển hơn SQLite, bạn có thể chuyển sang hệ thống cơ sở dữ liệu đầy đủ tính năng sau này. Nhóm nòng cốt Rails vừa thay đổi mặc định thành một tùy chọn nhẹ—rất phù hợp với câu chuyện “No PaaS”.
Kamal 2 giúp bạn triển khai
Rails 8 đơn giản hóa việc chạy một ứng dụng đang được sản xuất—nhưng còn việc đưa ứng dụng đến thì sao? sản xuất? Việc phát hành Kamal 2 cố gắng trả lời câu hỏi đó.
Kamal là một công cụ điều phối giúp triển khai ứng dụng của bạn (thông qua bộ chứa Docker) tới bất kỳ máy chủ Linux nào một cách dễ dàng. Nó tự động xây dựng hình ảnh ứng dụng của bạn, đẩy nó và chạy nó trên máy chủ mà bạn không cần phải thực hiện thủ công tất cả quá trình thiết lập máy chủ.
Với một số cấu hình và một lệnh (kamal setup ), Kamal sẽ lấy một hộp Linux mới và cung cấp cho nó những thứ cần thiết để chạy bộ chứa Docker của bạn.
Sau đó, việc triển khai đơn giản như chạy kamal deploy , kéo hình ảnh mới nhất và hoán đổi vùng chứa cũ lấy vùng chứa mới dưới dạng triển khai không có thời gian ngừng hoạt động.
Kamal 2 hy vọng mang đến cho bạn trải nghiệm triển khai giống như PaaS trên bất kỳ máy chủ Linux nào. Bạn có thể biến bất kỳ máy chủ nào thành máy chủ Rails chạy ứng dụng của mình chỉ bằng một lệnh. Cấu hình ban đầu có thể khó khăn nhưng những lần triển khai tiếp theo sẽ đơn giản hơn nhiều. Đây là một bước tiến lớn hướng tới việc làm cho việc tự lưu trữ trở nên thuận tiện như việc đẩy lên một nền tảng như Heroku.
"Không PaaS" có phải là một ý tưởng hay không?
Rails 8 có thực sự biến nền tảng trở thành quá khứ? Và liệu các nhóm vừa và nhỏ có thực sự tiết kiệm được tiền bằng cách tự tổ chức không?
Gần đây tôi đã triển khai một dự án sở thích trên VPS bằng Kamal và đó là một trải nghiệm khó chịu. Mặc dù quá trình triển khai diễn ra tương đối liền mạch sau khi tôi bắt đầu hoạt động, nhưng việc thiết lập lại không hề dễ dàng và công việc của tôi sẽ bị cắt bỏ nếu tôi cần mở rộng quy mô dự án này.
Vì vậy, đối với tôi, câu trả lời là không — Rails 8 không loại bỏ đề xuất giá trị của nền tảng . Tôi muốn tập trung vào ứng dụng của mình hơn và để một nền tảng như Heroku xử lý cơ sở hạ tầng.
Các nhà phát triển solo và các nhóm nhỏ sẽ được hưởng lợi nhiều hơn từ việc tập trung vào người dùng của họ hơn là theo đuổi tính kinh tế nhờ quy mô. Tại sao không thuê ngoài dịch vụ lưu trữ, triển khai và mở rộng quy mô sang một nền tảng có khả năng xử lý tốt những lĩnh vực này và tập trung vào việc xây dựng một sản phẩm mà khách hàng của bạn yêu thích?
Tất nhiên, khi nhóm và ứng dụng của bạn phát triển, bạn có thể thấy giá của nền tảng kém hấp dẫn hơn. Tại một thời điểm nào đó, sẽ rất hợp lý nếu có thời gian và/hoặc người dành riêng cho SRE và các trách nhiệm vận hành, và Kamal (cùng với các cài đặt mặc định tuyệt vời khác của Rails 8) là một bước tiến lớn giúp việc đó trở nên dễ dàng hơn.
Kết hợp tất cả lại với nhau
Rails 8 thu hẹp khoảng cách giữa việc tự lưu trữ và sử dụng nền tảng, nhưng nó không thu hẹp đủ để thành thật tuyên bố “Không cần PaaS”. Tuy nhiên, rõ ràng là Rails 8 giúp việc chọn VPS thay vì PaaS dễ dàng hơn mà không phải hy sinh quá nhiều kinh nghiệm của nhà phát triển; Tôi chỉ không nghĩ đó là kẻ hủy diệt nền tảng.
Solid Cache, Solid Queue và Solid Cable đều đưa các yêu cầu trước đây của bên thứ ba đối với ứng dụng web vào hỗ trợ của bên thứ nhất và tôi rất biết ơn về điều đó. Thật tuyệt vời khi có các giá trị mặc định nhẹ nhưng mạnh mẽ để khởi động ứng dụng và thậm chí còn tuyệt vời hơn nữa là chúng không yêu cầu nhiều cơ sở hạ tầng. Nếu bạn chọn tự lưu trữ, Kamal có thể giảm bớt một số gánh nặng triển khai cho bạn.
Cho dù bạn có sử dụng nền tảng hay không thì việc giám sát là điều cần thiết để phản hồi nhanh chóng các lỗi và sự cố ngừng hoạt động, đồng thời mang lại trải nghiệm người dùng tuyệt vời cho khách hàng của bạn. Đăng ký Honeybadger để nhận được thông tin chi tiết theo thời gian thực về tình trạng và hiệu suất của ứng dụng Rails của bạn.