আবদুআজিজ আবদুখালিমভ: "লিগ্যাসি সিস্টেমগুলি সাধারণত স্কেলের অধীনে ব্যর্থ হওয়ার আগে পরিবর্তনের অধীনে ব্যর্থ হয়।"

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

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

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

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

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

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

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

আপনি Open Data Challenge-এ প্রথম স্থান অধিকার করেছেন এবং আপনার ক্যারিয়ারের প্রথম দিকে Best Soft Challenge-এ শীর্ষ র‍্যাঙ্কিং পেয়েছেন। সেই অভিজ্ঞতাগুলি কীভাবে পরবর্তীতে বৃহৎ-স্কেল ইঞ্জিনিয়ারিং সমস্যাগুলির সাথে আপনার দৃষ্টিভঙ্গি গঠন করেছে?

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

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

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

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

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

Barso LLC-তে সিনিয়র ফুল-স্ট্যাক ডেভেলপার হিসাবে, আপনি একটি ক্লাউড-নেটিভ এন্টারপ্রাইজ প্ল্যাটফর্ম তৈরিতে সহায়তা করেছেন, যা সিস্টেম পারফরম্যান্স ৪০% উন্নত করেছে। সেই অভিজ্ঞতার উপর ভিত্তি করে, আপনি একটি Spring Boot পরিবেশে প্রায়শই কোন নীরব পারফরম্যান্স কিলার দেখেন?

অনেক পারফরম্যান্স সমস্যা অ্যালগরিদম দ্বারা নয় বরং আর্কিটেকচার সিদ্ধান্ত দ্বারা সৃষ্ট হয়।

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

আপনি ১,০০,০০০-এর বেশি সক্রিয় ব্যবহারকারীদের সেবা প্রদানকারী একটি প্ল্যাটফর্ম সমর্থন করার জন্য Apache Kafka এবং RabbitMQ ব্যবহার করে একটি ইভেন্ট-চালিত আর্কিটেকচার ডেভেলপ করেছেন, যা স্কেলেবিলিটি, ফল্ট টলারেন্স এবং সিস্টেম নির্ভরযোগ্যতা উন্নত করেছে। আপনার অভিজ্ঞতায়, কোন পরিস্থিতিতে ইভেন্ট-চালিত আর্কিটেকচার প্রকৃতপক্ষে রেজিলিয়েন্স এবং স্কেলেবিলিটি শক্তিশালী করে?

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

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

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

এমন পরিস্থিতি টিমগুলিকে নিখুঁত আর্কিটেকচারের উপরে স্থিতিশীলতা এবং অ্যাক্সেসযোগ্যতাকে অগ্রাধিকার দিতে বাধ্য করে।

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

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

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

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

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

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

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

তৃতীয়ত, প্রযুক্তিগত মডিউলের পরিবর্তে ব্যবসায়িক ডোমেনের উপর ভিত্তি করে সঠিক সার্ভিস সীমানা চিহ্নিত করুন। স্পষ্ট মালিকানা সিস্টেমগুলিকে রক্ষণাবেক্ষণ এবং স্কেল করা সহজ করে তোলে।

যখন সেই ভিত্তিগুলি স্থাপিত হয়, আধুনিকীকরণ একটি ঝুঁকিপূর্ণ লাফের পরিবর্তে একটি কাঠামোগত প্রক্রিয়া হয়ে ওঠে।