𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝘃𝘀. 𝗠𝗼𝗻𝗼𝗹𝗶𝘁𝗵𝗶𝗰 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲: 𝗪𝗵𝗮𝘁 𝗦𝗵𝗼𝘂𝗹𝗱 𝗬𝗼𝘂 𝗕𝘂𝗶𝗹𝗱?
একজন ফাউন্ডার একবার আমাকে একটি আর্কিটেকচার পিচ রিভিউ করতে বলেছিলেন।
এজেন্সিটি এগারোটি সার্ভিস, একটি মেসেজ কিউ (message queue) এবং একটি সার্ভিস মেশ (service mesh) প্রস্তাব করেছিল। এটি ছিল কোনো ইউজার নেই এমন একটি সাধারণ বুকিং টুলের জন্য।
এটি একটি ফাঁদ।
আর্কিটেকচারের সিদ্ধান্তগুলো আপনার হোস্টিং বিল, শিপিং স্পিড এবং নিয়োগ পরিকল্পনা নির্ধারণ করে দেয়। একজন ডেভেলপারকে বাজেট দেওয়ার আগে আপনাকে অবশ্যই এর খরচ সম্পর্কে জানতে হবে।
মনোলিথ (The Monolith) একটি মনোলিথ একটি কোডবেস, একটি ডিপ্লয়মেন্ট এবং একটি ডাটাবেস ব্যবহার করে। এটি সহজ।
প্রথম দিনেই আপনি আপনার ডোমেইন বাউন্ডারিগুলো (domain boundaries) সম্পর্কে জানেন না। আপনি যদি খুব দ্রুত সার্ভিসগুলো আলাদা করে ফেলেন, তবে আপনাকে এমন সব দেয়াল সরাতে সময় ব্যয় করতে হবে যা থাকার কথা ছিল না। আপনার টিম ছোট হলে মনোলিথ পরিচালনা করা সহজ। এখানে একটি API সেটআপ করার পরিবর্তে আপনি সরাসরি একটি ফাংশন কল করতে পারেন। রাত ২টায় যখন কোনো বাগ (bug) দেখা দেয়, তখন ত্রুটিটি সরাসরি কোডকে নির্দেশ করে, কোনো নেটওয়ার্ক ফেইলিউরের দিকে নয়।
মাইক্রোসার্ভিসেস (Microservices) মাইক্রোসার্ভিসেস সাংগঠনিক সমস্যা সমাধান করে। এগুলো বিভিন্ন টিমকে তাদের নিজস্ব সময়সূচী অনুযায়ী কোড শিপ করতে সাহায্য করে। নেটফ্লিক্স (Netflix) এটি ব্যবহার করে যাতে একটি ত্রুটি পুরো সিস্টেমকে অচল করে না দেয়।
তবে, এর জন্য আপনাকে প্রতিদিন মূল্য দিতে হয়। নেটওয়ার্ক কল ল্যাটেন্সি (latency) বাড়িয়ে দেয়। ডেটা কনসিস্টেন্সি (data consistency) বজায় রাখা কঠিন হয়ে পড়ে। লগ এবং ট্রেসিং (tracing) ম্যানেজ করার জন্য আপনার বিশেষায়িত টুলস এবং একটি বড় টিমের প্রয়োজন হয়। সঠিক জনবল না থাকলে, আপনি শেষ পর্যন্ত একটি 'ডিস্ট্রিবিউটেড মনোলিথ' (distributed monolith)-এর মুখোমুখি হবেন। এটি আপনাকে নেটওয়ার্কের সমস্ত জটিলতা দেবে কিন্তু কোনো স্বাধীনতা দেবে না।
মডুলার মনোলিথ (The Modular Monolith) এটি হলো মধ্যপন্থা। এটি একটি অ্যাপ যেখানে কোডের বিভিন্ন অংশের মধ্যে সুনির্দিষ্ট দেয়াল বা সীমানা থাকে। যেমন, বিলিং সিস্টেম আপনার অর্ডারের মূল অংশগুলোতে (guts) হস্তক্ষেপ করতে পারবে না।
শপিফাই (Shopify) এবং গিটহাব (GitHub) এই পদ্ধতি ব্যবহার করে। এতে আপনি পরিষ্কার বাউন্ডারি পান এবং নেটওয়ার্ক ট্যাক্স (network tax) এড়াতে পারেন। যখন আপনার অ্যাপের কোনো একটি অংশ আলাদাভাবে স্কেল করার প্রয়োজন হয়, তখন আপনি সহজেই এটিকে আলাদা করতে পারেন কারণ এর সীমানাগুলো আগে থেকেই নির্ধারিত থাকে।
কীভাবে সিদ্ধান্ত নেবেন:
- টিমের আকার: আপনার যদি মাত্র তিনজন সদস্য থাকে, তবে আপনি আলাদা সার্ভিস এবং প্রয়োজনীয় অন-কল রোটেশন (on-call rotation) সামলাতে পারবেন না।
- প্রোডাক্টের স্থায়িত্ব: আপনার প্রোডাক্ট যদি প্রতি সপ্তাহে পরিবর্তিত হয়, তবে আগামী মাসের মধ্যেই আপনার সার্ভিস বাউন্ডারিগুলো ভুল প্রমাণিত হবে।
- অপারেশনস: আপনার কি অটোমেটেড রোলব্যাক (automated rollbacks) এবং লগ অ্যাগ্রিগেশন (log aggregation) ব্যবস্থা আছে? যদি না থাকে, তবে মাইক্রোসার্ভিসেস আপনার জন্য সমস্যা তৈরি করবে।
- স্কেল: কাল্পনিক প্রবৃদ্ধির কথা ভেবে কিছু তৈরি করবেন না। আপনি বর্তমানে যে বাস্তব পথটি দেখতে পাচ্ছেন, তার জন্য তৈরি করুন।
যদি আপনার উত্তর হয় "এখনো না," তবে একটি মডুলার মনোলিথ তৈরি করুন।
শুধু শব্দটি আধুনিক শোনায় বলে মাইক্রোসার্ভিসেস চাইবেন না। আপনার পার্টনারকে বলুন প্রোডাক্টটি আসলে কী কাজ করে এবং কে এটি রক্ষণাবেক্ষণ করবে।
পণ্যগুলো ব্যর্থ হয়ে যায় কারণ সেগুলো কখনোই রিলিজ করা হয় না। একটি পরিচ্ছন্ন মনোলিথ (monolith) হলো ব্যবহারকারীদের কাছে পৌঁছানোর দ্রুততম উপায়। প্রথমে সেটিই তৈরি করুন। আপনার ট্রাফিকই আপনাকে জানিয়ে দেবে কখন বিষয়গুলোকে আলাদা করার সময় এসেছে।
ঐচ্ছিক লার্নিং কমিউনিটি: https://t.me/GyaanSetuAi