“শুধু নতুন করে লিখুন”: আধুনিকীকরণ নিয়ে প্ল্যাটফর্ম টিমগুলো আসলে কী ভাবে?

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

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

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

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

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

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

সবকিছু কুবারনেটিস/ক্লাউডে স্থানান্তর করার উদ্যোগও দুটি প্ল্যাটফর্ম ব্যবহার প্রতিরোধ করতে পারে না। এই ধরনের উদ্যোগগুলো প্রায়শই থমকে যায় কারণ কিছু ওয়ার্কলোড খাপ খায় না বা পরিকল্পনার চেয়ে অনেক বেশি সময় নেয়।

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

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

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

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

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

আসল ঘাটতিটি হলো অপারেশনাল

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

ঐতিহাসিকভাবে, ভিএম (VM) পরিবেশে দৈনন্দিন কার্যক্রম ইউআই (UI) চালিত হয়ে থাকে। ক্লাউড-নেটিভ পরিবেশগুলো অনেক বেশি কমান্ড-লাইন ইন্টারফেস (CLI) চালিত, যেখানে এপিআই (API), কনফিগারেশন ফাইল এবং টার্মিনালই হলো মূল কেন্দ্রবিন্দু। এই ব্যবধানটি একটি সাংগঠনিক এবং প্রযুক্তিগত উভয় প্রকারের সীমাবদ্ধতা হয়ে দাঁড়ায়। দলের সক্ষমতায় উল্লেখযোগ্য পরিবর্তন ছাড়া ইউআই-চালিত কার্যক্রম থেকে গভীর কমান্ড-লাইন ইন্টারফেস (CLI)/কনফিগারেশন ওয়ার্কফ্লোতে যাওয়াটা কোনো স্বাভাবিক পদক্ষেপ নয়।

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

আরেকটি উল্লেখযোগ্য পার্থক্য হলো স্টোরেজ ব্যবহারের ভিন্নতা:

ক্লাউড-নেটিভ অ্যাপগুলোর প্রায়শই একই সাথে একাধিক ধরনের স্টোরেজের প্রয়োজন হয়

ঐতিহাসিকভাবে ভিএম (VM) ওয়ার্কলোডগুলো সাধারণ ব্লক স্টোরেজের উপর নির্ভর করে

পাবলিক ক্লাউড, ক্লাউড-নেটিভ প্রত্যাশাগুলোকে প্রভাবিত করার মাধ্যমে, এই ব্যবধানকে আরও বাড়িয়ে তোলে। ডেভেলপাররা ক্লিক করেই একটি ডেটাবেস, যেমন অ্যামাজন রিলেশনাল ডেটাবেস সার্ভিস (RDS), পেতে পারেন এবং অবজেক্ট স্টোরেজ, যেমন অ্যামাজন সিম্পল স্টোরেজ সার্ভিস (S3), হাতের কাছেই থাকে। যখন এই প্ল্যাটফর্মগুলো পাবলিক ক্লাউডের বাইরে প্রসারিত হয়, তখন ডেভেলপাররা এই ধরনের সেলফ-সার্ভিস সরলতা আশা করেন, যার জন্য প্ল্যাটফর্ম টিমগুলো সবসময় প্রস্তুত থাকে না।

এজ (Edge) + এআই (AI) ফ্র্যাগমেন্টেশনকে একটি ব্যবসায়িক ঝুঁকিতে পরিণত করছে

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

এআই (AI) এই ঝুঁকিকে আরও বাড়িয়ে দেয়। আপনি যদি এজ (edge) থেকে ডেটা সংগ্রহ করেন, তবে প্রসেসিংয়ের জন্য তা বাইরে পাঠানো এবং ফলাফল ফিরিয়ে আনা খুব ধীর এবং ব্যয়বহুল হতে পারে।

কোনো প্ল্যাটফর্মের ওপর বাজি ধরার আগে আমাদের দাবি

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

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

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

পরিশেষে, আমরা প্যাচিং, আপগ্রেড এবং রক্ষণাবেক্ষণ সহ লাইফসাইকেল অপারেশনগুলো পুঙ্খানুপুঙ্খভাবে খতিয়ে দেখব, কারণ সপ্তাহান্তে ‘বিশেষ’ পরিশ্রমের কাজ কোনো টেকসই কৌশল নয়।

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

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

একটি দ্বৈত নেটিভ আর্কিটেকচার হিসেবে NKP এবং NKP Metal

Nutanix Kubernetes Platform (NKP) সলিউশন এবং NKP Metal, যা Nutanix অপারেটিং মডেল এবং NKP সলিউশনকে প্রসারিত করে, সরাসরি বেয়ার-মেটাল ইনফ্রাস্ট্রাকচারে Kubernetes ডেপ্লয়মেন্ট সমর্থন করে। এই সলিউশনটি একটি দ্বৈত নেটিভ প্ল্যাটফর্ম আর্কিটেকচারকে সমর্থন করার জন্য একীভূত Kubernetes অপারেশন, শেয়ার্ড ডেটা সার্ভিস, কেন্দ্রীভূত ভিজিবিলিটি এবং স্বয়ংক্রিয় বেয়ার-মেটাল লাইফসাইকেল ম্যানেজমেন্ট প্রদান করে।

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

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

এরপর কী?

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

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

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

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