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