معماری میکروسرویس و انتقال به آن


معماری میکروسرویس، یکی از معماری های شناخته شده و معروف در طراحی ساختار نرم افزار بوده و با وجود این که از سال های نسبتا دور وجود داشته، در سال های اخیر با پیشرفت ساختار های تحت کلاود (Cloud) و قابلیت های DevOps Automation به مراتب جذاب تر و پر استفاده تر شده و حداقل استفاده از کلمات و ادبیات مربوط به این معماری جزیی از روزمره مهندسان نرم افزار و معماران سیستم ها شده.

اما چه زمانی استفاده از معماری میکروسرویس در نرم افزار مفید است؟ چه پیش نیاز هایی برای پیاده سازی این معماری وجود دارد؟ و در صورت حرکت به سمت این معماری چه فرصت هایی بوجود می‌آید و چه مشکلاتی برای تیم ها و نرم افزار ها ممکن است ایجاد شود؟

چه وقتی معماری میکروسرویس برای استفاده مناسب است؟

پیاده سازی ابتدایی نرم افزار با معماری میکروسرویس! طمعی که خیلی ها که با این معماری آشنا هستند و قبلا مزایای آن رو تجربه کردند بهش دچار می‌شوند. اما قبل از گرفتن چنین تصمیمی باید نکات زیادی را در نظر گرفت. از جمله:

  • پیاده سازی معماری میکروسرویس نیازمند شناخت خوب و کامل از فضای مسئله یا همان ‌‌Business Domain هست و به همین خاطر لازم است که پیش از شروع زمان کافی صرف شناخت و تحلیل فضای مسئله و ساخت فضای راه حل بشود. به همین دلیل ابتدایی می‌توان با قطعیت خوبی مفید بودن استفاده از معماری میکروسرویس رو برای استارتاپ ها را رد کرد.
  • پیاده سازی با استفاده از معماری میکروسرویس به دلایل مختلف زمان بر تر از توسعه سیستم یکپارچه (monolithic) هست که از دلایل اون می‌توان به نیازمندی به بررسی و یادگیری بیشتر (Learning Curve)، نیاز به توسعه ابزار های اضافی (برای monitoring ، integration و … )، پیچیده تر بودن دیباگ کردن و … اشاره کرد.
  • نگهداری سرویس های متعدد برای تیم های کوچک دشوار بوده و کار کردن افراد یکسان روی سرویس های متعدد باعث سردرگمی و انتقال منطق های کد به جاهای اشتباه می‌شه . در صورتی که با تیم کوچکی کار میکنید حتما تعداد سرویس ها را پایین نگه دارید و همینطور نظارت دقیق روی نحوه پیاده سازی و رعایت مرز های بین سرویس ها داشته باشید.
  • در صورت عدم دسترسی به سیستم های cloud مانند AWS یا Azure، نگهداری ، scale  و مانیتورینگ سرویس ها در معماری میکروسرویس چالش برانگیز خواهد بود و شما نیاز به تیم قوی زیرساخت و DevOps خواهید داشت که قطعا هزینه بالایی به شما تحمیل خواهد کرد.

اما در چه شرایطی انتخاب این معماری می‌تواند کمک کننده بوده و باعث تولید خروجی باکیفیت و قابل نگهداری تر شود؟

  • اگر شناخت کافی از فضای مسئله دارید و قبلا روی موضوع به اندازه کافی مطالعه و تحقیق و تحلیل انجام شده انتقال به این معماری یا پیاده سازی ابتدایی با معماری میکروسرویس می‌تواند گزینه جذابی باشد. چرا که حالا اطلاعات و تجربه کافی برای شکستن صحیح سرویس ها دارید و احتمال خطا رفتن شما کمتر شده.
  • اگر نرم افزار در حال کار پیاده سازی شده به صورت یکپارچه (monolithic) دارید، حالا برای بهبود اوضاع، قابل نگهداری کردن کد و همچنین توسعه پذیر کردن تیم برنامه نویسی می‌توانید به سمت پیاده سازی این معماری حرکت کنید. (حرکت به سمت معماری میکروسرویس در قالب ریفکتور یا بازنویسی)
  • اگر استفاده از تکنولوژی های متفاوت (مانند پایگاه داده یا زبان برنامه نویسی) برای بخش های مختلف سرویس ارزش بالایی برای شما ایجاد‌ می‌کنه، استفاده از این معماری یا حداقل انتقال به نسخه ای از معماری سرویس گرا (Service Oriented Architecture) می‌تواند گزینه بسیار جذابی باشد. به عنوان مثال شما می‌تونید پایه اپلیکیشن سرور خود را که با Java توسعه داده شده همچنان نگهدارید ولی بخشی که برای مدیریت و پردازش کلان داده ها ایجاد شده را در قالب یک سرویس مجزا و با زبان Python پیاده سازی کنید و از مزایای هردو این زبان ها بهره‌مند شوید.

البته که موارد بالا فقط بخشی از موضوعات مهم در مورد تصمیم گیری برای انتخاب یا عدم انتخاب این معماری هستند اما می‌تونن نقطه شروعی برای این مسئله باشند.

شاید بهتر باشه از روش تحلیل SWOT برای تصمیم گیری در مورد این انتخاب استفاده کنید تا دید بهتری نسبت به شرایط و محدودیت ها داشته باشید.

چطور برای پیاده سازی اقدام کنیم؟

من در این بخش فرض می‌کنم که در حال حاضر سیستم یکپارچه (monolithic) در اختیار ماست و می‌خوایم به سمت معماری میکروسرویس حرکت کنیم. فرض دیگر من این هست که ما با یک سیستم که به شکل agile توسعه داده می‌شود مواجهیم و میزان تغییرات و فیچر های جدید توی سیستم در بازه های زمانی چند هفته ای وچند ماهه خیلی زیاد بوده و به همین دلیل گزینه ای که تمام یا بخش زیادی از کارها را متوقف کنیم و روی ریفکتور تمرکز کنیم وجود ندارد.

روش اول - پیاده سازی موازی

منظور از پیاده سازی موازی اینه که تیم جدیدی به صورت موازی تشکیل بشه که روی پیاده سازی سیستم با معماری جدید کار می‌کنه و هیچ کاری با نرم افزار موجود نداره. مزایا و معایب این کار از دید من این‌ها هستند:

مزایا

  • تیم به صورت متمرکز روی معماری و طراحی سیستم جدید کار می‌کند و تا حد زیادی از اتفاقات روتین سازمان جدا باقی می‌ماند.
  • جهت گیری (bias) های ذهنی جهت حفظ طرز فکر های سیستم قدیمی وجود ندارد و امکان خلاقیت و نوآوری بیشتری توی طراحی ها وجود خواهد داشت.
  • با توجه به تشکیل تیم جدید، می‌شود افراد دارای تجربه و تسلط نسبت به این معماری رو در تیم جدید قرار داد یا جذب کرد تا زمان آموزش و تحقیق کمتری نیاز باشد.

معایب

  • مدیریت فرهنگ تیم و سازمان و جلوگیری از رقابت های ناسالم بین دو تیم که همزمان دو نسخه از یک محصول را توسعه می‌دهند دشوار خواهد بود.
  • با توجه به موازی پیش رفتن پروژه‌ها امکان افتادن در سلسله تغییرات دائمی در سیستم جدید و هرگز تکمیل نشدن آن به دلیل تغییرات دائمی وجود دارد.
  • تیم پروژه Legacy باید علاوه بر کارهای روزمره به مرور و تا زمان تکمیل و جانشینی پروژه جدید، تحت آموزش لازم جهت کار در نرم افزار جدید نیز قرار گیرد.
  • فرایند جانشینی کامل نرم افزار جدید به جای قدیمی (به صورت BigBang) بسیار پیچیده و ریسکی خواهد بود.
  • علاوه بر توسعه نرم افزار جدید ابزارهایی برای روند جانشینی و تغییر ساختار داده ها به ساختار جدید باید توسعه داده شود که زمان توسعه را از قبل نیز بیشتر خواهد کرد.
  • به جهت عدم ارائه خروجی در سطح پروداکشن در مدت زمان طولانی امکان خستگی فردی و سازمانی بالایی وجود دارد.

روش دوم - پیاده سازی پلکانی

در این روش، به جای تشکیل تیم موازی و چالش های آن از همان تیم توسعه فعلی محصول برای انتقال به معماری جدید استفاده می‌کنیم. به این شکل که در صورت نیاز افراد جدید به تیم اضافه کرده و توسعه دهنده های قدیمی را نیز تحت آموزش های لازم جهت یادگیری نیازمندی های معماری جدید قرار می‌دهیم.

این روش که روش مورد علاقه من هم هست مزایا و معایب خود را داراست:

مزایا

  • نیازی به مدیریت دو تیم همزمان و جلوگیری از تداخل وظایف وجود ندارد.
  • پروژه به جای یک فرایند انتقال طولانی و فرسایشی در قالب بروز رسانی های مرحله ای مورد بهره‌برداری قرار می‌گیرد.
  • در صورت اشتباه در طراحی یا پیاده سازی، به دلیل چرخه های کوتاه تر توسعه و انتشار (Release) فیدبک های سریع‌تری دریافت می‌شود و به همین ترتیب ریسک کاهش پیدا می‌کند.
  • با توجه به روند پلکانی و مرحله ای دانش فنی تیم هم به طور مرحله ای و با تجربه عملی دائما بهبود پیدا کرده و تکمیل می‌شود.
  • نیاز به محدود سازی یا توقف توسعه فیچر های جدید وجود نداشته و صرفا با کمی مدیریت زمانی که با هماهنگی در سطح سازمان فراهم می‌شود، چابکی تیم حفظ شده و روند بیزنس به طور طبیعی و سالم به پیش می‌رود.

معایب

  • پروسه آموزش ابتدایی و یکسان سازی درک اعضای تیم از معماری میکروسرویس کمی طولانی تر و هزینه بر تر خواهد بود.
  • نیاز به هماهنگی بالایی در سطح سازمان جهت درک روند درحال انجام و مدیریت انتظارات و توقعات وجود خواهد داشت. به عنوان مثال، در سطح Stake Holder های سازمان باید درباره دلایل انجام کار، مزایای نهایی و همچنین کند شدن ابتدایی توسعه به دلایل مختلف شفافیت ایجاد کرد.
  • گاهی مواقع افراد توسعه دهنده سیستم Legacy نسبت به این سیستم دارای تعصب بوده و در برابر تغییرات مقاومت نشان می‌دهند. باید برای تمام افراد، خصوصا در سطح سازمان این موضوع شفاف شود که این انتقال به دلیل ایراد در سیستم فعلی نیست و بخشی از روند طبیعی رشد و زندگی و بلوغ یک نرم افزار است.

این ها بخشی از تجربه های شخصی و البته نتیجه مطالعات من در زمینه پیاده سازی معماری میکروسرویس بود که امیدوارم مورد توجه قرار گرفته و کمک کننده شما در تصمیم گیری و پیاده سازی هم باشد.

در مقاله های بعدی درباره روش های عملی پیاده سازی، برنامه ریزی زمانی، سریع تر کردن حلفه های فیدبک، ساختار های فنی و ابزار های مورد نیاز بیشتر توضیح خواهم داد و وارد مسائل فنی و عمیق تری خواهم شد.