“মাইক্রো” শব্দটা শুনলেই মনে হয় সব সমস্যার সমাধান—আসলে প্রথম ধাপটা বোঝা দরকার: এটা কী, আর কেন কেউ এ পথ নেয়।
কী?
মাইক্রোসার্ভিস মানে বড় অ্যাপকে অনেক ছোট সার্ভিসে ভাগ করা; প্রত্যেকটা নির্দিষ্ট কাজ করে। ধারণাটা Unix-এর “এক কাজ, ভালো করে”-র কাছাকাছি।
SOA শুনে থাকলে চেনা লাগবে—মাইক্রোসার্ভিস আরও ছোট গ্রানুলারিটি, কনটেইনার আর ক্লাউড-ফ্রেন্ডলি অপারেশনের যুগের সাথে মানানসই। সার্ভিসগুলো কথা বলে REST, RPC, বা মেসেজ বাস দিয়ে—অ্যাপের ধরন বলে দেয় কোনটা যথেষ্ট।
কেন? (স্কেলিং আর বাস্তবতা)
ট্রাফিক বাড়লে মনোলিথ একটা বক্স—CPU/RAM বাড়িয়ে বাঁচানো যায়; এটাই vertical scaling। কাজ করে, কিন্তু একসময় সিলিং আসে: খরচ, আর সব কিছু এক মেশিনে থাকলে single point of failure।
তখন ভাবা হয়: যদি অ্যাপের অংশগুলো আলাদা থাকত, চাহিদা অনুযায়ী আলাদা মেশিনে স্কেল করা যেত? সেখান থেকেই এই মডেলের জনপ্রিয়তা।
ভাগ করলে এক ধাক্কায় পুরো সাইট ডাউন হওয়ার ঝুঁকি কমে, আর হট স্পট সার্ভিসগুলোকে আলাদা করে বড় করা যায়।
একটা ই-কমার্স উদাহরণ
ধরো সাইটটাকে এভাবে ভাগ করা হয়েছে:
- প্রোডাক্ট ক্যাটালগ
- পছন্দ/হিস্ট্রি
- সার্চ রেজাল্ট
- অর্ডার
- পেমেন্ট/লেজার
১ ও ৩ বেশি লোড নিলে শুধু ওই দুটোকেই বেশি রিসোর্স দিতে পারো—পুরো মনোলিথকে ফ্যাট করার দরকার নেই। একই সার্ভিস জিওগ্রাফি অনুযায়ী ছড়ানো যেতে পারে যদি নির্দিষ্ট রিজিয়নে ট্রাফিক বেশি থাকে (আমাদের দেশে ডাটা সেন্টারের ভৌগোলিক বৈচিত্র্য কম বলে কম দেখা যায়; বড় গ্লোবাল প্রোডাক্টে এটা common)।
এক সার্ভিসের পেছনে একাধিক ইন্সট্যান্সে ট্রাফিক ছড়ানোর যে স্তর—সেটাই load balancer। বিস্তারিত আলাদা পর্বে।
আমার take
মাইক্রোসার্ভিস = সিলভার বুলেট না। ছোট টিম, unclear ডোমেন—এখানে মনোলিথ বা modular monolith অনেক সময় কম ঝামেলা। কিন্তু যখন স্কেল, টিম, আর রিলিজের গতি আলাদা অংশে ভিন্ন হয়ে যায়, তখন operational জটিলতা বইলেও স্কেল আর টিম ভেলোসিটে লাভটা থাকে।
পরের পর্বে: কখন মাইক্রো ভাববে, কখন না—সেটা নিয়ে লিখেছি (/blog/microservices-ken-kokhon-kibhabe-part-2)।