1. ভূমিকা ও সারসংক্ষেপ
এই বিষয়বস্তু সফটওয়্যার ইঞ্জিনিয়ারিং রেডিও পডকাস্টের (পর্ব ২১৩) একটি আলোচনা থেকে নেওয়া হয়েছে, যেখানে জোহানেস থোনেস ও জেমস লুইস মাইক্রোসার্ভিস বিষয়ে আলোচনা করেছেন। ২০১৫ সালের শুরুতে বৃহৎ, একক (মনোলিথিক) অ্যাপ্লিকেশন রক্ষণাবেক্ষণের চ্যালেঞ্জের প্রতিক্রিয়া হিসেবে জনপ্রিয়তা অর্জনকারী এই স্থাপত্য শৈলীর সংজ্ঞা, প্রেরণা ও ব্যবহারিক বিবেচনা নিয়ে এই কথোপকথন অনুসন্ধান করে।
2. মাইক্রোসার্ভিসের সংজ্ঞা
একটি মাইক্রোসার্ভিসকে একটি ছোট, কেন্দ্রীভূত অ্যাপ্লিকেশন উপাদান হিসেবে ধারণা করা হয়।
2.1 মূল বৈশিষ্ট্যসমূহ
আলোচনা অনুযায়ী, একটি মাইক্রোসার্ভিসের বেশ কয়েকটি মূল বৈশিষ্ট্য রয়েছে:
- স্বাধীন স্থাপনা: অন্যান্য সার্ভিসে পরিবর্তন না করেই স্থাপন করা যায়।
- স্বাধীন স্কেলিং: এর নির্দিষ্ট লোডের ভিত্তিতে অনুভূমিক বা উল্লম্বভাবে স্কেল করা যায়।
- স্বাধীন পরীক্ষণ: বিচ্ছিন্নভাবে বৈধতা যাচাই করা যায়।
- একক দায়িত্ব: পরিবর্তন বা প্রতিস্থাপনের একটি প্রধান কারণ থাকে। এটি একটি সুসংহত কাজ সম্পাদন করে এবং সহজে বোঝা যায়।
2.2 একক দায়িত্বের উদাহরণ
একটি মাইক্রোসার্ভিস যে "একটি কাজ" করে তা কার্যকরী বা আন্তঃকার্যকরী (অকার্যকরী) হতে পারে:
- কার্যকরী: একটি নির্দিষ্ট ডোমেইন সম্পদ পরিবেশন করা (যেমন, একটি ব্যবহারকারী সার্ভিস, একটি নিবন্ধ সার্ভিস, বীমাতে ঝুঁকি গণনার সার্ভিস)।
- আন্তঃকার্যকরী: একটি সারি প্রসেসর যা একটি বার্তা পড়ে, ব্যবসায়িক যুক্তি প্রয়োগ করে এবং এগিয়ে দেয়। ক্যাশিং বা লগিংয়ের মতো একটি নির্দিষ্ট অকার্যকরী চাহিদার জন্য দায়িত্ব।
3. মাইক্রোসার্ভিসের উত্থান
3.1 জনপ্রিয়তার কারণ
মাইক্রোসার্ভিসের জনপ্রিয়তার কারণ একটি ব্যাপক শিল্পের বেদনাদায়ক বিষয়: নিয়ন্ত্রণযোগ্য নয় এমন একক (মনোলিথিক) অ্যাপ্লিকেশন। প্রতিষ্ঠানগুলো এমন অ্যাপ্লিকেশনের মুখোমুখি হয় যা ৫-১০ বছরে বিকশিত হয়ে পরিবর্তন, SaaS হিসেবে স্থাপন বা ক্লাউডে কার্যকরভাবে স্কেল করা খুব কঠিন হয়ে পড়েছে।
3.2 প্রযুক্তিগত ঋণ মোকাবেলা
মাইক্রোসার্ভিস এই মনোলিথগুলিকে ছোট, সহযোগী উপাদানে বিভক্ত করার একটি সমাধান হিসেবে আবির্ভূত হয়েছে যা প্রক্রিয়ার বাইরে চলে। নেটফ্লিক্সের মতো কোম্পানিগুলো বৃহৎ পরিসরে প্রদর্শিত এই পদ্ধতি স্বাধীন রক্ষণাবেক্ষণ, স্কেলিং ও প্রতিস্থাপনের সুযোগ দেয়। মূল প্রেরণা হল সফটওয়্যার দ্রুত সরবরাহের প্রয়োজন এবং ক্রমাগত সরবরাহের মতো অনুশীলনের সুযোগ নেওয়া, যা মনোলিথিক স্থাপত্য দ্বারা বাধাগ্রস্ত হয়।
4. গ্রহণ ও বাস্তবায়নের নকশা
4.1 গ্রিনফিল্ড বনাম ব্রাউনফিল্ড
একটি মূল প্রশ্ন হল নতুন প্রকল্প মাইক্রোসার্ভিস দিয়ে শুরু করা (গ্রিনফিল্ড) নাকি বিদ্যমান মনোলিথকে এতে রূপান্তর করা (ব্রাউনফিল্ড)। আলোচনায় উল্লেখ করা হয়েছে যে, অভিজ্ঞতামূলকভাবে, বেশিরভাগ প্রতিষ্ঠান একটি মনোলিথ দিয়ে শুরু করে এবং পরে রূপান্তর করে, বিদ্যমান কোডবেসের মধ্যে সীমাবদ্ধ প্রসঙ্গ ও সংযোগস্থল চিহ্নিত করার চ্যালেঞ্জের মুখোমুখি হয়।
4.2 অপারেশনাল জটিলতা
পডকাস্টের অংশে উল্লেখ করা হয়েছে যে, স্থান সীমাবদ্ধতার কারণে অপারেশনাল জটিলতা এবং ডেভঅপস-এর উপর এর প্রভাব নিয়ে পূর্ণ আলোচনা করা সম্ভব হয়নি। এর অর্থ হল, মাইক্রোসার্ভিস উন্নয়ন ও স্কেলযোগ্যতার সমস্যা সমাধান করলেও, এটি পর্যবেক্ষণ, স্থাপনা সমন্বয় ও নেটওয়ার্ক নির্ভরযোগ্যতায় নতুন চ্যালেঞ্জ তৈরি করে।
5. মূল অন্তর্দৃষ্টি ও বিশ্লেষণ
মূল অন্তর্দৃষ্টি
মাইক্রোসার্ভিস কোনো জাদুর কাঠি প্রযুক্তি নয়; এগুলি মনোলিথিক উন্নয়নের বাধার প্রতি একটি সাংগঠনিক ও অর্থনৈতিক প্রতিক্রিয়া। নেটফ্লিক্সের উদাহরণ দ্বারা ইঙ্গিতিত মূল্য প্রস্তাবনা হল স্বাধীন, সমান্তরাল মূল্য সরবরাহের ধারা সক্ষম করা। এই স্থাপত্য সরাসরি সমন্বয় ব্যয় ও স্থাপনা ঘর্ষণকে লক্ষ্য করে যা একটি একক কোডবেসে কাজ করা বড় দলগুলোর জন্য সমস্যা তৈরি করে, মেলভিন কনওয়ের বচন দ্বারা যার আনুষ্ঠানিক রূপ দেওয়া হয়েছে যে "যেসব সংস্থা সিস্টেম ডিজাইন করে... তারা এমন নকশা তৈরি করতে বাধ্য হয় যা এই সংস্থাগুলোর যোগাযোগ কাঠামোর প্রতিলিপি।" মাইক্রোসার্ভিস কাঙ্ক্ষিত যোগাযোগ কাঠামো চাপিয়ে দেওয়ার জন্য সিস্টেম ডিজাইন করে এটিকে উল্টানোর চেষ্টা করে।
যুক্তিসঙ্গত প্রবাহ
বর্ণনাটি একটি আকর্ষণীয় কারণ-প্রভাব শৃঙ্খল অনুসরণ করে: (১) মনোলিথগুলি প্রযুক্তিগত ঋণ জমা করে এবং পরিবর্তন-অক্ষম হয়ে পড়ে। (২) ব্যবসা ক্লাউড স্কেলযোগ্যতা ও ক্রমাগত সরবরাহ দাবি করে। (৩) এর সংযোজনের কারণে মনোলিথিক স্থাপত্য মৌলিকভাবে এই লক্ষ্যগুলোর সাথে অসামঞ্জস্যপূর্ণ। (৪) সমাধান হল মনোলিথকে সীমাবদ্ধ প্রসঙ্গ বরাবর ভেঙে স্বাধীনভাবে স্থাপনযোগ্য ইউনিট তৈরি করা। এই যুক্তি সঠিক কিন্তু মধ্যবর্তী বিশাল জটিলতা—ভাঙার "কীভাবে"—কে উপেক্ষা করে।
শক্তি ও ত্রুটি
শক্তি: প্রধান বৈশিষ্ট্য হিসেবে স্বাধীন স্থাপনযোগ্যতা-এর উপর ফোকাস সঠিক। এটি সেই লিভার যা দলীয় স্বায়ত্তশাসন ও দ্রুত রিলিজ চক্রের তালা খোলে। কনওয়ের সূত্র ও CQRS (উল্লেখিত বাদ পড়া বিষয়) এর সাথে সংযোগ খেলতে থাকা গভীরতর সামাজিক-প্রযুক্তিগত নকশার সচেতনতা দেখায়।
ত্রুটি: ২০১৫ সালের দৃষ্টিভঙ্গি "একক দায়িত্ব" সংজ্ঞায়িত করার সহজতা সম্পর্কে লক্ষণীয়ভাবে আশাবাদী। পরবর্তী শিল্প অভিজ্ঞতা প্রকাশ করেছে যে এটি সবচেয়ে কঠিন অংশ—দুর্বলভাবে সংজ্ঞায়িত সার্ভিস সীমানার অভিশাপ যা বিতরণিত মনোলিথের দিকে নিয়ে যায়। ট্রান্সক্রিপ্টটি বিপজ্জনকভাবে অপারেশনাল ওভারহেডকেও কম গুরুত্ব দেয়। ফাউলারের মৌলিক নিবন্ধ পরে বিস্তারিত বলেছে, আপনি উন্নয়ন জটিলতার বিনিময়ে অপারেশন জটিলতা গ্রহণ করেন। ডকারকে "একটি জনপ্রিয় অংশ" হিসেবে উল্লেখ করা একটি ঐতিহাসিক স্ন্যাপশট; কন্টেইনারাইজেশন ইকোসিস্টেম ছিল সেই অনুপস্থিত অপারেশনাল সক্ষমকারী যা মাইক্রোসার্ভিসকে বৃহৎ পরিসরে ব্যবহারিকভাবে কার্যকর করে তুলেছিল।
কার্যকরী অন্তর্দৃষ্টি
নেতাদের জন্য: মাইক্রোসার্ভিস চালু করবেন না কারণ এটি ট্রেন্ডি। শুরু করুন আপনার পরিবর্তনের জন্য লিড টাইম ও স্থাপনা ফ্রিকোয়েন্সি পরিমাপ করে। যদি সেগুলো কোডবেস সমন্বয়ের কারণে খারাপ হয়, তবে মাইক্রোসার্ভিস বিবেচনা করুন। স্থপতিদের জন্য: প্রাথমিক ডিজাইন টুল একটি প্রযুক্তি চেকলিস্ট নয় বরং একটি ডোমেইন-চালিত ডিজাইন (DDD) প্রসঙ্গ মানচিত্র। প্রযুক্তিগত স্তরের ভিত্তিতে নয়, ব্যবসায়িক সক্ষমতার ভিত্তিতে সীমানা নির্ধারণ করুন। দলগুলোর জন্য: আগাম প্ল্যাটফর্ম ইঞ্জিনিয়ারিং-এ বিনিয়োগ করুন—স্বয়ংক্রিয় স্থাপনা, সার্ভিস আবিষ্কার ও পর্যবেক্ষণতা পরবর্তী চিন্তা নয়; সেগুলো ভিত্তি। প্রস্তাবিত পথ—মনোলিথ থেকে রূপান্তর—এখনও সবচেয়ে বুদ্ধিমানের কাজ। স্ট্র্যাংলার ফিগ প্যাটার্ন ব্যবহার করে মনোলিথের অংশগুলিকে ধাপে ধাপে সার্ভিস দ্বারা প্রতিস্থাপন করুন, কারণ এটি ঝুঁকি পরিচালনা করে এবং শেখার সুযোগ দেয়।
6. প্রযুক্তিগত কাঠামো ও গাণিতিক মডেল
পডকাস্টটি কথোপকথনমূলক হলেও, অন্তর্নিহিত নীতিগুলো আনুষ্ঠানিক করা যেতে পারে। একটি মূল মডেল হল দলের আকার (N), যোগাযোগ পথ এবং স্থাপত্য সংযোজনের মধ্যকার সম্পর্ক।
N সংখ্যক দল সহ একটি মনোলিথিক স্থাপত্যে, সম্ভাব্য যোগাযোগ পথ $O(N^2)$ স্কেল করে, কারণ একটি মডিউলের পরিবর্তন অনেকগুলোকে প্রভাবিত করতে পারে। এটি সমন্বয় ওভারহেড তৈরি করে। মাইক্রোসার্ভিস সীমাবদ্ধ প্রসঙ্গ ও API প্রয়োগ করে এটি কমানোর লক্ষ্য রাখে। লক্ষ্য হল ক্রস-সার্ভিস যোগাযোগের ব্যয়, $C_{comm}$, নেটওয়ার্ক কলের মাধ্যমে স্পষ্টভাবে বেশি করা, যার ফলে একটি সার্ভিসের মধ্যে শক্তিশালী মডুলারিটি উৎসাহিত হয় যেখানে পরিবর্তনের ব্যয়, $C_{internal}$, কম।
পরিবর্তন বিস্তারের সম্ভাব্যতা ($P_{prop}$) এর জন্য একটি সরলীকৃত মডেল হতে পারে:
$P_{prop} \approx \frac{C_{comm}}{C_{comm} + C_{internal}}$
যেখানে একটি সু-নকশাকৃত মাইক্রোসার্ভিস স্থাপত্য $C_{comm}$ (নেটওয়ার্ক লেটেন্সি, API ভার্সনিং) কে ক্রস-বাউন্ডারি পরিবর্তনের জন্য প্রধান ফ্যাক্টর করে $P_{prop}$ কে অসম্পর্কিত পরিবর্তনের জন্য ন্যূনতম করে।
7. পরীক্ষামূলক ফলাফল ও কেস স্টাডি
পডকাস্টটি নেটফ্লিক্সকে একটি প্রাথমিক কেস স্টাডি হিসেবে উদ্ধৃত করেছে। ২০১৫ সালের মধ্যে, নেটফ্লিক্স তার মনোলিথিক ব্যাকএন্ডকে শত শত মাইক্রোসার্ভিসে বিচ্ছিন্ন করে বিখ্যাতভাবে সক্ষম করেছে:
- স্বাধীন স্কেলিং: চলচ্চিত্র সুপারিশ বা বিলিংয়ের মতো সার্ভিসগুলি শীর্ষ লোডের সময় স্বাধীনভাবে স্কেল করতে পারে।
- দ্রুত উদ্ভাবন: দলগুলি পুরো স্ট্যাক সমন্বয় ছাড়াই তাদের সার্ভিস দিনে কয়েকবার স্থাপন করতে পারে।
- প্রযুক্তির বৈচিত্র্য: বিভিন্ন সার্ভিস তাদের কাজের জন্য সবচেয়ে উপযুক্ত ভাষায় লেখা হতে পারে (যেমন, জাভা, Node.js)।
চার্ট বর্ণনা (কল্পিত): একটি মনোলিথিক অ্যাপ্লিকেশন ও একটি মাইক্রোসার্ভিস স্থাপত্যের তুলনা করে একটি বার চার্ট দুটি অক্ষে: (১) স্থাপনা ফ্রিকোয়েন্সি (প্রতিদিন স্থাপনা): মনোলিথ একটি নিম্ন বার দেখায় (যেমন, ০.১), মাইক্রোসার্ভিস একটি উচ্চ বার দেখায় (যেমন, ৫০+)। (২) একটি ব্যর্থতা থেকে পুনরুদ্ধারের গড় সময় (MTTR): মনোলিথ একটি উচ্চ বার দেখায় (যেমন, ৪ ঘন্টা), মাইক্রোসার্ভিস একটি নিম্ন বার দেখায় (যেমন, ৩০ মিনিট), কারণ ব্যর্থতাগুলো নির্দিষ্ট সার্ভিসে বিচ্ছিন্ন করা যেতে পারে।
পরবর্তী গবেষণা, যেমন State of DevOps Reports-এ উল্লিখিত, পরিসংখ্যানগতভাবে আলগাভাবে সংযুক্ত, সার্ভিস-ভিত্তিক স্থাপত্যকে উচ্চতর সফটওয়্যার সরবরাহ কর্মক্ষমতার সাথে সম্পর্কিত করেছে।
8. বিশ্লেষণ কাঠামো: একটি ব্যবহারিক উদাহরণ
দৃশ্যকল্প: একটি ই-কমার্স মনোলিথ আপডেট নিয়ে সংগ্রাম করছে। "চেকআউট" বৈশিষ্ট্যের পরিবর্তনের জন্য পূর্ণ রিগ্রেশন টেস্টিং প্রয়োজন এবং "পণ্য ক্যাটালগ"-এর আপডেটের সাথে সংঘর্ষ হয়।
কাঠামো প্রয়োগ:
- সীমাবদ্ধ প্রসঙ্গ চিহ্নিত করুন: ডোমেইন-চালিত ডিজাইন ব্যবহার করে মূল ডোমেইন চিহ্নিত করুন: অর্ডারিং, ক্যাটালগ, ইনভেন্টরি, ব্যবহারকারী ব্যবস্থাপনা, পেমেন্ট।
- সার্ভিস সীমানা নির্ধারণ করুন: প্রতিটি প্রসঙ্গের জন্য একটি মাইক্রোসার্ভিস তৈরি করুন। অর্ডার সার্ভিস চেকআউট লজিক ও অর্ডার ডেটার মালিক।
- চুক্তি স্থাপন করুন: পরিষ্কার API নির্ধারণ করুন। অর্ডার সার্ভিস পেমেন্ট সার্ভিসের
processPayment(orderId, amount)API এবং ইনভেন্টরি সার্ভিসেরreserveStock(itemId, quantity)API কল করবে। - ডেটার মালিকানা: প্রতিটি সার্ভিস তার নিজস্ব ডাটাবেসের মালিক। অর্ডার সার্ভিসের নিজস্ব "orders" টেবিল আছে; এটি সরাসরি ইনভেন্টরি ডাটাবেস ক্যোয়ারি করে না।
- স্থাপনা ও পর্যবেক্ষণতা: প্রতিটি সার্ভিস কন্টেইনারাইজড, স্বাধীনভাবে স্থাপিত এবং একটি কেন্দ্রীয় ড্যাশবোর্ডে মেট্রিক্স (লেটেন্সি, ত্রুটি হার) প্রকাশ করে।
ফলাফল: চেকআউট দল এখন ক্যাটালগ বা ইনভেন্টরি দলকে জড়িত না করেই অর্ডার সার্ভিসে আপডেট স্থাপন করতে পারে, যা সমন্বয় ওভারহেড উল্লেখযোগ্যভাবে হ্রাস করে এবং স্থাপনা ফ্রিকোয়েন্সি বৃদ্ধি করে।
9. ভবিষ্যৎ প্রয়োগ ও গবেষণার দিক
মাইক্রোসার্ভিসের বিবর্তন ২০১৫ সালের দৃষ্টিভঙ্গির বাইরেও চলমান:
- সার্ভিস মেশ: Istio এবং Linkerd-এর মতো প্রযুক্তি আন্তঃকাটিং বিষয় (নিরাপত্তা, পর্যবেক্ষণতা, ট্র্যাফিক ব্যবস্থাপনা) অবকাঠামো স্তরে পরিচালনা করার জন্য আবির্ভূত হয়েছে, যা পৃথক সার্ভিসের উপর কোডের বোঝা হ্রাস করে।
- সার্ভারলেস ও FaaS: ফাংশন-এজ-এ-সার্ভিস (যেমন, AWS Lambda) মাইক্রোসার্ভিসের একটি চরম রূপ উপস্থাপন করে, যা অপারেশনাল জটিলতাকে সম্পূর্ণরূপে ক্লাউড প্রদানকারীর কাছে ঠেলে দেয় এবং আরও সূক্ষ্ম-দানাদার স্কেলিং সক্ষম করে।
- AI/ML সংহতকরণ: মাইক্রোসার্ভিস স্বাধীন পূর্বাভাস সার্ভিস হিসেবে ML মডেল স্থাপনের জন্য ডি ফ্যাক্টো প্যাটার্ন হয়ে উঠছে, যা A/B টেস্টিং এবং অ্যালগরিদমের দ্রুত পুনরাবৃত্তির সুযোগ দেয়।
- এজ কম্পিউটিং: IoT এবং রিয়েল-টাইম বিশ্লেষণ দৃশ্যকল্পে কম লেটেন্সি প্রক্রিয়াকরণের জন্য হালকা ওজনের মাইক্রোসার্ভিস এজ ডিভাইসে স্থাপন করা।
- গবেষণা ফোকাস: স্বয়ংক্রিয় সার্ভিস বিভাজন টুল, বিতরণিত সিস্টেমে বুদ্ধিমান ত্রুটি পূর্বাভাস এবং সার্ভিস কোরিওগ্রাফিতে মিথস্ক্রিয়ার আনুষ্ঠানিক যাচাইকরণে ভবিষ্যত গবেষণা প্রয়োজন।
10. তথ্যসূত্র
- Lewis, J., & Fowler, M. (2014). Microservices. MartinFowler.com. Retrieved from https://martinfowler.com/articles/microservices.html
- Newman, S. (2015). Building Microservices. O'Reilly Media.
- Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
- Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(5), 28-31.
- Google Cloud. (2019). The 2019 Accelerate State of DevOps Report. DORA.
- Netflix Technology Blog. (Various). https://netflixtechblog.com/