Rails 8 ส่งมอบด้วยสมมติฐานที่กล้า: "No PaaS Required" (ไม่ต้องใช้ PaaS) เนื่องจาก cloud platforms มีค่าใช้จ่ายมากขึ้น Ruby on Rails จึงเปลี่ยนมาลดการพึ่งพา infrastructure ภายนอก เพื่อให้นักพัฒนาสามารถ deploy และรันแอปพลิเคชันด้วยการพึ่งพาบริการภายนอกน้อยลง
โดยทั่วไป การ deploy Rails app สู่อินเทอร์เน็ตหมายถึงการ provision database server (เช่น PostgreSQL) และบริการเพิ่มเติมอย่าง Redis สำหรับ caching, background jobs หรือ WebSockets ด้วย Rails 8 ทีมแกนหวังจะเปลี่ยนแปลงเรื่องนี้โดย baking in โซลูชันสำหรับ caching, job queues และ real-time WebSockets - ทั้งหมด powered by database ของแอปพลิเคชันเอง
ในบทความนี้ เราจะสำรวจว่า Rails 8 ส่งมอบสัญญา "No PaaS Required" อย่างไร เริ่มจาก overview ของ "Solid Trifecta" (Solid ทริเฟกตา)
Solid Cache ช่วยให้คุณ cache ได้โดยไม่ต้องใช้ Redis
หนึ่งในฟีเจอร์โปรดของผมใน Rails 8 คือ Solid Cache cache store ใหม่ที่ แทนที่ความจำเป็นของ Redis หรือ Memcached Solid Cache ใช้ database เพื่อ persist cached data แทน in-memory key-value store แม้การเก็บ cached objects บนดิสก์จะช้ากว่า RAM ทางเทคนิค แต่มีข้อได้เปรียบที่สำคัญ
แรก พื้นที่เก็บข้อมูลบนดิสก์ให้พื้นที่มากกว่าและถูกกว่าหน่วยความจำ ด้วย Solid Cache คุณสามารถ cache ข้อมูลมากขึ้นมาก (และเก็บนานขึ้น) โดยไม่หมด RAM ที่ 37signals (บริษัทหลัง Basecamp และ HEY) การย้ายจาก Redis ไป Solid Cache ให้พวกเขาขยาย cache ไป 10+ terabytes ของข้อมูล ทำให้ P95 render times ลดลง 50%
ใช่ การอ่านจากหน่วยความจำเร็วกว่าการอ่านจากดิสก์ ในหลายกรณี (เช่นการใช้งานของ Basecamp) tradeoff ของการ cache ข้อมูลมากขึ้นทำให้ความช้าลงเล็กน้ี่นั้นคุ้มค่า
โดยค่าเริ่มต้น Rails 8 ใช้ Solid Cache (backed by SQLite) เหมือนปกติสำหรับ Rails conventions คุณยังเลือกตัวเลือกอื่นอย่าง Redis ได้ถ้ามันเหมาะสมกว่า แต่การยึดค่าเริ่มต้นนี้ทำให้คุณ cache สิ่งต่างๆ ได้โดยไม่ต้อง support production service อื่นอย่าง Redis ซึ่งลดภาระ infrastructure
Solid Queue ช่วยให้คุณทำ background jobs ได้ — โดยไม่ต้องใช้ Redis
ส่วนที่สองที่ชอบของ "Solid" trifecta คือ Solid Queue Active Job backend ใหม่ที่จัดการ background job processing โดยไม่ต้องใช้ Redis หรือแม้แต่ job system dependency แยกอย่าง Sidekiq
นักพัฒนา Rails หลายคนใช้ gems อย่าง Sidekiq (ซึ่งพึ่งพา Redis) หรือ Delayed Job สำหรับ background jobs Solid Queue เป็นความพยายามของ Rails เพื่อกำจัด ความจำเป็น ของ dependency อีกตัว มัน integrate job queueing เข้ากับ database ของแอปพลิเคชัน คุณจึงไม่ต้องการ memory solution หรือ queueing system
Solid Queue เก็บ jobs เป็น records ในตาราง database และใช้ SQL features ที่มีประสิทธิภาพจัดการ job queue มันรันได้ทั้งแบบ embedded ใน Rails web process (as a Puma plugin สำหรับ single-server setups) หรือใน worker processes แยก
ตามที่สมาชิกทีมแกน Rails กล่าว เป้าหมายคือให้นักพัฒนา "ติดตั้ง Rails ตั้งค่าฐานข้อมูล และมี background job processing ทันทีโดยไม่ต้องจัดการ gems 7 ตัวและระบบอื่นๆ"
Solid Cable ช่วยให้คุณทำ web sockets ได้ (令人惊讶 ไม่ต้อง Redis)
ชิ้นที่สามของปริศนา "No-Redis-needed" ของ Rails 8 คือ Solid Cable — Action Cable adapter ใหม่ที่ ใช่แล้ว ใช้ database ด้วย ทางประวัติ Action Cable ต้องการ Redis server เพื่อ broadcast messages ระหว่าง Rails processes หลายตัว ด้วย Solid Cable คุณสามารถใช้ Action Cable สำหรับ real-time WebSocket functionality ปลดล็อก live updates สำหรับฟีเจอร์แอปอย่าง chat และ notifications — โดยไม่ต้องรัน additional services
หวังว่าประโยชน์ของ "Solid" trifecta จะชัดเจนขึ้นแล้ว คุณสามารถ cache ข้อมูลระยะยาว ประมวลผล background jobs ปริมาณสูง และ deploy real-time features โดยไม่ต้องยืน Redis server หรือ pub/sub service อื่นๆ ฟีเจอร์เหล่านี้ร่วมกันลดความซับซ้อนสำหรับแอปเล็ก (คุณรันทุกอย่างบน single host กับ database เดียว) และเข้ากับปรัชญา Rails 8 ในการทำให้ deployment ง่ายขึ้น
การลดความจำเป็นของ Redis ใหญ่แค่ไหน?
หลังเห็นว่า Rails 8 หลายส่วนเกี่ยวกับการลบ dependency บน Redis คุณอาจสงสัยว่ามันสำคัญจริงไหม คำตอบขึ้นอยู่กับ context ของคุณ แต่มีข้อได้เปรียบที่โดดเด่นบ้าง
Moving parts น้อยลง = ความซับซ้อนน้อยลง โดยเฉพาะใน deployments ทุก additional service (Redis, background job runner แยก ฯลฯ) เป็นอีกอย่างที่อาจพังหรือต้อง scale ด้วยการใช้ database สำหรับมากขึ้น คุณทำ production operations ให้เรียบง่าย ไม่ต้อง monitor Redis memory หรือ ensure Redis instance รันตลอด
นักพัฒนา Rails หลายคนเคยเจอสถานการณ์ที่ใน development ไม่รัน cache server หรือใช้ queue adapter ต่างไป แต่ใน production ใช้ Redis/Sidekiq ด้วย Rails defaults ใหม่ คุณรัน setup เดียวกันใน development และ production ได้ ลดความประหลาดใจ Stack self-contained มากขึ้น และ "just works" ตั้งแต่ติดตั้งโดยไม่ต้อง config 特別 สำหรับ production
เซิร์ฟเวอร์หรือ add-ons น้อยลง = ค่า hosting ถูกกว่า แม้ใน large scale การรวม infrastructure ก็มาพร้อม cost efficiency บ้าง พื้นที่ database ถูกกว่า memory!
Rails ไม่ป้องกันคุณจากการใช้ Redis หรือ services อื่น มันแค่ทำให้พวกมัน optional คุณเริ่มกับ built-in Solid adapters และถ้าจำเป็น คุณนำ Redis หรือโซลูชันอื่นๆ มาต่อได้ภายหลัง
SQLite กำจัดความจำเป็นของ database process
การเปลี่ยนแปลงที่มีความหมายอีกอย่างใน Rails 8 คือการ embrace SQLite เป็น production database ที่ใช้ได้ enabled โดยการปรับปรุงมากมายของ Rails SQLite adapter ถ้าแอปของคุณใช้ SQLite ใน production ได้ คุณไม่ต้องมี database server แยกตัวรัน แทนที่จะเป็นแค่ไฟล์บนดิสก์ที่ถูกจัดการโดย app process เอง การปรับปรุง SQLite ของ Rails 8 ทำให้เรื่องนี้เป็นจริงได้มากกว่าเดิม
SQLite ทำให้ deployment ง่ายขึ้นมาก ไม่ต้อง install หรือ manage MySQL หรือ Postgres บนเซิร์ฟเวอร์ หรือใช้ (และจ่ายเงิน!) managed DB service มันแค่ไฟล์ที่ Rails app อ่านและเขียน
ถ้าคุณ outgrow SQLite คุณย้ายไป fully-featured database system ภายหลังได้ ทีมแกน Rails แค่เปลี่ยน default เป็น lightweight option — ซึ่งเข้ากับ narrative "No PaaS" ได้ดี
Kamal 2 ช่วยให้คุณ deploy
Rails 8 ทำให้ การรัน แอปใน production ง่ายขึ้น — แต่การนำแอป ไป production ล่ะ? Kamal 2 พยายามตอบคำถามนี้
Kamal เป็น orchestration tool ที่ deploy แอปของคุณ (ผ่าน Docker container) ไปที่ Linux server ใดๆ ด้วยความยุ่งยากน้อยที่สุด มัน automate การ build app image, push และ run บนเซิร์ฟเวอร์โดยคุณไม่ต้อง handcraft server setup ทั้งหมด
ด้วยการ config บ้างและคำสั่งเดียว (kamal setup) Kamal จะนำ Linux box ใหม่ๆ ไป provision ให้พร้อมรัน Docker container ของคุณ
หลังจากนั้น deployment ง่ายเท่าการรัน kamal deploy ซึ่ง pull latest image และ swap container เก่าด้วยใหม่เป็น zero-downtime deployment
Kamal 2 หวังให้คุณได้ PaaS-like deployment experience บน Linux host ใดๆ คุณทำให้เซิร์ฟเวอร์ใดก็ตามกลายเป็น Rails server รันแอปของคุณด้วยคำสั่งเดียว Initial config อาจเจ็บปวด แต่ deploys ต่อไปง่ายขึ้นมาก เป็นก้าวใหญ่สู่การทำให้ self-hosting สะดวกเท่า push ไป platform อย่าง Heroku
"No PaaS" เป็นไอเดียดีไหม?
Rails 8 จริงๆ ทำให้ platforms เป็นอดีตไหม? และทีมเล็กถึงกลาง真的ประหยัดเงินได้จาก self-hosting ไหม?
ผมเพิ่ง deploy hobby project บน VPS ด้วย Kamal และมันประสบการณ์ที่ frustrating แม้ deployments จะ seamless หลังได้มันทำงาน setup ไกลจากมัน และงานของผมเยอะมากถ้าต้อง scale โปรเจคนี้
ดังนั้นสำหรับผม คำตอบคือ ไม่ — Rails 8 ไม่ได้ลบ value proposition ของ platforms ผมชอบโฟกัสที่แอปและให้ platform อย่าง Heroku จัดการ infrastructure
นักพัฒนาสолоและทีมเล็กได้ประโยชน์มากกว่าจากการโฟกัสที่ผู้ใช้ แทนที่จะไล่ economies of scale ทำไมไม่ outsourcing hosting, deployments และ scaling ให้ platform ที่เก่งในเรื่องเหล่านี้ และโฟกัสสร้างผลิตภัณฑ์ที่ลูกค้ารัก?
แน่นอน เมื่อทีมและแอปพลิเคชันโตขึ้น คุณอาจรู้สึกว่าราคา platform ไม่คุ้ม ณ จุดหนึ่ง จะมีเวลาและ/หรือคน dedicated ให้ SRE และ ops responsibilities และ Kamal (รวมฟีเจอร์ Rails 8 อื่นๆ ที่เก๋ๆ) เป็นก้าวใหญ่สู่การทำให้เรื่องนั้นง่ายขึ้น
รวมทั้งหมดเข้าด้วยกัน
Rails 8 บีบช่องว่างระหว่าง self-hosting และใช้ platform แต่ไม่ปิดมันพอที่จะ claim "No PaaS required" อย่างซื่อสัตย์ ชัดเจนว่า Rails 8 ทำให้เลือก VPS แทน PaaS ง่ายขึ้นโดยไม่犠牲 developer experience มากนัก ผมแค่ไม่คิดว่ามัน platform killer
Solid Cache, Solid Queue และ Solid Cable นำ requirements ของ third-party สำหรับเว็บแอปมาสู่ first-party support และผมขอบคุณมาก มันเก๋ที่มี defaults ที่ lightweight แต่ powerful ให้แอปพลิเคชันลอยตัว และดีกว่านั้น ไม่ต้องการ infrastructure มาก ถ้าคุณเลือก self-host Kamal ช่วยลดภาระ deployments ให้คุณ
ไม่ว่าคุณจะใช้ platform หรือไม่ monitoring จำเป็นสำหรับการตอบสนองเร็วต่อ errors และ outages และให้ user experience ดีแก่ลูกค้า สมัคร Honeybadger เพื่อได้ real-time insights เกี่ยวกับ health และ performance ของ Rails application ของคุณ
