3.16 API গেটওয়ে ও সার্ভিস মেশ

পরিচিতি ও প্রেরণা

একটি প্রোগ্রামকে অনেক সার্ভিসে ভাগ করার মুহূর্তে একটি নতুন প্রশ্ন দেখা দেয়: তাদের মধ্যকার ট্রাফিক এবং বাইরে থেকে আসা ট্রাফিকের দায়িত্বে কে? আপনি প্রশ্নটির খারাপ উত্তর দিতে পারেন একই উদ্বেগ (প্রমাণীকরণ, রিট্রাই, টাইমআউট, হার সীমা, লগিং) প্রতিটি সার্ভিসে হাতে ছড়িয়ে, অথবা ভালো উত্তর দিতে পারেন সেই উদ্বেগ একটি ভাগ করা স্তরে ঠেলে যা প্রতিটি সার্ভিস বিনামূল্যে উত্তরাধিকার পায়। এই অধ্যায় এমন দুটি স্তর নিয়ে। একটি API গেটওয়ে সামনের দরজায় বসে এবং ক্লায়েন্টদের কাছ থেকে আসা ট্রাফিক পরিচালনা করে। একটি সার্ভিস মেশ আপনার সার্ভিসগুলোর মাঝে বসে এবং তাদের মধ্যে প্রবাহিত ট্রাফিক পরিচালনা করে। তারা ভিন্ন জায়গায় সম্পর্কিত সমস্যা সমাধান করে, এবং দুটি গুলিয়ে ফেলা একটি সাধারণ ও ব্যয়বহুল ভুল।

শিল্প ট্রাফিকের দুটি দিককে কম্পাস রূপকে নাম দেয়। উত্তর-দক্ষিণ ট্রাফিক সেই ট্রাফিক যা আপনার সিস্টেমের সীমানা পেরোয়: একটি মোবাইল অ্যাপ, একটি ব্রাউজার বা একজন অংশীদার ভেতরে ডাকছে। পূর্ব-পশ্চিম ট্রাফিক সেই ট্রাফিক যা আপনার সিস্টেমের ভেতরে থাকে: একটি অনুরোধ মেটাতে সার্ভিস A সার্ভিস B-কে ডাকে, যে সার্ভিস C-কে ডাকে। একটি API গেটওয়ে উত্তর-দক্ষিণের বিশেষজ্ঞ। একটি সার্ভিস মেশ পূর্ব-পশ্চিমের বিশেষজ্ঞ। এই পার্থক্য ধারালো রাখা এই অধ্যায়ের একক সবচেয়ে উপকারী ধারণা, কারণ এটি বলে কোন হাতিয়ার কোন নীতির মালিক, এবং আপনাকে একই কাজ দুবার করা থেকে ঠেকায়।

বড় দলের জন্য এই স্তরগুলোই একটি নীতি একশবারের বদলে একবার প্রয়োগ করার উপায়। প্রমাণীকরণ, ট্রানজিটে এনক্রিপশন ও হার সীমাবদ্ধকরণ একটি ভাগ করা স্তরে থাকলে একটি নিরাপত্তা সমাধান আপনি স্তর ডিপ্লয় করার দিনই প্রতিটি সার্ভিসে পৌঁছায়, শত ব্যাকলগের জন্য অপেক্ষা না করে। এন্টারপ্রাইজ ও সরকারি পরিবেশে সেই কেন্দ্রীকরণই প্রায়ই মূল কথা: নিরীক্ষকরা একটি একক, প্রমাণযোগ্য জায়গা চান যেখানে অ্যাক্সেস পরীক্ষা হয় এবং ট্রাফিক এনক্রিপ্টেড, আর একটি ভাগ করা গেটওয়ে বা মেশ ঠিক সেই নীতি প্রয়োগ বিন্দু দেয়। এই অধ্যায় অধ্যায় 3.2-এর স্থাপত্য শৈলী, অধ্যায় 3.3-এর বিতরিত-সিস্টেম বাস্তবতা এবং অধ্যায় 3.13-এর নেটওয়ার্কিং মৌলিক বিষয়ের ওপর গড়া, এবং সেগুলো আপনার ট্রাফিক কে সামলায় সে সম্পর্কে সুনির্দিষ্ট নির্দেশনায় পরিণত করে।

মূল নীতিসমূহ

• উত্তর-দক্ষিণ (গেটওয়ে) ও পূর্ব-পশ্চিম (মেশ) আলাদা করুন; প্রতিটিকে নিজের দিকের মালিক হতে দিন।
• ক্রস-কাটিং উদ্বেগ একটি ভাগ করা স্তরে ঠেলুন যাতে আপনি প্রতি সার্ভিসে নয়, একবার লেখেন।
• সার্ভিসের সংখ্যা প্রতি-সার্ভিস তারকে বড় খরচ করলেই কেবল সার্ভিস মেশ গ্রহণ করুন।
• প্রতিটি উদ্বেগের জন্য একটি নীতি প্রয়োগ বিন্দু ঠিক করুন; গেটওয়ে ও মেশ দুটিকে কখনো একই কাজ করতে দেবেন না।
• সার্ভিস পাতলা রাখুন: প্ল্যাটফর্ম পরিবহন সামলায়, সার্ভিস ব্যবসায়িক যুক্তি।
• নেটওয়ার্ক অবস্থানের ওপর আস্থার বদলে পরিচয়-ভিত্তিক, শূন্য-আস্থা নেটওয়ার্কিং পছন্দ করুন।
• মেশের পরিচালনগত জটিলতা চোখ খুলে কিনুন, এবং মাপুন তা ফল দেয় কি না।

সুপারিশ

একটি API গেটওয়ে কী করে তা বুঝুন

একটি API গেটওয়ে হলো আপনার সার্ভিসের সামনে বসা একক প্রবেশ বিন্দু যা বাইরের জগৎ থেকে আসা প্রতিটি অনুরোধে মধ্যস্থতা করে। সরলতম রূপে এটি একটি চতুর রিভার্স প্রক্সি (একটি সার্ভার যা ক্লায়েন্ট অনুরোধ গ্রহণ করে এবং সঠিক ব্যাকএন্ডে ফরওয়ার্ড করে), কিন্তু একটি গেটওয়ে নামটি অর্জন করে ফরওয়ার্ডিংয়ের চেয়ে অনেক বেশি করে। এটি পাথ, হোস্ট বা হেডারের ভিত্তিতে প্রতিটি অনুরোধ সঠিক সার্ভিসে রুট করে। এটি কলারকে প্রমাণীকরণ করে (কে তা যাচাই) এবং অনুরোধ অনুমোদন করে (সে কী করতে পারে তা পরীক্ষা), তাই এর পেছনের একটি সার্ভিস বিশ্বাস করতে পারে যে একটি অনুরোধ ইতিমধ্যে সামনের দরজা পেরিয়েছে। এটি হার সীমাবদ্ধকরণ (সময় ধরে প্রতি ক্লায়েন্টের অনুরোধ সীমিত) ও কোটা (দীর্ঘতর জানালায় মোট ব্যবহার সীমিত) প্রয়োগ করে যাতে একটি কোলাহলপূর্ণ বা অপব্যবহারকারী ক্লায়েন্ট বাকিদের অনাহারে রাখতে না পারে।

একটি গেটওয়ে ট্রাফিকের আকারও বদলায়। অনুরোধ রূপান্তর হেডার পুনর্লিখন করে, প্রোটোকলের মধ্যে অনুবাদ করে, বা একটি পুরোনো ক্লায়েন্টের ফরম্যাট একটি নতুন সার্ভিসের প্রত্যাশায় খাপ খাওয়ায়। API সংযোজন গেটওয়েকে একটি একক ইনবাউন্ড অনুরোধ কয়েকটি সার্ভিসে ছড়িয়ে তাদের সাড়া একটিতে জুড়তে দেয়, তাই ক্লায়েন্ট ছয়টির বদলে একটি কল করে। সংস্করণ সমর্থন আপনাকে API-র v1 ও v2 পাশাপাশি চালাতে এবং প্রতিটি ক্লায়েন্টকে সে যে সংস্করণ আশা করে তাতে রুট করতে দেয়, যা কাউকে না ভেঙে বিবর্তনের জায়গা কেনে। এই উদ্বেগ প্রান্তে কেন্দ্রীভূত করা আপনার সার্ভিসকে ব্যবসায়িক যুক্তিতে মনোযোগী রাখে এবং যা কিছু ঢোকে তার সব পর্যবেক্ষণ, সুরক্ষিত ও থ্রটল করার একটি জায়গা দেয়। গেটওয়ে যে API-র সামনে বসে তার নকশা অধ্যায় 2.3-এর বিষয়, এবং এটি যে পরিচয় পরীক্ষা করে তা অধ্যায় 4.7 থেকে টানে।

ভিন্নমুখী ক্লায়েন্টের জন্য ব্যাকএন্ড-ফর-ফ্রন্টএন্ড প্যাটার্ন ব্যবহার করুন

একটি সাধারণ-উদ্দেশ্যের API প্রায়ই একটি ওয়েব অ্যাপ, একটি মোবাইল অ্যাপ ও অংশীদার ইন্টিগ্রেশনকে একসঙ্গে সেবা দেয়, এবং সবাইকে সামান্য খারাপভাবে সেবা দেয়। মোবাইল ক্লায়েন্ট ছোট পেলোড ও কম রাউন্ড ট্রিপ চায় কারণ ব্যান্ডউইথ ও ব্যাটারি দুর্লভ; ওয়েব ক্লায়েন্ট বাচাল, সমৃদ্ধ সাড়া সামলাতে পারে; অংশীদার এমন স্থিতিশীল চুক্তি চায় যা কখনো তাকে অবাক করে না। ব্যাকএন্ড ফর ফ্রন্টএন্ড (BFF) প্যাটার্ন এই টানাপোড়েন সমাধান করে প্রতিটি ক্লায়েন্ট শ্রেণিকে তার প্রয়োজনে উপযোগী নিজস্ব পাতলা গেটওয়ে দিয়ে, যা পেছনের ভাগ করা সার্ভিসের সামনে বসে।

একটি BFF হলো সংকীর্ণতর শ্রোতার একটি গেটওয়ে। মোবাইল BFF সাড়া জোড়ে ও ছাঁটে যাতে অ্যাপ একটি দক্ষ কল করে; ওয়েব BFF পূর্ণতর আকার প্রকাশ করে; অংশীদার BFF একটি ধীর-গতি, সাবধানে সংস্করণযুক্ত চুক্তি ধরে। প্রতিটি দল অন্যদের জন্য অপেক্ষা না করে নিজের BFF বিবর্তিত করতে পারে, যা প্রায়ই প্রকৃত জয়, কারণ এটি ক্লায়েন্ট দলগুলোকে একে অন্যের থেকে বিযুক্ত করে। খরচ হলো আরও চলমান অংশ এবং BFF জুড়ে কিছু নকল যুক্তি, তাই ক্লায়েন্টের প্রয়োজন সত্যিই ভিন্ন হলে প্যাটার্নটি সংরক্ষণ করুন। প্রতিটি ক্লায়েন্ট একই জিনিস চাইলে একটি গেটওয়ে সরলতর ও ভালো।

একটি সার্ভিস মেশ কী করে তা বুঝুন

একটি সার্ভিস মেশ আপনার সার্ভিসের মধ্যকার পূর্ব-পশ্চিম ট্রাফিক পরিচালনা করে, এবং সেই সার্ভিসগুলোকে কোড না বদলাতে বলে তা করে। ক্লাসিক মেশ কাজ করে প্রতিটি সার্ভিস ইনস্ট্যান্সের পাশে একটি সাইডকার প্রক্সি ডিপ্লয় করে (একটি ছোট প্রক্সি প্রসেস যা সার্ভিসের সব নেটওয়ার্ক ট্রাফিক আটকায়)। আপনার সার্ভিস ভাবে সে সরাসরি অন্য সার্ভিসের সঙ্গে কথা বলছে; বাস্তবে সে তার স্থানীয় সাইডকারের সঙ্গে কথা বলে, যা প্রকৃত নেটওয়ার্ক কল সামলায়। কারণ প্রতিটি অনুরোধ এখন প্ল্যাটফর্মের নিয়ন্ত্রিত একটি প্রক্সির মধ্য দিয়ে প্রবাহিত হয়, মেশ প্রতিটি ভাষায় প্রতিটি সার্ভিস জুড়ে অভিন্নভাবে আচরণ প্রয়োগ করতে পারে, সিঙ্কে রাখার কোনো ভাগ করা লাইব্রেরি ছাড়া।

এটি কী প্রয়োগ করে? প্রথমত, পারস্পরিক TLS (mTLS), যেখানে প্রতিটি সংযোগের দুই পক্ষই সার্টিফিকেট উপস্থাপন করে এবং ট্রাফিক এনক্রিপ্ট করে, তাই সার্ভিস-থেকে-সার্ভিস কল ডিফল্টে প্রমাণীকৃত ও ব্যক্তিগত। দ্বিতীয়ত, ট্রাফিক ব্যবস্থাপনা: মেশ একটি ক্যানারি রিলিজের জন্য ট্রাফিকের একটি ছোট শতাংশ নতুন সংস্করণে সরাতে, টেস্টিংয়ের জন্য হেডার ধরে ট্রাফিক ভাগ করতে, বা একটি শ্যাডো সার্ভিসে ট্রাফিক মিরর করতে পারে। তৃতীয়ত, স্থিতিস্থাপকতা: রিট্রাই, টাইমআউট ও সার্কিট ব্রেকিং (অধ্যায় 2.20-এর প্যাটার্ন) প্ল্যাটফর্ম স্তরে প্রয়োগ, প্রতিটি সার্ভিসে কোড না করে নীতি দিয়ে কনফিগার করা। চতুর্থত, অবজার্ভেবিলিটি: কারণ প্রতিটি অনুরোধ একটি প্রক্সি পেরোয়, মেশ সব সার্ভিস-থেকে-সার্ভিস ট্রাফিকের জন্য সামঞ্জস্যপূর্ণ মেট্রিক, লগ ও বিতরিত ট্রেস নির্গত করে, অধ্যায় 9.2-এর অবজার্ভেবিলিটি চর্চায় জোগান দিয়ে। সার্ভিস রচয়িতা এর কিছুই লেখেন না এবং সবই পান।

সাইডকার প্যাটার্ন ও সাইডকারবিহীন বিকল্প জানুন

সাইডকার মডেল মার্জিত কিন্তু বিনামূল্যের নয়। প্রতিটি সার্ভিস ইনস্ট্যান্স এখন একটি বাড়তি প্রক্সি কন্টেইনার চালায় যা মেমরি ও CPU খরচ করে, এবং প্রতিটি কল দুটি বাড়তি নেটওয়ার্ক হপ (স্থানীয় সাইডকারে ঢোকা ও দূরবর্তীটি থেকে বেরোনো) করে, সামান্য লেটেন্সি যোগ করে। হাতে-গোনা সার্ভিসে এই বাড়তি বোঝা অদৃশ্য; হাজার হাজার পডে এটি আপনার কম্পিউট বিল ও লেটেন্সি বাজেটে প্রকৃত লাইন আইটেম হয়ে ওঠে। সেই খরচ সাইডকারবিহীন বা প্রক্সিবিহীন পদ্ধতির ঢেউ চালিয়েছে।

দুটি দিক গুরুত্বপূর্ণ। একটি মেশ ফাংশন প্রতি-পড সাইডকার থেকে প্রতি-নোড প্রক্সিতে সরায়, তাই একই মেশিনের অনেক সার্ভিস প্রত্যেকে নিজের না চালিয়ে একটি প্রক্সি ভাগ করে; এটি কিছু বিচ্ছিন্নতার বিনিময়ে বাড়তি বোঝায় বড় পতন ঘটায়। অন্যটি, প্রক্সিবিহীন পদ্ধতি, একটি পাতলা লাইব্রেরি বা রানটাইমের মাধ্যমে মেশের যুক্তি সরাসরি সার্ভিসে এমবেড করে, প্রতি-ভাষা নির্ভরতার খরচে বাড়তি হপ পুরোপুরি সরিয়ে। একটি নতুন উন্নয়ন eBPF (Linux কার্নেলের ভেতরে স্যান্ডবক্সড প্রোগ্রাম চালানোর প্রযুক্তি) ব্যবহার করে কিছু মেশ ফাংশন অপারেটিং সিস্টেম কার্নেলে ঠেলে দেয়, যা ইউজারস্পেস প্রক্সির চেয়ে কম বাড়তি বোঝায় নীতি প্রয়োগ ও টেলিমেট্রি সংগ্রহ করতে পারে। আপনাকে আজ একটি বিজয়ীর ওপর বাজি ধরতে হবে না। আপনাকে জানতে হবে সাইডকার কর প্রকৃত, বিকল্প বিদ্যমান, এবং আপনার প্ল্যাটফর্ম পছন্দ আপনাকে পরে সেগুলো গ্রহণ থেকে আটকাবে না। এই প্যাটার্ন অধ্যায় 8.3-এর কন্টেইনার অর্কেস্ট্রেশন ভিত্তির ওপর বসে।

মেশ কখন তার জটিলতা অর্জন করে তা ঠিক করুন

একটি সার্ভিস মেশ শক্তিশালী এবং সত্যিই চালানো জটিল। এটি পরিচালনার একটি কন্ট্রোল প্লেন, আপগ্রেড করার প্রক্সি, ঘোরানোর সার্টিফিকেট, এবং একটি অনুরোধ হারিয়ে গেলে ডিবাগ করার একটি নতুন স্তর যোগ করে। যথেষ্ট সার্ভিস থাকলে এই জটিলতা কেনার যোগ্য, যখন প্রতি সার্ভিস ও প্রতি ভাষায় এই উদ্বেগ হাতে জোড়া মেশ চালানোর চেয়ে বেশি খরচ করে। মোটামুটি সংকেত পরিসর ও বহুভাষী বৈচিত্র্য: ডজন বা শত সার্ভিস, কয়েকটি ভাষায় লেখা, যেখানে mTLS ও রিট্রাইয়ের জন্য একটি ভাগ করা লাইব্রেরি সামঞ্জস্যপূর্ণ রাখা দুঃস্বপ্ন হতো। সেই পরিসরে একটি মেশ অভিন্নতা ও প্রমাণযোগ্য নিরাপত্তায় নিজের দাম তোলে।

হাতে-গোনা সার্ভিস, একটি ভাষা বা ছোট দল থাকলে মেশ তার জটিলতা অর্জন করে না। একটি সাদামাটা সিস্টেমের জন্য একটি ভালো লাইব্রেরি বা ফ্রেমওয়ার্ক পূর্ণ মেশের চেয়ে অনেক কম পরিচালনগত বোঝায় mTLS, রিট্রাই ও মেট্রিক দিতে পারে, এবং একটি সাদামাটা গেটওয়ে ও যুক্তিসঙ্গত ক্লায়েন্ট লাইব্রেরি প্রায়ই আপনার যা দরকার সব ঢাকে। আপনার পরিসর দাবি করার আগে ফ্যাশনেবল বলে মেশ গ্রহণ করা এমন সমস্যা সমাধান করা অবকাঠামো এক বছর চালানোর সাধারণ উপায় যা আপনার নেই। গেটওয়ে দিয়ে শুরু করুন, কোড বা লাইব্রেরিতে স্থিতিস্থাপকতা প্যাটার্ন যোগ করুন, এবং সার্ভিস ও ভাষার সংখ্যা প্রতি-সার্ভিস পদ্ধতিকে বেশি ব্যয়বহুল করলে মেশ ধরুন। ক্লাউড ও বিতরিত-সিস্টেম অধ্যায় (3.11 ও 3.3) বারবার যে “এটি কি জটিলতা অর্জন করে” শৃঙ্খলায় ফেরে এটি তা-ই।

গেটওয়ে ও মেশ ওভারল্যাপ করলে দ্বিগুণ-সামলানো এড়ান

গেটওয়ে ও মেশ ওভারল্যাপ করে, এবং ওভারল্যাপই সেখানে যেখানে দল নিজেদের আঘাত করে। দুটিই রিট্রাই করতে পারে, দুটিই টাইমআউট প্রয়োগ করতে পারে, দুটিই পরিচয় পরীক্ষা করতে পারে, দুটিই টেলিমেট্রি সংগ্রহ করতে পারে। গেটওয়ে একটি অনুরোধ তিনবার রিট্রাই করলে এবং মেশও প্রতিটি অভ্যন্তরীণ হপে তিনবার রিট্রাই করলে, একটি ক্লায়েন্ট রিট্রাই ডজন ডজন ব্যাকএন্ড কলে ফেটে একটি ছোট ঝলককে রিট্রাই ঝড়ে পরিণত করতে পারে। দুটি স্তরই একটি টাইমআউট প্রয়োগ করলে এবং ভেতরেরটি বাইরেরটির চেয়ে দীর্ঘ হলে, বাইরেরটি হাল ছাড়ে যখন ভেতরেরটি কাজ করতে থাকে, কেউ পড়বে না এমন একটি সাড়ার ওপর পরিশ্রম অপচয় করে।

সমাধান হলো একটি স্পষ্ট শ্রম বিভাজন লিখে রাখা ও একমত হওয়া। প্রতিটি উদ্বেগ ঠিক একটি স্তরে নির্ধারণ করুন। গেটওয়ে উত্তর-দক্ষিণ উদ্বেগের মালিক: শেষ-ব্যবহারকারী প্রমাণীকরণ, বাইরের হার সীমা ও কোটা, অনুরোধ রূপান্তর এবং ক্লায়েন্টের জন্য API সংযোজন। মেশ পূর্ব-পশ্চিম উদ্বেগের মালিক: সার্ভিস-থেকে-সার্ভিস mTLS, অভ্যন্তরীণ রিট্রাই ও সার্কিট ব্রেকিং এবং সার্ভিস সংস্করণের মধ্যে ট্রাফিক সরানো। যেখানে একটি উদ্বেগ দুটির যেকোনোটিতে থাকতে পারে, একজন মালিক বাছুন এবং অন্য স্তরকে পাস-থ্রু করান। রিট্রাই বাজেট ও টাইমআউট শ্রেণিবিন্যাস এমনভাবে কনফিগার করুন যাতে বাইরের টাইমআউট সবসময় সে যে ভেতরের কাজের অপেক্ষা করছে তার চেয়ে দীর্ঘ হয়। লক্ষ্য হলো প্রতিটি অনুরোধের প্রতিটি উদ্বেগ সামলানোর ঠিক একটি জায়গা থাকা, এবং কোনো অনুরোধ দুর্ঘটনাবশত দুবার রিট্রাই, প্রমাণীকৃত বা লগ না হওয়া।

শূন্য আস্থার জন্য গেটওয়ে ও মেশকে নীতি প্রয়োগ বিন্দু গণ্য করুন

এই স্তরগুলো চালানোর গভীরতম কারণ নিরাপত্তা স্থাপত্য। শূন্য আস্থা হলো এই নীতি যে কোনো অনুরোধ সে কোথা থেকে এসেছে বলে বিশ্বাসযোগ্য নয়; প্রতিটি অনুরোধকে তার পরিচয় ও অনুমোদন প্রমাণ করতে হবে, আপনার নিজের নেটওয়ার্কের ভেতরেও। পুরোনো মডেল ইতিমধ্যে পরিসীমার ভেতরের যেকোনো কিছু বিশ্বাস করত, যার মানে একটি ভাঙা সার্ভিস অবাধে ঘুরে বেড়াতে পারত। শূন্য আস্থা নেটওয়ার্ক-অবস্থান আস্থাকে প্রতিটি হপে পরিচয়-ভিত্তিক আস্থা দিয়ে প্রতিস্থাপন করে, এবং গেটওয়ে ও মেশ হলো সেই স্বাভাবিক প্রয়োগ বিন্দু যেখানে সেই পরিচয় পরীক্ষা হয়।

গেটওয়ে বাইরের পরিচয়ের জন্য নীতি প্রয়োগ বিন্দু: এটি কিছু আপনার সার্ভিসে পৌঁছানোর আগে শেষ ব্যবহারকারী বা অংশীদারকে যাচাই করে। মেশ ওয়ার্কলোড পরিচয়ের জন্য নীতি প্রয়োগ বিন্দু: প্রতিটি সার্ভিস একটি ক্রিপ্টোগ্রাফিক পরিচয় পায়, mTLS প্রতিটি কলে তা প্রমাণ করে, এবং নীতি ঠিক করে কোন সার্ভিস কোনটির সঙ্গে কথা বলতে পারবে। একসঙ্গে তারা গভীর প্রতিরক্ষা দেয়, যেখানে একটি অনুরোধ প্রান্তে এবং আবার সার্ভিসের মধ্যে পরীক্ষিত, তাই একটি সার্ভিসের আপস বাকিদের মুক্ত চলাচল দেয় না। বহু-ক্লাস্টার ও বহু-অঞ্চল ডিপ্লয়মেন্টে একটি মেশ ক্লাস্টার সীমানা জুড়ে এই পরিচয় কাপড় বাড়াতে পারে, ফলে এক ক্লাস্টারের একটি সার্ভিস অন্যটির একটি সার্ভিসের কাছে স্থানীয়ভাবে যে mTLS নিশ্চয়তা ব্যবহার করে তেমনই প্রমাণীকৃত হয়, পদচিহ্ন ছড়ালেও সামঞ্জস্যপূর্ণ শূন্য-আস্থা নেটওয়ার্কিং দিয়ে। এখানকার পরিচয় ভিত্তি সরাসরি অধ্যায় 4.7-এর সঙ্গে যুক্ত।

ট্রেড-অফ: সুবিধা ও অসুবিধা

পদ্ধতি	সুবিধা	অসুবিধা
API গেটওয়ে	authn, হার সীমা, সংযোজন, সংস্করণের একটি জায়গা	স্কেল ও উচ্চ উপলব্ধ রাখার একটি একক চোকপয়েন্ট
ব্যাকএন্ড ফর ফ্রন্টএন্ড	প্রতিটি ক্লায়েন্ট একটি উপযোগী, স্বাধীনভাবে বিবর্তনশীল API পায়	চালানোর আরও গেটওয়ে; BFF জুড়ে নকল যুক্তি
সার্ভিস মেশ (সাইডকার)	কোড পরিবর্তন ছাড়া অভিন্ন mTLS, রিট্রাই, অবজার্ভেবিলিটি	প্রক্সি বাড়তি বোঝা, লেটেন্সি, এবং চালানোর একটি কন্ট্রোল প্লেন
সাইডকারবিহীন / প্রক্সিবিহীন মেশ	প্রতি-পড সাইডকারের চেয়ে কম বাড়তি বোঝা ও লেটেন্সি	কম পরিণত; দুর্বলতর বিচ্ছিন্নতা বা প্রতি-ভাষা নির্ভরতা
লাইব্রেরি-ভিত্তিক স্থিতিস্থাপকতা	চালানো সরল; বাড়তি অবকাঠামো নেই	প্রতি-ভাষা নকল; পরিসরে সামঞ্জস্যপূর্ণ রাখা কঠিন
ক্লাস্টার জুড়ে মেশ	সর্বত্র সামঞ্জস্যপূর্ণ শূন্য-আস্থা পরিচয়	উল্লেখযোগ্য পরিচালনগত ও নেটওয়ার্কিং জটিলতা

কেন্দ্রীয় টানাপোড়েন অভিন্নতা বনাম পরিচালনগত খরচ। একটি ভাগ করা স্তর আপনাকে সামঞ্জস্য, প্রমাণযোগ্য নিরাপত্তা এবং একবার লেখা নীতি কেনে, কিন্তু এটি একটি প্রকৃত সিস্টেম যা আপনাকে চালাতে, স্কেল করতে, সুরক্ষিত করতে ও ডিবাগ করতে হয়, এবং এটি প্রতিটি অনুরোধের পথে নিজেকে ঢোকায়। পরিসর ও প্রয়োজন দিয়ে টানাপোড়েন সমাধান করুন। বাইরের ক্লায়েন্ট থাকার মুহূর্তে একটি গেটওয়ে প্রায় সবসময় ফল দেয়, কারণ সে যে উদ্বেগ কেন্দ্রীভূত করে তা আপনি এড়াতে পারেন না। একটি মেশ পরে ফল দেয়, যখন সার্ভিস ও ভাষার সংখ্যা প্রতি-সার্ভিস তারকে বেশি ব্যয়বহুল পথ করে। সেই সীমার নিচে লাইব্রেরি ও একটি সাদামাটা গেটওয়ে খরচের ভগ্নাংশে বেশিরভাগ সুবিধা দেয়। ওপরে মেশের অভিন্নতা তার ওজনের যোগ্য। দুই দিকেই ভুল হলো প্রয়োজনের বদলে ফ্যাশনে গ্রহণ: খুব আগে মেশ এক বছরের ইয়াক-শেভিং, আর খুব দেরিতে বাদ দেওয়া মেশ mTLS-এর শত অসঙ্গত, হাতে-ঘোরানো বাস্তবায়ন।

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

1. প্রতিটি ক্রস-কাটিং উদ্বেগের (প্রমাণীকরণ, রিট্রাই, টাইমআউট, হার সীমাবদ্ধকরণ, এনক্রিপশন, টেলিমেট্রি) জন্য কোন একক স্তর মালিক, এবং সবাই কি অনুমান না করে মালিকের নাম বলতে পারেন? এটি সেই প্রশ্ন যা দ্বিগুণ-সামলানো ঠেকায়, এবং বেশিরভাগ দল কখনো এর সুস্পষ্ট উত্তর দেয়নি, মানে উত্তর সার্ভিস ও রচয়িতা ভেদে ভিন্ন। বাঁ দিকে উদ্বেগের একটি সুনির্দিষ্ট তালিকা এবং ওপরে আপনার স্তর (ক্লায়েন্ট লাইব্রেরি, গেটওয়ে, মেশ, পৃথক সার্ভিস) নিয়ে আসুন, এবং একসঙ্গে গ্রিড পূরণ করুন। যেখানে একটি উদ্বেগের জন্য দুটি ঘর পরীক্ষিত, সেগুলো আপনার ঘটার অপেক্ষায় থাকা রিট্রাই ঝড় ও টাইমআউট উল্টানো। ফাঁকা সারিগুলো সেই উদ্বেগ যা কেউ আদৌ সামলাচ্ছে না। ফল হলো একটি সম্মত টেবিল, যেখানে প্রতিটি দল দেখতে পায় সেখানে প্রকাশিত, যা বলে ঠিক একটি স্তর প্রতিটি উদ্বেগের মালিক এবং বাকিরা পাস-থ্রু করে। সেই টেবিল যেকোনো পরিমাণ গেটওয়ে বা মেশ কনফিগারেশনের চেয়ে বেশি মূল্যবান, কারণ এটিই সেই জিনিস যা দুটি স্তরকে একে অন্যের সঙ্গে লড়া থেকে ঠেকায়।

2. একটি সার্ভিস মেশ যথার্থ করার মতো যথেষ্ট সার্ভিস ও ভাষা বৈচিত্র্য কি আমাদের আছে, নাকি আমাদের নেই এমন সমস্যা সমাধানে আমরা একটি কন্ট্রোল প্লেন কিনতে যাচ্ছি? একটি মেশ গুরুতর পরিচালনগত প্রতিশ্রুতি, এবং অনেক দলের সৎ উত্তর হলো একটি ভালো লাইব্রেরি ও একটি গেটওয়ে আজ তাদের ভালো সেবা দিত। আপনার সার্ভিসের প্রকৃত সংখ্যা, সেগুলো যে কয়টি ভাষায় লেখা, এবং নকল নেটওয়ার্কিং যুক্তি এখনই আপনাকে কতটা আঘাত করছে তার সৎ মূল্যায়ন আনুন। তারপর অন্য দিকও আনুন: মেশ কে চালাবে, তার প্রক্সি আপগ্রেড করবে, সার্টিফিকেট ঘোরাবে, এবং একটি অনুরোধ ভুল রুট হলে কে পেজ পাবে। প্রতি-সার্ভিস তারের ব্যথা মেশ চালানোর খরচের চেয়ে ছোট হলে আপনার উত্তর আছে, আর তা হলো অপেক্ষা করা। বহুভাষী ডজন সার্ভিস জুড়ে অসঙ্গত mTLS ও রিট্রাই কোডে ডুবে থাকলে মেশ নিজের ভরণপোষণ অর্জন করে। মূল কথা হলো প্রমাণে সিদ্ধান্ত নেওয়া, মেশ একটি সম্মেলন বক্তৃতায় যেমন দেখাত তার ভিত্তিতে নয়।

3. আজ আমাদের শূন্য-আস্থা সীমানা কোথায়, এবং একটি অভ্যন্তরীণ সার্ভিস আপস হলে কী ঘটে? অনেক সিস্টেম এখনো নেটওয়ার্কের ভেতরে ইতিমধ্যে থাকা যেকোনো কিছু বিশ্বাস করে, যার মানে একটি ভাঙা সার্ভিস পার্শ্বদিকে সরে বাকি সবকিছুতে পৌঁছাতে পারে, এবং দল প্রায়ই কেবল একটি ঘটনার সময় তা আবিষ্কার করে। ক্ষতির পরিসর সৎভাবে হাঁটুন: একজন আক্রমণকারী আপনার একটি সার্ভিসের মালিক হলে সে কী ডাকতে পারে, কী পড়তে পারে, এবং তাকে কী থামায়? সার্ভিস-থেকে-সার্ভিস কল কীভাবে প্রমাণীকৃত ও এনক্রিপ্টেড তার আপনার বর্তমান উত্তর আনুন, এবং নির্দিষ্ট থাকুন কোন কল mTLS দ্বারা সুরক্ষিত আর কোনটি একই নেটওয়ার্কে থাকার ভিত্তিতে প্লেইনটেক্সট আস্থা। পরবর্তী পদক্ষেপ হলো প্রতিটি হপে পরিচয়-ভিত্তিক অ্যাক্সেসের একটি সুচিন্তিত পরিকল্পনা, গেটওয়ে বাইরের পরিচয় এবং মেশ বা সমতুল্য ওয়ার্কলোড পরিচয় পরীক্ষা করে, যাতে একটি আপস বিপর্যয়ের বদলে সীমিত থাকে। আপনি পূর্ণ মেশ চালানোর জন্য প্রস্তুত না হলেও, আস্থা সীমানা আসলে কোথায় বসে তার নাম দেওয়া প্রথম সৎ পদক্ষেপ।

4. আমাদের API গেটওয়ে স্তর এখনই ব্যর্থ হলে সিস্টেমের কতটা অন্ধকার হয়, এবং আমরা কি সেই ব্যর্থতা উড়িয়ে না দিয়ে পরীক্ষা করেছি? গেটওয়ে এত কেন্দ্রীভূত করে যে এর বিভ্রাট এর পেছনের সবকিছু অফলাইন করে, এবং বড় দল এর বাড়তি ব্যবস্থায় ঠিক সেই কারণে কম বিনিয়োগ করে যে এটি শান্তভাবে কাজ করে যতক্ষণ না আর করে না। প্রতিদ্বন্দ্বী টান ওজন করুন: একটি সরল একক গেটওয়ে নিয়ে যুক্তি করা সহজ ও চালাতে সস্তা, আর অনুভূমিকভাবে স্কেল করা বহু-জোন স্তর বেশি খরচ করে এবং নিজস্ব ফেইলওভার কনফিগারেশন ও জটিলতা যোগ করে। আলোচনায় প্রকৃত সংখ্যা আনুন, আজ কয়টি ইনস্ট্যান্স চলে, কয়টি উপলব্ধতা জোন জুড়ে, ফেইলওভার সময় কত, এবং আপনি শেষ কবে ইচ্ছা করে গেটওয়ে মেরে ফেলা গেম ডে চালিয়েছেন। আপটাইম প্রতিশ্রুতি বা বিধিবদ্ধ সেবা স্তর বহনকারী এন্টারপ্রাইজ ও সরকারি প্ল্যাটফর্মের জন্য বিভ্রাটের চুক্তিগত বা নিয়ন্ত্রক জরিমানা যোগ করুন, কারণ বাড়তি ব্যবস্থাহীন সামনের দরজা এমন উপলব্ধতা ঝুঁকি যা আপনি এর পেছনের প্রতিটি সার্ভিস ও প্রতিটি নাগরিকের পক্ষে নিঃশব্দে গ্রহণ করেছেন।

5. আমাদের মেশ আসলে যে সাইডকার কর নেয় তা কি আমরা মেপেছি, এবং সাইডকারবিহীন ও eBPF বিকল্পের জন্য আমাদের কি পরিকল্পনা আছে, নাকি আমরা অন্ধভাবে তা দিচ্ছি? পরিসরে প্রতি-পড প্রক্সি বাড়তি বোঝা কম্পিউট ও লেটেন্সিতে অদৃশ্য থাকা বন্ধ করে বাজেটের প্রকৃত লাইন হয়ে ওঠে, তবু অনেক দল তার খরচ কখনো না মেপে হাজার হাজার সাইডকার চালায়। টানাপোড়েন সাইডকার মডেলের পরিপক্বতা ও বিচ্ছিন্নতা একদিকে, আর প্রতি-নোড প্রক্সি, প্রক্সিবিহীন লাইব্রেরি বা কার্নেল eBPF পদ্ধতির কম বাড়তি বোঝা অন্যদিকে, যেগুলো নতুনতর এবং কিছু বিচ্ছিন্নতা ছাড়ে বা প্রতি-ভাষা নির্ভরতা যোগ করে। মাপা সংখ্যা আনুন: বহর জুড়ে প্রক্সির খাওয়া মেমরি ও CPU, প্রতি হপে যোগ হওয়া লেজের লেটেন্সি, এবং আপনার কম্পিউট বিলের কত ভগ্নাংশ মেশ। হাজার হাজার পড জুড়ে মেশ চালানো একটি বড় এন্টারপ্রাইজ বা বাজেট যাচাইয়ের অধীন একটি সরকারি প্ল্যাটফর্মের জন্য এটি এমন একটি ব্যয় সিদ্ধান্ত যা তদারকি অবশেষে জিজ্ঞেস করবে, তাই কর জানা এবং আপনার প্ল্যাটফর্ম পছন্দ সস্তা বিকল্প খোলা রাখে কি না জানা মৌলিক যথাযথ পরিশ্রম।

6. প্রতিটি ক্লায়েন্ট শ্রেণির কি সত্যিই নিজস্ব ব্যাকএন্ড ফর ফ্রন্টএন্ড দরকার, নাকি আমরা একই জিনিস চাওয়া ক্লায়েন্টের জন্য গেটওয়ে জুড়ে যুক্তি নকল করতে যাচ্ছি? BFF প্যাটার্ন ক্লায়েন্ট দলকে বিযুক্ত করে এবং প্রতিটিকে একটি উপযোগী চুক্তি বিবর্তিত করতে দেয়, কিন্তু প্রতিটি নতুন BFF চালানোর, সুরক্ষিত করার ও সিঙ্কে রাখার আরেকটি গেটওয়ে, এবং তাদের জুড়ে নকল যুক্তি নিঃশব্দে রক্ষণাবেক্ষণ কর হয়ে ওঠে। প্রতিদ্বন্দ্বী বিবেচনা দল স্বায়ত্তশাসন ও ক্লায়েন্ট-নির্দিষ্ট দক্ষতা বনাম অনেক প্রায়-অভিন্ন গেটওয়ের পরিচালনগত খরচ ও সরে যাওয়া। ক্লায়েন্টের প্রয়োজন প্রকৃতপক্ষে কতটা ভিন্ন তার প্রমাণ আনুন: পেলোডের আকার, রাউন্ড-ট্রিপ গণনা, সংস্করণ ছন্দ, এবং একটি ভাগ করা গেটওয়ের অধীনে একটি ক্লায়েন্টের পরিবর্তন কত ঘন ঘন অন্যটিকে আটকাত। অনেক ক্লায়েন্ট দলসহ একটি বড় প্রতিষ্ঠানে, বা একটি পাবলিক ওয়েব অ্যাপ, একটি মোবাইল অ্যাপ ও অংশীদার ইন্টিগ্রেশন একসঙ্গে সেবা দেওয়া একটি সরকারি প্ল্যাটফর্মে, সৎ প্রশ্ন হলো ভিন্নতা কি বিস্তার যথার্থ করে, কারণ সবাই একই আকার চাওয়া প্রতিটি ক্লায়েন্টের জন্য একটি BFF বছরের পর বছর রক্ষণাবেক্ষণে দাম দেওয়া একটি জঙ্গল।

খাতভেদে দৃষ্টিভঙ্গি

স্টার্টআপ। একটি API গেটওয়ে পাঠান এবং মেশ বাদ দিন। হাতে-গোনা সার্ভিস ও ক্ষুদ্র দলে একটি একক গেটওয়ে প্রমাণীকরণ, হার সীমা ও সংযোজন সামলায়, আর একটি ভাগ করা ক্লায়েন্ট লাইব্রেরি কন্ট্রোল প্লেনের খরচের ভগ্নাংশে আপনাকে mTLS ও রিট্রাই দেয়। আপনার দুর্লভতম সম্পদ প্রকৌশল মনোযোগ, তাই আপনি চালাতে পারেন না এমন মেশ একটি দায়, পরিখা নয়। এক নোড মরলে টিকে থাকার মতো যথেষ্ট বাড়তি ব্যবস্থায় গেটওয়ে রাখুন, এবং সার্ভিস সংখ্যা ও ভাষা বৈচিত্র্য সত্যিই প্রশ্নটি বাধ্য করলেই কেবল মেশ পুনর্বিবেচনা করুন।

ছোট ব্যবসা। মেশ চালানোর প্ল্যাটফর্ম দল নেই, তাই আপনার হোস্টিং প্ল্যাটফর্ম বা গেটওয়ে পণ্য বাক্সের বাইরে যা দেয় তার ওপর ভর করুন: ম্যানেজড TLS, ইনবিল্ট হার সীমাবদ্ধকরণ, এবং আপনি প্যাচ করেন এমন একটির বদলে একটি হোস্টেড গেটওয়ে। পছন্দকে কেনা-বনাম-বানানো ফ্রেম করুন, এবং কিনুন, কারণ একটি ম্যানেজড API গেটওয়ে নিজের চালানোর ইঞ্জিনিয়ার-ঘণ্টার চেয়ে কম খরচ করে। অভ্যন্তরীণ সার্ভিস-থেকে-সার্ভিস এনক্রিপশনকে আপনার প্ল্যাটফর্মের দেওয়া ফিচার গণ্য করুন, আপনি কর্মী জোগান দেওয়া প্রকল্প নয়।

এন্টারপ্রাইজ। অনেক দল ও ভাষা জুড়ে শত শত সার্ভিসে একটি মেশ তার জটিলতা অর্জন করে, এবং প্রকৃত কাজ শাসন: একটি লিখিত শ্রম বিভাজন যাতে গেটওয়ে ও মেশ কখনো একটি উদ্বেগ দ্বিগুণ-সামলায় না, অভিন্ন mTLS ও টেলিমেট্রি, এবং প্রক্সি আপগ্রেড ও সার্টিফিকেট ঘূর্ণনের মালিক একটি প্ল্যাটফর্ম দল। নিরীক্ষকরা অ্যাক্সেস ও এনক্রিপশনের জন্য একটি একক প্রমাণযোগ্য প্রয়োগ বিন্দু চান, তাই ইন্টারফেস প্রমিত করুন এবং নীতিকে পুনর্বাস্তবায়নের বদলে দলগুলোর উত্তরাধিকার পাওয়া কিছু করুন। সাইডকার করকে প্রকৃত বাজেট লাইন হিসেবে পরিচালনা করুন, এবং সাইডকারবিহীন বিকল্প খোলা রাখুন যাতে আপনি পরে সস্তা পদ্ধতি থেকে আটকে না যান।

সরকার। ক্রয়ের নিয়ম, স্বচ্ছতা ও জনগণের কাছে জবাবদিহি স্থাপত্য আকার দেয়। গেটওয়ে ও মেশকে নিয়ন্ত্রকরা যে শূন্য-আস্থা মেরুদণ্ড আশা করেন তা গণ্য করুন: প্রতিটি নাগরিক ও অংশীদার সামনের দরজায় প্রমাণীকৃত, প্রতিটি অভ্যন্তরীণ কল ওয়ার্কলোড পরিচয় দিয়ে প্রমাণীকৃত ও এনক্রিপ্টেড, এবং প্রতিটি প্রয়োগ বিন্দুতে একটি নিরীক্ষা ট্রেইল যা প্রমাণ করে অ্যাক্সেস কোথায় পরীক্ষা হয়েছে এবং ট্রাফিক কোথায় এনক্রিপ্টেড। ক্রয়ের নিয়ম যা নিষিদ্ধ করতে পারে সেই মালিকানাধীন লক-ইনের বদলে মুক্ত মান ও বহনযোগ্য কনফিগারেশন পছন্দ করুন, এবং যথাযথ ক্ষেত্রে প্রকাশ করুন প্ল্যাটফর্ম প্রতিটি সীমানা পেরোনোর সময় নাগরিক ডেটা কীভাবে রক্ষা করে।

উদাহরণ

স্টার্টআপ। বারোজনের একটি স্টার্টআপ একটি একক API গেটওয়ের পেছনে আটটি সার্ভিস চালায়। গেটওয়ে সব উত্তর-দক্ষিণ কাজ সামলায়: এটি একটি টোকেন পরীক্ষায় ব্যবহারকারীদের প্রমাণীকরণ করে, প্রতি-প্ল্যান হার সীমা প্রয়োগ করে যাতে ফ্রি-স্তরের ব্যবহারকারীরা সিস্টেম ভরাট করতে না পারে, এবং কয়েকটি বাচাল এন্ডপয়েন্ট মোবাইল-বান্ধব একক কলে জোড়ে। পূর্ব-পশ্চিম ট্রাফিকের জন্য তারা ইচ্ছাকৃতভাবে একটি সার্ভিস মেশ বাদ দেয়, কারণ দুটি ভাষায় আটটি সার্ভিস একটি কন্ট্রোল প্লেন যথার্থ করে না। তার বদলে তারা একটি ভাগ করা ক্লায়েন্ট লাইব্রেরি ও তাদের প্ল্যাটফর্মের ইনবিল্ট সার্টিফিকেট ব্যবস্থাপনা থেকে mTLS ও রিট্রাই পায়, এবং একটি হালকা এজেন্ট দিয়ে ট্রেস সংগ্রহ করে। পরে তারা কঠোরতর পেলোড প্রয়োজনের একটি নিবেদিত মোবাইল ক্লায়েন্ট যোগ করলে বিদ্যমান ওয়েব গেটওয়ের পাশে একটি মোবাইল ব্যাকএন্ড ফর ফ্রন্টএন্ড আনে। তারা প্রতি বছর মেশ প্রশ্ন পুনর্বিবেচনা করে এবং ঠিকভাবে সিদ্ধান্ত নিতে থাকে যে তারা এখনো সেই সীমা পেরোয়নি যেখানে এটি ফল দেবে।

এন্টারপ্রাইজ। একটি বহুজাতিক ব্যাংক অনেক দল ও ভাষা জুড়ে কয়েকশ সার্ভিস চালায়, এবং এখানে একটি সার্ভিস মেশ তার জটিলতা অর্জন করে। প্রতিটি সার্ভিস একটি ওয়ার্কলোড পরিচয় এবং ডিফল্টে mTLS পায়, তাই সব অভ্যন্তরীণ ট্রাফিক কোনো দল ক্রিপ্টো কোড না লিখে প্রমাণীকৃত ও এনক্রিপ্টেড, যা নিরাপত্তা সংস্থা এবং একক প্রমাণযোগ্য প্রয়োগ বিন্দু চাওয়া নিরীক্ষক দুজনকেই সন্তুষ্ট করে। মেশ নীতি দিয়ে অভিন্ন রিট্রাই, টাইমআউট ও সার্কিট ব্রেকিং প্রয়োগ করে, এবং ক্যানারি রিলিজের জন্য ক্রমে ট্রাফিক সরায় যাতে একটি খারাপ ডিপ্লয় সবাইকে ছোঁয়ার আগে এক শতাংশ ব্যবহারকারীকে ছোঁয়। API গেটওয়ের একটি স্তর বাইরের ও অংশীদার ট্রাফিকের সামনে বসে, প্রমাণীকরণ, কোটা ও সংস্করণের মালিক, একটি দৃঢ় লিখিত নিয়মসহ যে অভ্যন্তরীণ রিট্রাই কেবল মেশে এবং বাইরের হার সীমা কেবল গেটওয়েতে থাকে, তাই দুটি স্তর কখনো একটি অনুরোধ দ্বিগুণ-সামলায় না। প্রতিটি প্রক্সি থেকে সামঞ্জস্যপূর্ণ টেলিমেট্রি একটি কেন্দ্রীয় অবজার্ভেবিলিটি প্ল্যাটফর্মে জোগান দেয় যা একজন অন-কল ইঞ্জিনিয়ারকে ডজন ডজন সার্ভিস হপ জুড়ে একটি অনুরোধ ট্রেস করতে দেয়।

সরকার। একটি জাতীয় কর সংস্থা একটি নাগরিক-মুখী দাখিল প্ল্যাটফর্ম আধুনিক করে এবং গেটওয়ে ও মেশকে নিয়ন্ত্রকদের দাবি করা শূন্য-আস্থা স্থাপত্যের মেরুদণ্ড গণ্য করে। একটি API গেটওয়ে নিয়ন্ত্রিত সামনের দরজা: প্রতিটি নাগরিক ও প্রতিটি অংশীদার সেখানে প্রমাণীকৃত ও অনুমোদিত, বাইরের হার সীমা দাখিলের সময়সীমার ঢেউয়ের সময় সিস্টেম রক্ষা করে, এবং পুরোনো ক্লায়েন্ট ফরম্যাট প্রান্তে রূপান্তরিত হয় যাতে লিগ্যাসি ইন্টিগ্রেশন কাজ করতে থাকে। তার পেছনে একটি সার্ভিস মেশ প্রতিটি অভ্যন্তরীণ সার্ভিসকে একটি ক্রিপ্টোগ্রাফিক পরিচয় দেয় এবং প্রতিটি কলে mTLS প্রয়োগ করে, তাই কোনো সার্ভিস কেবল নেটওয়ার্কের ভেতরে থাকার জন্য বিশ্বস্ত নয়, এবং অ্যাক্সেস নীতি সুস্পষ্টভাবে তালিকাভুক্ত করে কোন সার্ভিস কোনটিকে ডাকতে পারে। প্ল্যাটফর্ম স্থিতিস্থাপকতার জন্য একাধিক ডেটা সেন্টার জুড়ে বিস্তৃত বলে মেশ ক্লাস্টার জুড়ে একই পরিচয় ও এনক্রিপশন নিশ্চয়তা বাড়ায়, দেশজুড়ে সামঞ্জস্যপূর্ণ শূন্য-আস্থা নেটওয়ার্কিং দেয়। প্রতিটি প্রয়োগ বিন্দু একটি নিরীক্ষা ট্রেইল নির্গত করে, তাই সংস্থা তদারকি সংস্থাকে প্রমাণ করতে পারে ঠিক কোথায় অ্যাক্সেস পরীক্ষা হয়েছে এবং ট্রাফিক কোথায় এনক্রিপ্টেড।

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

একটি গেটওয়ের প্রতিদান দেখা সহজ এবং সাধারণত বড়। প্রতিটি সার্ভিস প্রমাণীকরণ, হার সীমাবদ্ধকরণ ও অনুরোধ লগিং পুনর্বাস্তবায়ন করার বদলে আপনি সেগুলো প্রান্তে একবার গড়েন এবং প্রতিটি সার্ভিস উত্তরাধিকার পায়। একটি নিরাপত্তা সমাধান বা নতুন হার-সীমা নীতি একশটির বদলে একটি ডিপ্লয়ে পৌঁছায়, যা দুর্বলতা বন্ধ করার সময় কমায় এবং প্রতিটি নিরীক্ষার খরচ কমায়, কারণ পরিদর্শনের একটি জায়গা। সংযোজন ও সংস্করণ ফিচার ক্লায়েন্ট রাউন্ড ট্রিপ কাটে এবং কলারদের না ভেঙে API বিবর্তিত করতে দেয়, যা লেটেন্সি খরচ ও দল-জোড়া সমন্বয় কর দুটিই কমায়। বাইরের ক্লায়েন্টসহ প্রায় যেকোনো সিস্টেমের জন্য একটি গেটওয়ে দ্রুত নিজের দাম তোলে।

সার্ভিস মেশের একটি সূক্ষ্মতর ব্যবসায়িক যুক্তি আছে, কারণ তার মালিকানার মোট খরচ প্রকৃত ও চলমান। আপনি প্রক্সির কম্পিউট ও লেটেন্সির জন্য, কন্ট্রোল প্লেন চালানো ইঞ্জিনিয়ারদের জন্য, এবং একটি নতুন স্তর ডিবাগ করার শেখার বক্ররেখার জন্য দাম দেন। সেই খরচ যথার্থ যখন বিকল্প (mTLS, রিট্রাই ও টেলিমেট্রির প্রতি-সার্ভিস, প্রতি-ভাষা বাস্তবায়ন) বড় এবং, আরও খারাপ, এমনভাবে অসঙ্গত যা নিরাপত্তা ফাঁক ও বিভ্রাট তৈরি করে। উচ্চ পরিসরে মেশ শত ভঙ্গুর হাতে-ঘোরানো সমাধানকে একটি অভিন্ন, প্রমাণযোগ্য সমাধানে রূপান্তর করে, এবং ROI দেখা দেয় কম নিরাপত্তা ঘটনা, ট্রাফিক সরানোর মাধ্যমে দ্রুততর নিরাপদ ডিপ্লয়মেন্ট এবং নাটকীয়ভাবে ভালো অবজার্ভেবিলিটিতে। সেই পরিসরের নিচে সৎ হিসাব প্রায়ই লাইব্রেরি ও একটি গেটওয়ের পক্ষে, এবং শৃঙ্খলাবদ্ধ পদক্ষেপ হলো অপেক্ষা করা। নেতৃত্বের কাছে যুক্তি দিতে গেটওয়েকে তাঁরা ইতিমধ্যে অনুসরণ করা মেট্রিকের সঙ্গে যুক্ত করুন (দুর্বলতা সারানোর সময়, নিরীক্ষা খরচ, API সমন্বয় বাড়তি বোঝা) এবং মেশকে নিরাপত্তা ঘটনা সীমিতকরণ, ডিপ্লয়মেন্ট নিরাপত্তা, এবং সে যে বহুভাষী নকল প্রতিস্থাপন করে তার খরচের সঙ্গে যুক্ত করুন।

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• প্রয়োজনের আগে মেশ: হাতে-গোনা সার্ভিসে পূর্ণ সার্ভিস মেশ গ্রহণ, আপনার এখনো নেই এমন সমস্যা সমাধানে একটি কন্ট্রোল প্লেন কেনা।
• দ্বিগুণ রিট্রাই: গেটওয়ে ও মেশ দুটিই রিট্রাই করে, তাই একটি ক্লায়েন্ট কল ব্যাকএন্ড রিট্রাই ঝড়ে গুণ হয় যা বিভ্রাট বাড়ায়।
• টাইমআউট উল্টানো: ভেতরের টাইমআউট বাইরেরটির চেয়ে দীর্ঘ, তাই কলার হাল ছাড়ে যখন কলি কেউ পড়বে না এমন সাড়ার ওপর কাজ করতে থাকে।
• মনোলিথ হিসেবে গেটওয়ে: গেটওয়েতে ব্যবসায়িক যুক্তি ঠাসা যতক্ষণ না তা এমন ভাগ করা বাধা হয় যা বদলাতে প্রতিটি দলকে সমন্বয় করতে হয়।
• একক ব্যর্থতার বিন্দু: বাড়তি ব্যবস্থা ছাড়া একটি গেটওয়ে ইনস্ট্যান্স চালানো, তাই সামনের দরজা ব্যর্থ হলে পেছনের প্রতিটি সার্ভিস নামে।
• নেটওয়ার্কে বিশ্বাস: পরিসীমার ভেতরের সবকিছু নিরাপদ গণ্য করা, তাই একটি আপসকৃত সার্ভিস পার্শ্বদিকে সরে সবকিছুতে পৌঁছাতে পারে।
• ওভারল্যাপিং মালিকানা: কোনো লিখিত শ্রম বিভাজন নেই, তাই একই উদ্বেগ দুর্ঘটনাবশত দুই স্তরে সামলানো এবং কেউ জানে না কোনটি কর্তৃত্বপূর্ণ।
• BFF বিস্তার: ক্লায়েন্টরা একই জিনিস চাইলেও প্রতিটির জন্য একটি ব্যাকএন্ড ফর ফ্রন্টএন্ড ঘুরিয়ে তোলা, কোনো লাভ ছাড়া গেটওয়ে গুণ করা ও যুক্তি নকল করা।
• সাইডকার কর উপেক্ষা: কম্পিউট ও লেটেন্সি বাড়তি বোঝা না মেপে হাজার হাজার সাইডকার ডিপ্লয়, তারপর বাজেট কোথায় গেল ভাবা।

পরিপক্বতা মডেল

• স্তর ১, সূচনা: সার্ভিস কোনো ভাগ করা স্তর ছাড়া সরাসরি একে অন্যের সঙ্গে কথা বলে। প্রমাণীকরণ, রিট্রাই ও টাইমআউট প্রতি সার্ভিসে হাতে-কোড করা ও অসঙ্গত। অভ্যন্তরীণ ট্রাফিক প্রায়ই প্লেইনটেক্সট এবং নেটওয়ার্কে থাকার জন্য বিশ্বস্ত, এবং নীতি প্রয়োগ বা ট্রাফিক পর্যবেক্ষণের একক জায়গা নেই। সিদ্ধান্ত প্রতিক্রিয়াশীল, সমস্যা দেখা দিলে সার্ভিস ধরে ধরে নেওয়া।
• স্তর ২, বিকাশ: একটি API গেটওয়ে বাইরের ট্রাফিকের সামনে বসে এবং প্রমাণীকরণ, হার সীমাবদ্ধকরণ ও রাউটিং কেন্দ্রীভূত করে, কিন্তু পূর্ব-পশ্চিম উদ্বেগ অসম গ্রহণসহ ভাগ করা লাইব্রেরি সামলায়। কিছু সার্ভিসে mTLS আছে; অনেকটিতে নেই। দলগুলো উত্তর-দক্ষিণ বনাম পূর্ব-পশ্চিম পার্থক্য চেনে, তবু মালিকানা অনানুষ্ঠানিক এবং চর্চা দল ভেদে ভিন্ন।
• স্তর ৩, মানসম্মতকরণ: উত্তর-দক্ষিণ ও পূর্ব-পশ্চিম উদ্বেগ পরিচ্ছন্নভাবে আলাদা, প্রতিষ্ঠান জুড়ে প্রয়োগ করা একটি লিখিত শ্রম বিভাজনসহ। গেটওয়ে বাইরের পরিচয়, কোটা ও সংযোজনের মালিক; একটি মেশ বা সামঞ্জস্যপূর্ণ লাইব্রেরি স্তর অভ্যন্তরীণ mTLS, রিট্রাই ও টেলিমেট্রির মালিক। ওভারল্যাপ সমাধান করা যাতে কোনো উদ্বেগ দ্বিগুণ-সামলানো নয়, অভ্যন্তরীণ ট্রাফিক ডিফল্টে এনক্রিপ্টেড ও পরিচয়-পরীক্ষিত, এবং মান নথিবদ্ধ ও প্রয়োগ করা, প্রতিটি দলের বিবেচনায় ছেড়ে না দিয়ে।
• স্তর ৪, ব্যবস্থাপনা: ট্রাফিক স্তর ভিত্তিরেখার বিপরীতে মাপা ও নিয়ন্ত্রিত। আপনি কম্পিউট ও প্রতি-হপ লেজের লেটেন্সিতে সাইডকার কর, ত্রুটি বাজেটের বিপরীতে গেটওয়ে ও মেশ উপলব্ধতা, রিট্রাই-বিবর্ধন ও টাইমআউট-উল্টানো ঘটনা, অভ্যন্তরীণ কলের শতাংশ হিসেবে mTLS কভারেজ, এবং বহর জুড়ে একটি নীতি পরিবর্তন ঠেলতে সময় অনুসরণ করেন। মেট্রিক সিদ্ধান্ত গেট করে: একটি প্রক্সি আপগ্রেড, একটি নতুন রিট্রাই বাজেট বা একটি ক্যানারি নিয়ম সহজাত বোধের বদলে ভিত্তিরেখার বিপরীতে তথ্যে বিচার করা হয়, এবং মান থেকে যেকোনো সরে যাওয়া একটি সমাধান ট্রিগার করে।
• স্তর ৫, সমন্বয়: গেটওয়ে ও মেশ একটি পরিণত শূন্য-আস্থা স্থাপত্যের নীতি প্রয়োগ বিন্দু, ক্লাস্টার ও অঞ্চল জুড়ে প্রতিটি হপে পরিচয় পরীক্ষিত। ট্রাফিক সরানো নিরাপদ ক্রমবর্ধমান সরবরাহ চালায়, অবজার্ভেবিলিটি অভিন্ন ও সমৃদ্ধ, এবং প্রতিষ্ঠান নিরন্তর সাইডকারবিহীন, প্রক্সিবিহীন ও eBPF পদ্ধতি মূল্যায়ন ও গ্রহণ করে যেখানে তারা ফল দেয়। ট্রাফিক স্তর নিরাপত্তা, সরবরাহ ও সক্ষমতা পরিকল্পনার সঙ্গে একীভূত, এবং পরিসর, ভাষা ও ঝুঁকির চিত্র সরলে খাপ খায়।

আলোচনার ভাবনা

1. আপনার একক API গেটওয়ে এখনই নেমে গেলে কয়টি সার্ভিস অপৌঁছানো হত, এবং সামনের দরজা বাড়তি ব্যবস্থাসহ করার আপনার পরিকল্পনা কী?
2. আপনার সিস্টেমের কোন উদ্বেগ বর্তমানে গেটওয়ে এবং একটি সার্ভিসে (বা একটি লাইব্রেরিতে) দুটিতেই সামলানো, এবং আপনি কীভাবে প্রমাণ করবেন তা দ্বিগুণ-সামলানো হচ্ছে না?
3. কতগুলো সার্ভিস ও ভাষায় আপনার দল একমত হবে যে একটি মেশ অবশেষে তার জটিলতা অর্জন করেছে, এবং আপনি সেই রেখা থেকে কত দূরে?
4. আগামীকাল একজন আক্রমণকারী একটি অভ্যন্তরীণ সার্ভিস আপস করলে সে আর কোন সার্ভিসে পৌঁছাতে পারত, এবং কোন পরিচয় পরীক্ষা তাকে থামাত?
5. সাইডকারবিহীন বা eBPF-ভিত্তিক মেশ পদ্ধতি কি আপনার প্ল্যাটফর্মের জন্য এখনই যথেষ্ট পরিণত, এবং সিদ্ধান্ত নিতে আপনি কী মাপবেন?
6. আপনার ভিন্নমুখী ক্লায়েন্টের প্রতিটির কি সত্যিই নিজস্ব ব্যাকএন্ড ফর ফ্রন্টএন্ড দরকার, নাকি আপনি ভাগ করে রাখা যেত এমন যুক্তি নকল করতে যাচ্ছেন?

প্রধান শিক্ষা

• উত্তর-দক্ষিণ ট্রাফিক (একটি API গেটওয়ে সামলায়) ও পূর্ব-পশ্চিম ট্রাফিক (একটি সার্ভিস মেশ সামলায়) আলাদা করুন; প্রতিটি নিজের দিকের মালিক, এবং এদের গুলিয়ে ফেলা দ্বিগুণ-সামলানো ঘটায়।
• একটি গেটওয়ে রাউটিং, প্রমাণীকরণ, অনুমোদন, হার সীমাবদ্ধকরণ, কোটা, অনুরোধ রূপান্তর, সংযোজন ও সংস্করণ কেন্দ্রীভূত করে, তাই সার্ভিস পাতলা থাকে এবং নীতি এক জায়গায় বাস করে।
• একটি সার্ভিস মেশ আপনাকে mTLS, ট্রাফিক সরানো, প্ল্যাটফর্ম-স্তরের রিট্রাই ও সার্কিট ব্রেকিং, এবং সার্ভিস কোড না বদলে অভিন্ন অবজার্ভেবিলিটি দেয়, ক্লাসিকভাবে সাইডকার প্রক্সির মাধ্যমে।
• মেশ গ্রহণ করুন কেবল যখন সার্ভিস ও ভাষার সংখ্যা প্রতি-সার্ভিস তারকে বেশি ব্যয়বহুল পথ করে; তার নিচে লাইব্রেরি ও একটি গেটওয়ে জেতে, এবং সাইডকার কর লক্ষ্য রাখার মতো প্রকৃত।
• গেটওয়ে ও মেশকে শূন্য-আস্থা স্থাপত্যের নীতি প্রয়োগ বিন্দু গণ্য করুন, প্রতিটি ক্রস-কাটিং উদ্বেগ ঠিক একটি স্তরে নির্ধারণ করুন, এবং ক্লাস্টার জুড়ে প্রতিটি হপে পরিচয় পরীক্ষা করুন।

তথ্যসূত্র ও আরও পড়ার জন্য

• Sam Newman, Building Microservices: Designing Fine-Grained Systems
• Chris Richardson, Microservices Patterns: With Examples in Java
• Lee Calcote ও Zack Butcher, Istio: Up and Running
• Ken Owens, Alois Reitbauer ও অন্যান্য; CNCF Cloud Native Landscape ও সার্ভিস মেশ ডকুমেন্টেশন
• Evan Gilman ও Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks
• Scott Rose, Oliver Borchert, Stu Mitchell ও Sean Connelly, Zero Trust Architecture, NIST Special Publication 800-207
• Susan Fowler, Production-Ready Microservices