در سالیان اخیر استفاده از معماری میکروسرویس بسیار رواج پیدا کرده است. مهاجرت یک سیستم نرم افزاری که به کمک معماری یکنواخت توسعه داده شده به به معماری میکروسرویس چالش هایی را به همراه دارد. در این تحقیق قصد داریم تا ابتدا علل مهاجرت به معماری میکروسرویس را به طور کامل بررسی و دسته بندی کنیم. سپس چالش هایی که در فرآیند مهاجرت از معماری یکنواخت به معماری میکروسرویس وجود دارد را به صورت شفاف بیان کرده و در نهایت 12 معیار برای اینکه آیا مهاجرت به معماری میکروسرویس به صرفه و منطقی است یا خیر را ارائه کنیم تا معمار نرم افزار بتواند به کمک پاسخ دادن به این سوالات یک تصمیم درست و با دید باز برای مهاجرت به معماری میکروسرویس بگیرد.
کلمات کلیدی: معماری نرم افزار ، میکروسرویس ، معماری یکنواخت ، مهاجرت به میکروسرویس
امروزه با بزرگتر شدن مقیاس نرم افزار ها استفاده از معماری میکروسرویس برای توسعه نرم افزار بسیار رایج شده است که این معماری مزایا و چالش های مختص خودش را دارد. از طرف دیگر برخی سیستم های نرم افزاری وجود دارند که از ابتدا، فرآیند توسعه نرم افزار را با معماری یکنواخت انجام داده اند و به دلایل مختلفی، از جمله مقیاس پذیری و سرعت توسعه بیشتر، قصد دارند تا به معماری میکروسرویس مهاجرت کنند. باید به این نکته توجه داشت که مهاجر به معماری میکروسرویس همیشه تصمیم درستی نیز و اگر قبل از مهاجرت یک سری تحقیق و تخمین از مشکلات پیش رو وجود نداشته باشد، نه تنها مهاجرت کمکی به بهبود نرم افزار نخواهد کرد، بلکه باعث هدر رفتن زمان و انرژی نیز خواهد شد.
این تحقیق از 3 بخش عمده تشکیل شده است. در بخش اول سعی کرده ایم تا به کمک مقالات موجود علل مهاجرت را بررسی کنیم. در این بخش خواهیم دید که چه عواملی باعث می شوند تا یک معمار نرم افزار تصمیم بگیرد که سیستم نرم افزاری را به سوی معماری میکروسرویس سوق دهد. در بخش دوم چالش هایی که معماری نرم افزار و توسعه دهندگان و حتی ذی النفعان با آن درگیر می شوند را بیان خواهیم کرد و نهایتا در بخش آخر، به توجه به این اطلاعات، یک سری معیار برای مهاجرت تعریف می کنیم. هر کدام این این معیار ها در واقع یک سوال هستند که معمار نرم افزار می تواند به آن ها پاسخ بدهد. پس از آن که این سوالات پاسخ داده شدند، یک شاخص یا امتیاز به دست خواهد آمد که پاسخ این سوال است: "مهاجرت یک سیستم نرم افزاری از معماری یکنواخت به معماری میکروسرویس، یه چه میزان منطقی و تصمیمی درست است؟"
تاکنون تحقیق ها زیادی بر روی علل مهاجرت به معماری میکروسرویس صورت گرفته است. در مرجع [1]، 20 تکنیک برای مهاجرت به معماری میکروسرویس بیان شده و گفته شده که مهم ترین چالش هنگام مهاجرت به معماری میکروسرویس، چالش های مربوط به پایگاه داده است. در مرجع [2] به انگیزه مدیران پروژه برای مهاجرت به معماری میکروسرویس اشاره شده و هم چالش هایی که در مهاجرت به معماری میکروسرویس وجود دارد معرفی شده است. در مرجع [3] به 2 سوال پاسخ داده شده است، سوال اول اینکه برای مهاجرت به معماری میکروسرویس چه اقداماتی باید انجام داد و سوال دوم اینکه چه چالش هایی هنگام مهاجرت به معماری میکروسرویس وجود دارد. همچنین در این مقاله نیز علل مهاجرت سیستم ها به معماری میکروسرویس بیان شده است. در مرجع [7]، مهاجرت به معماری میکروسرویس از جنبه های مختلف مورد بررسی قرار گرفته است و راهکار هایی در هر زمینه ارائه شده است. در مرجع [14] نیز ایتدا معماری میکروسرویس و اقدامات لازم برای نگهاری آن عنوان شده و سپس نحوه استقرار میکروسرویس ها به کمک Cloud و VM و Container ها ذکر شده و در نهایت مزایا و معایب روش های معروف موجود برای مهاجرت به معماری میکروسرویس به طور مفصل بیان شده است.
مهاجرت به معماری میکروسرویس علل و انگیزه های مختلفی دارد. این علل را می توان از جنبه های مختلفی بررسی کرد. اما به طور کلی با جمع بندی از مقالات موجود و بررسی یک پروژه عملی، علل زیر به دست آمد (به ترتیب از مهم ترین):
3.1: افزایش سرعت توسعه: هنگامی که مقیاس یک پروژه نرم افزاری که با معماری یکنواخت توسعه داده شده بزرگ می شود، ایجاد تغییر نیز به همان نسبت سخت تر می شود. چون وقتی می خواهیم یک تغییر را در پروژه به وجود بیاوریم، باید به جنبه های مختلف آن پروژه نگاه کنیم و از تعداد زیادی از افراد تایید بگیریم که این یک فرآیند زمان گیر است. اما وقتی این سیستم به چند سیستم کوچک تر یا اصطلاحا میکروسرویس تقسیم می شود، توسعه دهندگان می توانند به صورت تیم های جدا از هم و بر روی بخش های کوچک تری از پروژه کار کنند که این به فرآیند توسعه نرم افزار سرعت می بخشد و همچنین در این حالت شاهد اختلافات و دعوا های کمتری میان توسعه دهندگان هستیم.
3.2: امکان خلاقیت بیشتر: وقتی از معماری یکنواخت استفاده می کنیم، کل پروژه با یک زبان خاص نوشته شده است، اما در معماری میکروسرویس می توان از چندین زبان و تکنولوژی در یک زمان بهره برد. به عنوان مثال یک پروژه نرم افزاری را در نظر بگیرید که با زبان Java نوشته شده و از پایگاه داده Oracle استفاده می کند. مدیران فنی این پروژه پس از مدتی تصمیم می گیرند که برای قسمتی از پروژه شان از هوش مصنوعی استفاده کنند. طبیعتا استفاده از هوش مصنوعی به کمک پایتون بسیار رایج تر و منطقی تر است، لذا یک میکروسرویس به وجود می آید که به زبان پایتون نوشته شده است و عملیات مربوط به هوش مصنوعی را انجام می دهد و با این سیستم اولیه در ارتباط خواهد بود. به طور کلی وقتی از معماری میکروسرویس استفاده می کنیم، به یک زبان یا تکنولوژی خاص محدود نمی شویم. مثلا یک میکروسرویس با Java و یکی با C# و یکی دیگر با Python توسعه داده شده (ولی در عین حال نیز به کمک پروتکل هایی مانند صف یا REST با هم در ارتباط هستند). این امر باعث می شود تا توسعه دهندگان در هر تیم بتوانند خلاقیت بیشتری در آن زبان و تکنولوژی از خودشان داشته باشند و از مزایای تمام زبان های برنامه نویسی بهره ببرند، چرا که به صورت تخصصی با آن زبان و تکنولوژی آشنایی دارند.
3.3: افزایش مقیاس پذیری: مقیاس پذیری به این معناست که یک سیستم نرم افزاری چه میزان توانایی دارد که خودش را با نیاز های جدید مطرح شده از جمله درخواست کارآیی یا منابع بیشتر وفق دهد. وقتی به معماری میکروسرویس مهاجرت می کنیم، امکان استفاده از فضای ابری و استقرار میکروسرویس ها بر بستر ابر یا VM معنای بیشتری پیدا می کند. به این صورت راحت تر می توان منابع را مدیریت کرد. به عنوان مثال وقتی از معماری یکنواخت استفاده می کردیم، اگر یک قسمت از برنامه تعداد درخواست زیادی داشت مجبور بودیم تا کل سرور را ارتقا دهیم، ولی وقتی به همعماری میکروسرویس مهاجرت کنیم، می توانیم به صورت On Demand هر لحظه که اراده کنیم منابع ابری را برای هر میکروسرویسی کم یا زیاد کنیم. به این صورت اگر مثلا تعداد کاربران یک سامانه زیاد شود، منابع مروبط به میکروسرویس منابع انسانی را ارتقا می بخشیم. به طور کلی وقتی به معماری میکروسرویس مهاجرت می کنیم چون از منابع به صورت اشتراکی استفاده نمی شود، کارآیی بیشتر خواهد بود.
3.4: کاهش قطعی کل سیستم: تصور کنید که یک نرم افزار با معماری یکنواخت نوشته شده است و میخواهیم تغییر کوچکی در یکی از بخش های آن ایجاد کنیم. اگر این پروژه شامل حجم زیادی از کد ها و کتابخانه ها باشد، build گرفتن از آن و سپس استقرار و جایگزینی آن با نسخه قبلی بسیار زمان بر خواهد بود که در این مدت زمان سیستم قطع خواهد شد. ولی وقتی به معماری میکروسرویس مهاجرت می کنیم، این به روز رسانی ها در داخل هر کدام از میکروسرویس ها که حاوی حجم کمتری کد و کتابخانه هستند اتفاق می افتد و می توان سریع تر عملیات استقرار را انجام داد. همچنین اگر در معماری یکنواخت بخشی از سیستم دچار خرابی شود، آن خرابی به کل سیستم سرایت کرده و باعث می شود تا کل سیستم دچار قطعی شود، اما در معماری میکروسرویس اگر یک میکروسرویس دچار خرابی بشود سایر میکروسرویس ها می توانند به فعالیت خود ادامه بدهند.
3.5: عیب یابی آسان تر: در بسیاری از پروژه های نرم افزاری، بودجه هایی برای بخش آزمون و اشکال زدایی نرم افزار تخصیص داده می شود. وقتی از معماری یکنواخت برای توسعه نرم افزار استفاده شده است، گاها حتی این بودجه کم هم می آید و پاسخگوی تمام نیاز ها در این حوزه نیست. لذا مدیران پروژه تصمیم می گیرند تا یک بار و یک هزینه کلی را صرف مهاجرت به معماری میکروسرویس انجام دهند تا پس از آن فرآیند آزمون و اشکل زدایی سریع تر و ارزان تر بشود. از آن جا که در معماری میکروسرویس نقش هر میکروسرویس کاملا مشخص است و میکروسرویس ها به صورت مستقل از هم فعالیت می کنند، عیب یابی کار راحت تری است و همچنین آزمون نرم افزار نیز می تواند به صورت همزمان بر روی میکروسرویس های متخلف در آن واحد انجام بگیرد.
3.6: مستند سازی شفاف تر: در برخی از متدلوژی های توسعه نرم افزار مانند RUP، مستندات مختلف مانند SAD یا SRS یا ... دارای ارزش بسیار بالایی هستند. وقتی از معماری یکنواخت استفاده می شود، معمولا مستند سازی بخش های مختلف را یک نفر انجام می دهد و نهایتا نیز یک مستند طولانی از بخش های مختلف یک پروژه واحد حاصل می شود. این امر باعث می شود تا برخی از مدیران به فکر بیوفتند که به معماری میکروسرویس مهاجرت کنند تا پس از مهاجرت بتوانند آرشیوی از مستندات کامل تر و تمیز تر در بخش های مختلف نرم افزار یا همان میکروسرویس ها داشته باشند. در واقع به جای یک مستند طولانب و خسته کننده، هر میکروسرویس یک مستند مختصر و مفید خواهد داشت که در آن فقط خودش را توصیف می کند. ذکر این نکته نیز حائز اهمیت است که اکثر سامانه هایی که با معماری یکنواخت توسعه داده می شودند اصلا مستند ندارند.
علت هایی که ذکر شدند را می توان از مهم ترین علت ها مهاجرت به معماری میکروسرویس دانست، گرچه علل دیگری نیز وجود دارند اما به ذکر همین 6 علت عمده و مهم کفایت می کنیم.
هنگامی که تصمیم به مهاجرت به معماری میکروسرویس گرفته می شود، فرآیند مهاجرت آغاز می شود. در این فرآیند مهاجرت چالش های زیادی وجود دارد که می توان آن ها را به دو دسته ی کلی: "چالش های فنی" و "چالش های سازمانی" تقسیم کرد. هر کدام از این دو دسته شامل یک سری زیر دسته هم می شوند که در ادامه با هم خواهیم دید:
در فرآیند مهاجرت به معماری میکروسرویس چالش های فنی زیادی وجود دارد که حل آن ها نیازمند افراد متخصص و دانش فنی مربوط به آن حوزه است. برخی از مهم ترین این چالش های فنی عبارت اند از:
4.1.1 مهاجرت پایگاه داده: از آن جا که فلسفه معماری میکروسرویس این است که هر میکروسرویس باید پایگاه داده مختص خودش را داشته باشد و فقط خود آن میکروسرویس به آن پایگاه داده دسترسی دارد، شاید مهم ترین و سخت ترین کار در هنگام مهاجرت از معماری یکنواخت به معماری میکروسرویس، تجزیه یک پایگاه داده به چند پایگاه داده باشد. در حین مهاجرت باید به این نکته نیز توجه داشت که ممکن است چنس پایگاه داده های میکروسرویس های مختلف با هم فرق داشته باشد، در صورتی که در معماری یکنواخت فقط یک پایگاه داده داشتیم که تمام داده ها در آن ذخیره می شد. به عنوان مثال ممکن است پایگاه داده نرم افزار اولیه که با معماری یکنواخت توسعه داده شده از جنس SQL Server بوده باشد و حالا تصمیم گرفته ایم که نرم افزار اولیه را به سه میکروسرویس، که یکی با پایگاه داده MySql و دیگری با MongoDB و دیگری با Oracle کار میکند بشکنیم. به طور کلی انتقال داده ها و همچنین Sync بودن داده ها با یکدیگر و وجود جامعیت بین داده های توزیع شده در پایگاه داده های مختلف یک کار چالش برانگیز است که نیازمند دانش فنی متخصصان این حوزه است.
4.1.2 خرد کردن کد اصلی برنامه: منظور از خرد کردن کد اصلی برنامه در واقع همان مشخص کردن boundary ها و شناسایی سرویس های مختلف و پیاده سازی مجدد آن ها در قالب میکروسرویس های مختلف است. یکی از بزرگترین چالش ها هنگام مهاجرت به معماری میکروسرویس، شکستن کد برنامه اصلی به چند بخش می باشد. برای این کار باید از روابط موجود میان کلاس ها و مفهوم تمام قطعه کد های برنامه اولیه آگاه باشیم. حتی در شرایطی ممکن است هنگام مهاجرت تبدیل زبان نیز داشته باشیم، یعنی به عنوان مثال نرم افزار اولیه که با معماری یکنواخت توسعه داده شده است با زبان #C نوشته شده است اما یکی از میکروسرویس ها قرار است با زبان پایتون کار کند، در این حالت باید آن کد #C را به پایتون تبدیل کنیم که خود امری چالش برانگیز است.
4.1.3 ارتباط میان میکروسرویس ها: پس از مهاجرت به معماری میکروسرویس، چندین پروژه نرم افزاری با مقیاس کوچک تر به وجود می آیند که قبلا در قالب یک پروژه بزرگ با یکدیگر در ارتباط بودند. ارتباط آن ها در یک پروژه واحد به سادگی پیاده سازی شده بود، مثلا کلاس های مختلف یکدیگر را صدا می زند، و یا داده ای را در پایگاه داده مشترک بینشان ذخیره یا به روز رسانی می کردند. اما سوال که به وجود می آید این است که پس از مهاجرت به معماری میکروسرویس، این میکروسرویس ها چگونه باید با یکدیگر ارتباط برقرار کنند؟ در پاسخ باید گفت که برای این منظور را ههای مختلفی از جمله استفاده از پروتکل هایی مانند REST یا SOAP و یا پروتکل های پیام رسانی وجود دارد. این که میکروسرویس ها باید از کدام یک از این پروتکل ها استفاده کنند تصمیمی است که معمار نرم افزار با توجه به شرایط موجود می گیرد. اما به طور کلی اگر فراخوانی بین میکروسرویس ها خیلی زیاد باشد بهتر است تا از پروتکل های مبتنی بر صف و فناوری های مربوط به آن حوزه استفاده کرد تا کارآیی کم نشود.
4.1.4 مدیریت منابع: هنگامی که از معماری یکنواخت استفاده می شد، تمام قسمت های مختلف برنامه از یک سری منابع اشتراکی محدود و واحد استفاده می کردند. اما وقتی تصمیم می گیریم که به معماری میکروسرویس مهاجرت کنیم، منابع باید یه نوعی بین میکروسرویس ها پخش شوند تا همه میکروسرویس ها در بستر آن منابع بتوانند بهترین عملکرد خودشان را داشته باشند. برای این بخش استفاده از فضاهای ابری که می توان منابع را به صورت نرم افزاری مدیریت کرد پیشنهاد می شود.
4.1.5 مشکلات امنیتی: وقتی میکروسرویس ها به صورت توزیع شده و جدا از هم کار می کنند و با هم از طریق پروتکل های مختلف در ارتباط هستند، یک سری مشکلات امنیتی به وجود می آید که از قبل وجود نداشت. اغلب این مشکلات امنیتی هنگام برقراری ارتباط بین میکروسرویس ها است. بسیاری از سازمان ها به این موضوع توجه نمی کنند و سطوح دسترسی مشخصی را برای اعضا و تیم ها تعریف نمی کنند و هر کس می تواند از هر گونه API ای استفاده کند که این باعث پیدایش رخنه امنیتی در سیستم می شود.
جدای از مسائل فنی در مهاجرت به معماری میکروسرویس، یک سری مشکلات در سطح سازمان وجود دارد که به آن ها می پردازیم.
4.2.1 تغییر تفکر سازمانی: در بسیاری از مواقع وقتی یک سازمان تصمیم می گیرد که به معماری میکروسرویس مهاجرت کند، متدلوژی توسعه نرم افزار را نیز تغییر می دهد. مثلا تا قبل از مهاجرت به معماری میکروسرویس از متدلوژی سنتی آبشاری استفاده می کرده است اما پس از مهاجرت تصمیم گرفته است تا از متدلوژی Agile که با معماری میکروسرویس همخوانی زیادی دارد استفاده کند. در این حالت تمام اعضای تیم ها باید آموزش های مربوط به متدلوژی و فرهنگ جدید را ببینند، در غیر این صورت نمی توانند نیروی کارآمدی باشند. در بسیاری از موارد، اعضای سازمان از یادگیری مفاهیم جدید خودداری می کنند و ترجیح می دهند که دیگر در آن تیم کار نکنند. در مواردی هم آموزش برخی اعضا بسیار زمان بر و فرسایشی می شود.
4.2.2 تقسیم بندی وظایف: وقتی تصمیم به مهاجرت به معماری میکروسرویس گرفته می شود، اشخاص و متخصصانی که در یک تیم واحد بزرگ کار می کردند باید به تیم های کوچک و چابک تقسیم بشوند. همچنین باید یک نوع تقسیم بندی وظایف بین این افراد صورت بگیرد تا نقش هر شخص در هر تیم مشخص شود. در بسیاری از موارد در هنگام همین تقسیم بندی وظایف دعواهایی پیش می آید که باعث استعفای کارمندان نیز می شود و جایگزین کردن نیروی جدید به جای آن شخص فرآیندی زمان بر است.
در این بخش سعی کردیم تا چالش هایی که هنگام مهاجرت به معماری میکروسرویس وجود دارند را بیشتر بشناسیم تا بتوانیم با دید بازتری به قسمت بعد برویم و برای مهاجرت یا عدم مهاجرت تصمیم گیری کنیم.
در این بخش 12 سوال مطرح شده است که به هر کدام از این سوال ها یک پاسخ که یک عدد بین 0 تا 4 است داده می شود و در نهایت یک عدد بین 0 تا 48 به دست می آید. این فرم باید توسط معمار نرم افزار پاسخ داده شود. تفسیر نتیجه و این که آیا مهاجرت به معماری میکروسرویس به صلاح و به نفع سازمان است یا خیر در انتهای سوالات آمده است.
سوال 1: پیاده سازی یک تغییر در پروژه فعلی چقدر زمان می برد؟
0: زمان بسیار کمی می برد.
1: زمان نسبتا کمی می برد.
2: زمان معقول و استانداردی را می برد.
3: زمان نسبتا زیادی می برد.
4: زمان بسیار زیادی می برد.
سوال 2: پیاده سازی یک تغییر در پروژه فعلی چقدر هزینه می برد؟
0: هزینه بسیار کمی می برد.
1: هزینه نسبتا کمی می برد.
2: هزینه معقول و استانداردی را می برد.
3: هزینه نسبتا زیادی می برد.
4: هزینه بسیار زیادی می برد.
سوال 3: مولفه های نرم افزاری که سامانه اصلی را تشکیل می دهند چه میزان به هم وابستگی دارند؟
0: بسیار کم.
1: نسبتا کم.
2: متوسط.
3: نسبتا زیاد.
4: بسیار زیاد.
سوال 4: دانش فنی اعضای تیم توسعه در چه سطحی قرار دارد؟
0: بسیار خوب.
1: نسبتا خوب.
2: متوسط.
3: نسبتا ضعیف.
4: بسیار ضعیف.
سوال 5: در حال حاضر چه تعداد ویژگی جدید (یا تغییر) در حال پیاده سازی روی این سامانه است؟
0: هیچ قابلیت جدیدی در حال پیاده سازی نیست.
1: یک یا دو قابلیت جدید در حال پیاده سازی هستند.
2: بین سه تا پنج قابلیت جدید در حال پیاده سازی هستند.
3: بین شش تا ده قابلیت جدید در حال پیاده سازی هستند.
4: بیش از ده قابلیت جدید در حال پیاده سازی هستند.
سوال 6: آیا توسعه دهندگان و کارمندان با معماری میکروسرویس آشنایی دارند؟
0: بله کاملا اشنا هستند.
1: اکثر آن ها کمی با معماری میکروسرویس آشنا هستند.
2: تقریبا نیمی از آن ها با معماری میکروسرویس آشنایی دارند.
3: برخی از آن ها کمی با معماری میکروسرویس آشنا هستند.
4: خیر هیچ گونه آشنایی ندارند و نیاز به آموزش های زیادی در این زمینه وجود دارد.
سوال 7: آیا بستر های لازم برای مهاجرت وجود دارد؟ (مثلا فضای ابر تهیه شده یا ...)
0: بله تمامی بستر های لازم برای مهاجرت فراهم شده اند.
1: اکثر بستر ها فراهم شده و تهیه برخی بستر ها در دست اقدام می باشد.
2: نیمی از بستر ها فراهم شده و تهیه نیمی دیگر در دست اقدام می باشد.
3: برخی بستر ها فراهم شده و تهیه اکثر بستر ها در دست اقدام می باشد.
4: خیر هیچ بستری برای مهاجرت فراهم نشده است.
سوال 8: آیا نقش ها و مسوولیت تیم های مشخص شده است؟
0: بله تمامی نقش ها و مسوولیت ها مشخص هستند.
1: اکثر نقش ها و مسوولیت ها مشخص شده اند.
2: نیمی از نقش ها و مسوولیت ها مشخص شده اند.
3: برخی از نقش ها و مسوولیت ها مشخص شده اند.
4: خیر هنوز تصمیمی در این باره گرفته نشده است.
سوال 9: نرم افزار کنونی چقدر قدمت دارد؟
0: کمتر از 2 سال.
1: بین 2 تا 4 سال.
2: بین 5 تا 7 سال.
3: بین 8 تا 10 سال.
4: بیش از 10 سال.
سوال 10: آیا نوع زبان برنامه نویسی و فناوری های میکروسرویس ها امشخص شده اند؟
0: بله زبان ها و فناوری های میکروسرویس ها تمام و کمال مشخص شده اند.
1: چندین زبان ها و فناوری ها انتخاب شده اند و برای استفاده از آن ها اطمینان نسبی وجود دارد.
2: برخی زبان ها و فناوری ها انتخاب شده اند و برای استفاده از آن ها اطمینان نسبی وجود دارد.
3: تعداد کمی زبان ها و فناوری ها انتخاب شده اند و تصمیمی گرفته نشده است.
4: خیر هیچ گونه تصمیم یا تحقیقی در این زمینه گرفته نشده است.
سوال 11: آیا میکروسرویس ها به صورت حدودی شناسایی شده اند؟
0: بله تمامی میکروسرویس ها به طور دقیق شناسایی شده اند.
1: اکثر میکروسرویس ها شناسایی شده و تعداد کم باقی مانده در در حال بحث می باشند.
2: تقریبا نیمی از آن ها شناسایی شده و نیمی دیگر نیز در حال بحث و مناظره می باشند.
3: تعداد کمی (در حد یک یا دو) میکروسرویس شناسایی شده و عمده آن ها شناسایی نشده اند.
4: خیر هیچ تحلیل و اقدامی برای شناسایی میکروسرویس ها صورت نگرفته است.
سوال 12: آیا پروتکل های ارتباطی میان میکروسرویس ها (مثل REST یا صف) مشخص شده اند؟
0: بله پروتکل ها به صورت دقیق و واضح مشخص شده اند.
1: اکثر پروتکل ها مشخص شده اند و مابقی نیز در حال مشخص شدن هستند.
2: تقریبا نیمی از پروتکل های ارتباطی مشخص شده اند.
3: برخی پروتکل ها مشخص شده اند و اکثر آن ها هنوز مشخص نشده اند.
4: خیر هنوز هیچ تصمیمی درباره نوع پروتکل های ارتباطی گرفته نشده است.
برای نتیجه گیری باید اعداد را با هم جمع کرد که تفسیر عدد حاصل جمع به شرح زیر است:
بین 0 تا 12: مهاجرت به معماری میکروسرویس احتمالا بدون هیچ مشکل و خرج اضافه انجام خواهد شد و می توان از همین الان فرآیند مهاجرت را با در نظر داشتن چالش های احتمالی پیش رو شروع کرد.
بین 13 تا 24: مهاجرت به معماری میکروسرویس با مشکلات جزیی همراه خواهد بود که وجود متخصصین ماهر در زمینه میکروسرویس ها کمک می کند تا این موانع و مشکلات در حین مهاجرت کمرنگ تر شوند. بهتر است در حین مهاجرت یک سری مرور های فنی و به صورت دوره ای انجام بگیرد.
بین 25 تا 36: مهاجرت به معماری میکروسرویس با ریسک بالایی همراه است و توصیه می شود اگر سیستم کنونی مشکل خاصی ندارد با همان ادامه داده شود در غیر این صورت حتما قبل از مهاجرت باید یک تیم شامل متخصصین در حوزه میکروسرویس تشکیل شود که تمام انرژی خود را روی مهاجرت می گذارند و ریسک های مهاجرت را بررسی و پوشش می دهند.
بین 37 تا 48: مهاجرت به معماری میکروسرویس در مقطع کنونی اصلا به صلاح نیست و نه تنها باعث سود نمی شود، بلکه به سازمان ضررهای عمده نیز وارد می کند. این سیستم هم اکنون توانایی تبدیل شدن به چند سرویس را ندارد و باید یک بازنگری در تصمیم در خصوص مهاجرت بشود.
گرچه لازم به ذکر است که می توان دسته بندی های دیگری نیز روی عدد بدست آمده داشت اما آن چه مهم است عددی است که نهایتا به دست می آید که یک دید کلی به معمار نرم افزار می دهد.
در این تحقیق سعی کردیم تا ابتدا علل مهاجرت به معماری میکروسرویس را بیان کرده و سپس چالش های موجود در فرآیند مهاجرت به معماری میکروسرویس را از جنبه های مختلف با هم بررسی کنیم. در نهایت 12 سوال ارائه کردیم که معمار نرم افزار به کمک آن سوال ها می تواند یک تصمیم درست تری برای مهارت یا عدم مهاجرت به معماری میکروسرویس بگیرد. اما برای ادامه کار نیاز است تا پروژه های عملی بیشتری مورد بررسی قرار بگیرند تا این 12 معیار پخته تر و کامل تر بشوند و جواب نهایی به واقعیت نزدیک تر باشد.
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.
[1] Ponce, Francisco, Gastón Márquez, and Hernán Astudillo. "Migrating from monolithic architecture to microservices: A Rapid Review." 2019 38th International Conference of the Chilean Computer Science Society (SCCC). IEEE, 2019.
[2] Fritzsch, Jonas, et al. "Microservices migration in industry: intentions, strategies, and challenges." 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2019.
[3] Di Francesco, Paolo, Patricia Lago, and Ivano Malavolta. "Migrating towards microservice architectures: an industrial survey." 2018 IEEE International Conference on Software Architecture (ICSA). IEEE, 2018.
[4] Freire, Augusto Flávio AA, et al. "Migrating production monolithic systems to microservices using aspect oriented programming." Software: Practice and Experience 51.6 (2021): 1280-1307.
[5] Agarwal, Shivali, et al. "Monolith to Microservice Candidates using Business Functionality Inference." 2021 IEEE International Conference on Web Services (ICWS). IEEE, 2021.
[6] Desai, Utkarsh, Sambaran Bandyopadhyay, and Srikanth Tamilselvam. "Graph neural network to dilute outliers for refactoring monolith application." Proceedings of 35th AAAI Conference on Artificial Intelligence (AAAI’21). 2021.
[7] Newman, Sam. Monolith to microservices: evolutionary patterns to transform your monolith. O'Reilly Media, 2019.
[8] PoojaParnami, AmanJain, and Navneet Sharma. "From Monolith to Microservice Architecture." Journal of Network and Innovative Computing 5.2017: 020-024.
[9] Krause, Alexander, et al. "Microservice decomposition via static and dynamic analysis of the monolith." 2020 IEEE International Conference on Software Architecture Companion (ICSA-C). IEEE, 2020.
[10] Nunes, Luís, Nuno Santos, and António Rito Silva. "From a monolith to a microservices architecture: An approach based on transactional contexts." European Conference on Software Architecture. Springer, Cham, 2019.
[11] Mendonça, Nabor C., et al. "Developing self-adaptive microservice systems: Challenges and directions." IEEE Software 38.2 (2019): 70-79.
[12] Baškarada, Saša, Vivian Nguyen, and Andy Koronios. "Architecting microservices: Practical opportunities and challenges." Journal of Computer Information Systems (2018).
[13] Wang, Yingying, Harshavardhan Kadiyala, and Julia Rubin. "Promises and challenges of microservices: an exploratory study." Empirical Software Engineering 26.4 (2021): 1-44.
[14] Kazanavičius, Justas, and Dalius Mažeika. "Migrating legacy software to microservices architecture." 2019 Open Conference of Electrical, Electronic and Information Sciences (eStream). IEEE, 2019.
[15] Bogner, Justus, et al. "Assuring the evolvability of microservices: insights into industry practices and challenges." 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2019.
[16] Yarygina, Tetiana, and Anya Helene Bagge. "Overcoming security challenges in microservice architectures." 2018 IEEE Symposium on Service-Oriented System Engineering (SOSE). IEEE, 2018.
