ডাটাবেস কি Kubernetes বাস?

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

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

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

উজ্জ্বল দিক

লাইট সাইডের যুক্তি সংক্ষেপে একটি বাক্যাংশে বর্ণনা করা যেতে পারে: "হ্যালো, 2k19 জানালার বাইরে আছে!" এটি অবশ্যই পপুলিজমের মতো শোনাচ্ছে, তবে আপনি যদি পরিস্থিতিটি বিশদভাবে অনুসন্ধান করেন তবে এর সুবিধা রয়েছে। এখন তাদের বাছাই করা যাক.

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

এটা ঠিক, তথ্য. যেকোন প্রকল্পের মূল হল এর ডেটা: এটি হয় একটি সাধারণ DBMS - MySQL, Postgre, MongoDB, অথবা অনুসন্ধানের জন্য ব্যবহৃত স্টোরেজ (ElasticSearch), ক্যাশিং-এর জন্য কী-মান স্টোরেজ - উদাহরণস্বরূপ, redis, ইত্যাদি হতে পারে। বর্তমানে আমরা নেই খারাপভাবে লিখিত প্রশ্নের কারণে ডাটাবেস ক্র্যাশ হলে আমরা কুটিল ব্যাকএন্ড বাস্তবায়ন বিকল্পগুলি সম্পর্কে কথা বলব, এবং পরিবর্তে আমরা ক্লায়েন্ট লোডের অধীনে এই ডাটাবেসের ত্রুটি সহনশীলতা নিশ্চিত করার বিষয়ে কথা বলব। সর্বোপরি, যখন আমরা আমাদের অ্যাপ্লিকেশনকে কন্টেইনারাইজ করি এবং যেকোন সংখ্যক ইনকামিং অনুরোধ প্রক্রিয়া করার জন্য এটিকে অবাধে স্কেল করার অনুমতি দিই, এটি স্বাভাবিকভাবেই ডাটাবেসের উপর লোড বাড়ায়।

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

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

আপনি একটি ক্যাচ বোধ হয়? আমরা k8s বা Swarm ব্যবহার করি লোড বিতরণ করতে এবং প্রধান ওয়েব সার্ভার ক্র্যাশ হওয়া এড়াতে, কিন্তু আমরা ডাটাবেসের জন্য এটি করি না। কিন্তু যদি ডাটাবেস ক্র্যাশ হয়ে যায়, তাহলে আমাদের পুরো ক্লাস্টার করা অবকাঠামোর কোনো মানে হয় না - খালি ওয়েব পেজগুলো কি ভালো যেগুলো ডাটাবেস অ্যাক্সেসের ত্রুটি ফিরিয়ে দেয়?

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

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

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

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

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

এবং এখন ডাটাবেস ক্লাস্টারিংয়ের বিরোধীদের মধ্যে পরিবর্তন করার সময়।

অন্ধকার দিক

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

সম্মত হন, যে প্রকল্পগুলির জন্য সত্যিই একটি পাত্রে একটি বেস প্রয়োজন সেগুলি সেরা মিলিং মেশিন অপারেটর দ্বারা এক হাতের আঙুলে গণনা করা যেতে পারে। বেশিরভাগ ক্ষেত্রে, এমনকি k8s বা Docker Swarm-এর ব্যবহারও অপ্রয়োজনীয় - প্রায়শই এই সরঞ্জামগুলি প্রযুক্তির সাধারণ হাইপ এবং লিঙ্গের ব্যক্তির মধ্যে "সর্বশক্তিমান" এর মনোভাবের কারণে সবকিছুকে ধাক্কা দেওয়ার জন্য অবলম্বন করা হয়। মেঘ এবং পাত্রে। ঠিক আছে, কারণ এখন এটি ফ্যাশনেবল এবং সবাই এটি করে।

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

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

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

ঠিক আছে. সম্ভবত প্রকল্পটির সত্যিই ক্লাস্টারিং প্রয়োজন, কিন্তু যদি স্টেটলেস অ্যাপ্লিকেশনগুলির সাথে সবকিছু পরিষ্কার হয়, তাহলে আমরা কীভাবে একটি ক্লাস্টারড ডাটাবেসের জন্য শালীন নেটওয়ার্ক সংযোগ সংগঠিত করতে পারি?

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

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

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

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

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

পরিবর্তে আউটপুট

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

এমন প্রকল্প রয়েছে যার জন্য কুবারনেটিসের সাথে আসা নীতি এবং সরঞ্জামগুলি পুরোপুরি ফিট করে এবং এই জাতীয় প্রকল্পগুলিতে অন্তত ব্যাকএন্ড এলাকায় শান্তি রয়েছে। এবং এমন প্রকল্প রয়েছে যেগুলির কন্টেইনারাইজেশনের প্রয়োজন নেই, তবে একটি সাধারণ সার্ভার পরিকাঠামো, কারণ তারা মৌলিকভাবে মাইক্রোসার্ভিস ক্লাস্টার মডেলে পুনঃস্কেল করতে পারে না, কারণ তারা পড়ে যাবে।

উত্স: www.habr.com