রেলস ৮ একটি বোল্ড প্রিমাইসের সাথে এসেছে: "No PaaS Required।" ক্লাউড প্ল্যাটফর্মগুলো যেহেতু дорবার হয়ে উঠছে, রুবি অন রেলস এক্সটার্নাল ইনফ্রাস্ট্রাকচার ডিপেন্ডেন্সি কমানোর দিকে যাচ্ছে যাতে ডেভেলপাররা কম সার্ভিস ডিপেন্ডেন্সি দিয়ে অ্যাপ্লিকেশন ডিপ্লয় এবং রান করতে পারে।
পরম্পরাগতভাবে, একটি রেলস অ্যাপ ইন্টারনেটে ডিপ্লয় করার মানে হচ্ছে একটি ডাটাবেস সার্ভার (যেমন PostgreSQL) এবং রেডিস-এর মতো অতিরিক্ত সার্ভিস প্রোভিশন করা ক্যাশিং, ব্যাকগ্রাউন্ড জব, বা WebSocket-এর জন্য। রেলস ৮-এ, কোর টিম এটাকে পরিবর্তন করতে চায় ক্যাশিং, জব কিউ, এবং রিয়েল-টাইম WebSocket-এর জন্য বিল্ট-ইন সমাধান দিয়ে - সবই আপনার অ্যাপ্লিকেশন ডাটাবেস দ্বারা চালিত।
এই আর্টিকেলে, আমরা খুঁজে বের করব রেলস ৮ কীভাবে "No PaaS Required" প্রতিশ্রুতিটি পুরা করছে, "Solid Trifecta"-র একটি ওভারভিউ দিয়ে শুরু করে।
Solid Cache: রেডিস ছাড়া ক্যাশিং
রেলস ৮-এ আমার প্রিয় অডিশনগুলোতে একটি হলো Solid Cache, একটি নতুন ক্যাশ স্টোর যা রেডিস বা Memcached-এর প্রয়োজনিয়ত প্রতিস্থাপন করে। Solid Cache ক্যাশড ডেটা পা arsen করার জন্য ইন-মেমরি কি-ভ্যালু স্টোরের বদলে ডাটাবেস ব্যবহার করে। ডিস্কে ক্যাশড অবজেক্ট স্টোর করা টেকনিক্যালি র্যামের চেয়ে স্লো, কিন্তু কিছু উল্লেখযোগ্য সুবিধা আছে।
প্রথমে, ডিস্ক স্টোরেজ আপনাকে বেশি স্পেস এবং মেমরির চেয়ে অনেক সস্তা দেয়। Solid Cache-এ, আপনি খুব বেশি ডেটা (এবং বেশি সময় ধরে) ক্যাশ করতে পারবেন র্যাম খালি না হওয়া পর্যন্ত। ৩৭সিগন্যালস (Basecamp এবং HEY-এর পেছনে কোম্পানি) রেডিস থেকে Solid Cache-এ স্যুইচ করলে তাদের ক্যাশ ১০+ টেরাবাইট ডেটা পর্যন্ত বাড়াতে পেরেছে, যা অবশেষে তাদের P95 রেন্ডার টাইম ৫০% কমিয়ে দিয়েছে।
হ্যাঁ, মেমরি থেকে পড়া ডিস্ক থেকে পড়ার চেয়ে দ্রুত। অনেক কেসে (Basecamp-এর ব্যবহারের মত), আরও বেশি ডেটা ক্যাশ করার ট্রেড-অফ এই স্পিড হিটের ارزش রেখে।
ডিফল্টরূপে, রেলস ৮ Solid Cache ব্যবহার করে (SQLite ব্যাকড)। অবশ্যই, রেলস কনভেনশনের মত, আপনি অন্য অপশন মনে করলে রেডিস ব্যবহার করতে পারেন। কিন্তু এই ডিফল্ট মেনে চললে আপনি রেডিসের মত আরেকটি প্রোডাকশন সার্ভিস সাপোর্ট ছাড়া ক্যাশিং করতে পারবেন, যা আপনার ইনফ্রাস্ট্রাকচার বোঝা সহজ করে দেয়।
Solid Queue: রেডিস ছাড়া ব্যাকগ্রাউন্ড জব
"Solid" ট্রাইফেক্টার আমার دوم প্রিয় অংশ হলো Solid Queue, একটি নতুন Active Job ব্যাকএন্ড যা রেডিস বা Sidekiq-এর মত আলাদা জব সিস্টেম ডিপেন্ডেন্সি ছাড়া ব্যাকগ্রাউন্ড জব প্রসেসিং হ্যান্ডেল করে।
অনেক রেলস ডেভেলপার Sidekiq (যেটি রেডিসের ওপর নির্ভরশীল) বা Delayed Job জেম ব্যবহার করে ব্যাকগ্রাউন্ড জবের জন্য। Solid Queue হলো রেলসের আরেকটি ডিপেন্ডেন্সির প্রয়োজনিয়ত দূর করার চেষ্টা। এটি আপনার অ্যাপ্লিকেশনের ডাটাবেসে জব কিউইং ইন্টিগ্রেট করে, যাতে আপনাকে মেমরি সমাধান বা কিউইং সিস্টেম দরকার নয়।
Solid Queue জবগুলো ডাটাবেস টেবিলে রেকর্ড হিসেবে স্টোর করে এবং কার্যকর SQL ফিচার ব্যবহার করে জব কিউ ম্যানেজ করে। এটি রেলস ওয়েব প্রসেসে এম্বেডেড (সিঙ্গেল-সার্ভার সেটআপের জন্য Puma প্লাগইন হিসেবে) বা আলাদা ওয়ার্কার প্রসেসে চলে।
রেলস কোর টিমের একজন সদস্য বলেছেন, লক্ষ্য ছিল একটি ডেভেলপারকে "রেলস ইনস্টল করুন, একটি ডাটাবেস সেট আপ করুন, এবং বক্সের বাইরে থেকে সাতটি ভিন্ন জেম এবং অন্যান্য সিস্টেম ম্যানেজ না করে ব্যাকগ্রাউন্ড জব প্রসেসিং পান।"
Solid Cable: রেডিস ছাড়া ওয়েব সকেট
রেলস ৮-এর "No-Redis-needed" পাজলটির তৃতীয় অংশ হলো Solid Cable — একটি নতুন Action Cable অ্যাডাপ্টার যা, আপনি حدস করেছেন, ডাটাবেস ব্যবহার করে। ঐতিহাসিকভাবে, Action Cable-এর জন্য একটি রেডিস সার্ভার দরকার হতো একাধিক রেলস প্রসেসের মাঝপথে মেসেজ ব্রডকাস্ট করার জন্য। Solid Cable-এ, আপনি রেডিস ছাড়া Action Cable ব্যবহার করে রিয়েল-টাইম WebSocket ফাংশনালিটি লিভারেজ করতে পারেন, চ্যাট এবং নোটিফিকেশন-जैसे অ্যাপ্লিকেশন ফিচারের জন্য লাইভ আপডেট আনলক করে - বিনা অতিরিক্ত সার্ভিস চালানো।
আশা করি "Solid" ট্রাইফেক্টার সুবিধা এখন স্পষ্ট হয়ে গেছে। আপনি লং-টার্ম ডেটা ক্যাশ করতে পারেন, হাই-থ্রুপুট ব্যাকগ্রাউন্ড জব প্রসেস করতে পারেন, এবং রিয়েল-টাইম ফিচার ডিপ্লয় করতে পারেন - রেডিস সার্ভার বা অন্যান্য pub/sub সার্ভিস খড়া না করে। একসাথে, এই ফিচারগুলো ছোট অ্যাপের জন্য কমপ্লেক্সিটি কমিয়ে দেয় (আপনি সবকিছু একটি হোস্টে একটি ডাটাবেস দিয়ে রান করতে পারেন) এবং রেলস ৮-এর ফিলোসফি ডিপ্লয়মেন্ট সহজ করার সাথে মিলে যায়।
রেডিসের প্রয়োজনিয়ত সরানো কি বড় ব্যাপার?
রেলস ৮ এর কতটুকু রেডিসের ডিপেন্ডেন্সি সরানোর উপর নির্ভর করে দেখার পর, আপনি জানতে চাইতে পারেন এটা আসলে কতটুকু মাটার করে। উত্তর আপনার কন্টেক্সটের ওপর নির্ভর করে, কিন্তু কিছু উল্লেখযোগ্য সুবিধা নিশ্চিত।
কম mouvинг পার্টস মানে ডিপ্লয়মেন্টে কম কমপ্লেক্সিটি। প্রতিটি অতিরিক্ত সার্ভিস (রেডিস, আলাদা ব্যাকগ্রাউন্ড জব রানার, ইত্যাদি) আরেকটি জিনিস যা ভাঙতে পারে বা স্কেলিং দরকার। ডাটাবেসকে বেশি কাজে লাগিয়ে, আপনি আপনার প্রোডাকশন অপারেশন সহজ করে তোলেন। আপনাকে রেডিস মেমরি মনিটর করতে হবে না বা নিশ্চিত করতে হবে না যে রেডিস ইনস্ট্যান্স সবসময় রান করছে।
অনেক রেলস ডেভেলপার এই পরিস্থিতি সম্মুখীন हुएँ: ডেভেলপমেন্টে, আপনি ক্যাশ সার্ভার চালান না বা ভিন্ন কিউ অ্যাডাপ্টার ব্যবহার করুন, কিন্তু প্রোডাকশনে রেডিস/Sidekiq ব্যবহার করুন। নতুন রেলস ডিফল্টের সাথে, আপনি ডেভেলপমেন্ট এবং প্রোডাকশনে একই সেটআপ চালাতে পারেন, সারপ্রাইজ কমিয়ে দিয়ে। স্ট্যাকটি আরও সেলফ-কনটেইনড এবং "জাস্ট ওয়ার্কস" আউট অফ দ্য বক্স স্পেশ্যাল কনফিগারেশন ছাড়া প্রোডাকশনের জন্য।
কম সার্ভার বা অ্যাড-অন মানে সস্তা হোস্টিং বিল। বড় স্কেলেও, ইনফ্রাস্ট্রাকচার কনসোলিডেট করার সাথে কিছু কাস্ট এফিশিয়েন্সি আসে। ডাটাবেস স্পেস মেমরির চেয়ে সস্তা!
রেলস আপনাকে রেডিস বা অন্যান্য সার্ভিস ব্যবহার করতে বাধা দেয় না। এটা সেগুলোকে শুধু অপশনাল করে দেয়। আপনি বিল্ট-ইন Solid অ্যাডাপ্টার দিয়ে শুরু করতে পারেন, এবং প্রয়োজনে পরে রেডিস বা অন্যান্য সমাধান আনার পারেন।
SQLite ডাটাবেস প্রসেসের প্রয়োজনিয়ত সরিয়ে দেয়
রেলস ৮-এ আরেকটি অর্থবহ পরিবর্তন হলো SQLite-কে প্রোডাকশন ডাটাবেস হিসেবে গ্রহণ করা, যা রেলসের SQLite অ্যাডাপ্টারে অনেক উন্নতির মাধ্যমে সম্ভব হয়েছে। যদি আপনার অ্যাপ প্রোডাকশনে SQLite ব্যবহার করতে পারে, তবে আপনাকে আলাদা একটি ডাটাবেস সার্ভার চালাতে হবে না। বরং, আপনার ডেটা একটি সিম্পল ফাইলে ডিস্কে থাকে যা অ্যাপ প্রসেস নিজেই ম্যানেজ করে। রেলস ৮-এর SQLite-এ উন্নতিগুলো এটাকে আগের চেয়ে বেশি বাস্তবসম্মত করে দিয়েছে।
SQLite ডিপ্লয়মেন্ট অনেক সহজ করে দেয়। আপনাকে সার্ভারে MySQL বা Postgres ইনস্টল বা ম্যানেজ করতে হবে না বা (এবং টাকা দিয়ে!) ম্যানেজড DB সার্ভিস ব্যবহার করতে হবে না। এটা শুধু একটি ফাইল যা রেলস অ্যাপ পড়ে এবং লিখে।
আপনি যদি SQLite-এর চেয়ে বড় হয়ে যান, তবে অবশ্যই পরে পূর্ণাঙ্গ ডাটাবেস সিস্টেমে মাইগ্রেট করতে পারেন। রেলস কোর টিম শুধু ডিফল্টকে একটি লাইটওয়েট অপশনে পরিবর্তন করেছে - যা "No PaaS" Нарেটিভের সাথে খুব ভালো ফিট করে।
Kamal ২ ডিপ্লয়মেন্টে সাহায্য করে
রেলস ৮ অ্যাপ প্রোডাকশনে রান করা সহজ করে দিচ্ছে - কিন্তু অ্যাপকে প্রোডাকশনে পৌঁছানো কী? Kamal ২ রিলিজ সেই প্রশ্নের উত্তর দিতে চেয়েছে।
Kamal একটি অর্কেস্ট্রেশন টুল যা আপনার অ্যাপকে (Docker কন্টেইনার ভায়া) যেকোনো লিনাক্স সার্ভারে ডিপ্লয় করে ন্যূনতম ঝামেলায়। এটি আপনার অ্যাপের ইমেজ বিল্ড করা, পুশ করা, এবং সার্ভারে রান করা অটোমেট করে - আপনাকে হাতে সার্ভার সেটআপ করতে হবে না।
কিছু কনফিগারেশন এবং এক কমান্ড (kamal setup) দিয়ে, Kamal একটি ফ্রেশ লিনাক্স বক্স নেবে এবং আপনার Docker কন্টেইনার চালানোর জন্য যা লাগবে সেটা দিয়ে প্রোভিশন করবে।
এরপর, ডিপ্লয়মেন্ট খুব সহজ - শুধু kamal deploy রান করলে, যা লেটেস্ট ইমেজ পুল করে এবং পুরনো কন্টেইনারকে নতুন একটি দিয়ে স্মুথলি রিপ্লেস করে সিরো-ডাউনটাইম ডিপ্লয়মেন্ট হিসেবে।
Kamal ২ আপনাকে যেকোনো লিনাক্স হোস্টে PaaS-মত ডিপ্লয়মেন্ট অভিজ্ঞতা দিতে চায়। আপনি যেকোনো সার্ভারকে এক কমান্ড দিয়ে আপনার অ্যাপ চালানো একটি রেলস সার্ভারে রূপান্তরিত করতে পারেন। ইনিশিয়াল কনফিগারেশন একটু কষ্টদায়ক হতে পারে, তবে পরবর্তী ডিপ্লয়মেন্টগুলো অনেক সহজ। এটি সেলফ-হোস্টিংকে Heroku-এর মত প্ল্যাটফর্মে পুশ করার মত সুবিধাজনক করার দিকে একটি বড় ধাপ।
"No PaaS" কি ভালো আইডিয়া?
কি রেলস ৮ সত্যিই প্ল্যাটফর্মকে অতীতের কथा করে দিচ্ছে? এবং কি ছোট থেকে মাঝারি আকারের টিমরা সেলফ-হোস্টিং দিয়ে টাকা বাঁচাতে পারেন?
আমি gầnে একটি হবি প্রজেক্ট Kamal দিয়ে VPS-এ ডিপ্লয় করেছি, এবং অভিজ্ঞতা বিভ্রান্তিকর ছিল। ডিপ্লয়মেন্টগুলো কাজ করার পরে relatibely seamless, কিন্তু সেটআপ সেটা দূরে ছিল, এবং আমার কাজ বাকি আছে যদি কখনো এই প্রজেক্ট স্কেল করতে হয়।
তো, আমার জন্য উত্তর না — রেলস ৮ প্ল্যাটফর্মের ভ্যালু প্রপজিশন সরিয়ে দিচ্ছে না। আমি চাই আমার অ্যাপে ফোকাস করি এবং Heroku-এর মত প্ল্যাটফর্ম ইনফ্রাস্ট্রাকচার হ্যান্ডেল করুক।
সোলো ডেভেলপার এবং ছোট টিমরা তাদের ইউজাররূপে ফোকাস করার থেকে বেশি বেনিফিট পাবে বরং ইকোনমি অফ স্কেল पीछা করার থেকে। কেন হোস্টিং, ডিপ্লয়মেন্ট, এবং স্কেলিং আউটসোর্স করবেন না এমন একটি প্ল্যাটফর্মে যেটা এই এলাকায় চমৎকার কাজ করে এবং আপনার প্রিয় গ্রাহকদের পছন্দ এমন একটি প্রোডাক্ট বানাতে ফোকাস করবেন?
অবশ্যই, আপনার টিম এবং অ্যাপ্লিকেশন বড় হলে, আপনি প্ল্যাটফর্মের প্রাইসিং কম আকর্ষণীয় পেতে পারেন। 어느 পয়েন্টে, SRE এবং অপ্স দায়িত্বের জন্য ডেডিকেটেড টাইম এবং/অথবা লোক থাকা মেনে আসে, এবং Kamal (অন্যান্য অসাধারণ রেলস ৮ ডিফল্টসহ) এটাকে অনেক সহজ করার দিকে একটি বড় ধাপ।
সবকিছু একসাথে আনা
রেলস ৮ সেলফ-হোস্টিং এবং প্ল্যাটফর্ম ব্যবহার করার মাঝপথের গ্যাপ ছোট করে দিয়েছে, কিন্তু এটি "No PaaS required" দাবি করার জন্য যথেষ্ট ক্লোজ করিনি। স্পষ্ট হলো, যাই হোক, রেলস ৮ VPS-কে প্ল্যাটফর্মের বদলে বেছে নেওয়া সহজ করে দিয়েছে বিনা অনেক ডেভেলপার এক্সপেরিয়েন্স ফরফিয়ে করায়; আমি শুধু মনে করি এটি প্ল্যাটফর্ম কিলার নয়।
Solid Cache, Solid Queue, এবং Solid Cable সবই পূর্বে থার্ড-পার্টি রিকোয়্যারমেন্টগুলো ফার্স্ট-পার্টি সাপোর্টে আনেছে, এবং আমি সেটার জন্য কৃতজ্ঞ। লাইটওয়েট কিন্তু পাওয়ারফুল ডিফল্ট থাকা رائع যা অ্যাপ্লিকেশন চালু করতে সাহায্য করে, এবং আরও ভালো, এগুলো অনেক ইনফ্রাস্ট্রাকচার দরকার করে না। আপনি যদি সেলফ-হোস্ট বেছে নেন, তবে Kamal আপনার ডিপ্লয়মেন্টের কিছু বোঝা কমাতে পারে।
আপনি প্ল্যাটফর্ম ব্যবহার করেন বা না করেন, মনিটরিং অপরিহার্য দ্রুত এরর এবং আউটেজ রেসপন্সের জন্য এবং আপনার কাস্টমারদের দুর্দান্ত ইউজার এক্সপেরিয়েন্স দিতে। Honeybadger-এ সাইন আপ করুন আপনার রেলস অ্যাপ্লিকেশনের স্বাস্থ্য এবং পারফরম্যান্সে রিয়েল-টাইম ইনসাইট পেতে।
