در این پست پنج ارائهای درباره معماری نرم افزار که در کنفرانسهای معتبر برنامهنویسی goto; xconf QCon در سالهای اخیر برگزار شده است به صورت خلاصه نوشته شده.
ارائه اول از آقای Randy Shoup با عنوان Minimum Viable Architecture در کنفرانس goto; سال 2022
Minimum Viable Architecture • Randy Shoup • YOW! 2022
لینک ویدیو
آقای شوپ با استناد بر روند رشد و پیشرفت دو شرکت ebay و Amazon راجع به این موضوع حرف میرند که ما یک معماری کامل و فراگیر برای کل چرخه حیات یک سیستم نداریم و در هر مرحله بنا به اهداف مربوط به همان مرحله باید یک معماری را انتخاب و براساس آن سیستم نرم افزاری را توسعه دهیم و البته که در مراحل بعدی این معماری تغییر خواهد کرد.
مراحل رشد یک سیستم از نظر ایشان یه چهار بازه تقسیم شده که در ادامه به اهداف و معماری هرکدام میپردازیم
مرحله ایده(Idea Phase):
در این مرحله هدف یافتن پاسخ مناسب برای نیازهای مشتری در یک فضای پاسخ بسیار بزرگ است و بنابراین معماری ما باید بتواند به سرعت تغییر کرده و براساس این تغییرات پاسخهایی که برای نیاز مشتری ارائه میدهد را ارزیابی کنیم. در این مرحله ایشان "معماری پروتوتایپ" را پیشنهاد میدهد که براساس یک ساختار مونولیتیک است و فقط برای میل به این هدف کاربرد دارد و در مراحل بعدی باید با یک معماری مناسب جایگزین شود.
در این مرحله تنها هدف یافتن پاسخ مناسب برای نیازهای مشتری بوده و بعد از آن مرحله شروع، شروع میشود
مرحله شروع:
پس از اعتبارسنجی محصول و یافتن بازار مناسب برای آن، می توانیم شروع به ایجاد زیرساختی با قابلیت مقیاسبندی و قابلیت اعتماد بیشتر کنیم. معماری باید همچنان ساده و قابل تغییر باشد، اما باید بتواند ترافیک و داده های بیشتری را نیز تحمل کند. یک گزینه خوب برای مرحله شروع، ادامه استفاده از معماری مونولیث است، اما در این مرحله باید معماری مونولیتیک را کمی بهبود داده و تا جای ممکن آن را به احزای کوچکتری تقسیم کنیم تا تغییر و توسعه آن راحتتر شده و در عین حال بتواند به نیازهای مشتریان به خوبی پاسخ دهد. در این مرحله معماری مونولیتیک(ماژولار) برای سیستم بهترین انتخاب است چرا که هم توسعه آن راحتتر بوده و هم کارکرد مناسب سیستم در حال حاضر را ارائه میدهد.
مرحله مقیاس بندی:
با افزایش شمار مشتریان سیستم مونولیتیک دیگر نمیتواند درخواستهای بیشتر را پاسخ داده و اصطلاخا توانایی افزایش مقیاس عرضی آن به حد خود میرسد. این امر یک نشانه خوب برای شرکت است چرا که نشاندهنده رشد بازار شرکت میباشد.
در این مرحله ما باید اقدام به جایگزینی معماری خود کنیم تا بتوانیم با معماری جدید به درخواستهای بیشتری پاسخ دهیم و در این مرحله آقای shoup معماری مایکروسرویس را پیشنهاد میهد که برای افزایش مقیاس و پاسخ به درخواستهای زیاد بسیار مناسب است. ایشان همچنین پیشنهاد میکنند که روند جایگزین کردن معماری مونولیتیک مرحله به مرحله باشد و ابتدا اجزای مختلفی از سیستم مونولیتیک را از آن جدا کرده و با یک رابط جایگزین کنیم تا عملکرد سیستم همچنان برقرار باشد و در نهایت ما اجزایی خواهیم داشت که هرکدام کار خاصی را به طور مستقل از سایر بخشها انحام میدهند و ما آماده خواهیم بود که این اجزا را به مایکروسرویسهای مستقل تبدیل کنیم. در این مرحله ما نیاز به تیمهای بیشتری داریم تا هرکدام بتوانند مایکروسرویس خود را توسعه و بهبود دهند.
مرحله بهینه سازی:
پس از رسیدن به حالت پایدار، می توانیم شروع به بهینه سازی معماری خود برای عملکرد، کارایی و مقرون به صرفه بودن کنیم. در این مرحله سیستم نیاز به توسعه زیادی نداشته و بنابراین تعداد تیمها کاهش پیدا خواهد کرد و تنها هدف افزایش کارایی و رسیدن به معماری پایدار سیستم است.
جمع بندی:
در این ارائه براساس تجربه شرکتهای ebay و Amazon دیدیم که یک معماری کلی برای یک شرکت نمیتوان ارائه داد که در همه مراحل رشد شرکت بهترین معماری باشد و شروع یک سیستم با معماری مونولیتیک انتخابی کاملا اشتباهی نیست و با رشد سیستم باید این معماری را تغییر داده و از مایکروسرویس استفاده کنیم و این تغییر نشانه اشتباه در انتخاب معماری نیست بلکه نشانه رشد شرکت میباشد
