خانه / microservices / درس هایی که مایکروسرویس باید از موفقیت ها و شکست های SOA بگیرد.

درس هایی که مایکروسرویس باید از موفقیت ها و شکست های SOA بگیرد.

درس هایی که مایکروسرویس باید از موفقیت ها و شکست های SOA بگیرد.

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

اگرچه این دو مفهوم در ابعاد مختلفی از سبک معماری، پیاده سازی، تکنولوژی و … با هم تفاوت های اساسی دارند، اما هر دوی اینها در چشم اندازی که دارند بسیار شبیه هم بوده و هدف مشترکی را دنبال می کنند. هر دوی این سبک های معماری به دنبال تغییر تفکر و نحوه ی تولید نرم افزار با decompose کردن سیستم به بخش های کوچکتر هستند. باید توجه داشت که هر چند هم مایکروسرویس و هم SOA به عنوان معماری شناخته میشوند، در نهایت اما هر تمایل دارند که به جنبش و حرکت جهت تغییر جهت تفکر و رویکر و culture سنتی در سازمان مبدل شوند.

با توجه به اینکه SOA به عنوان یک جنبش تقریبا ناموفق در صنعت IT شناخته می شود، و همچنین اینکه مایکروسرویس هم با شعارهای مشابه SOA    وارد میدان شده است، تمایل و حساسیت بسیار زیادی در مقایسه بین دو مفهوم بین افراد بوجود امده.

Roy Schulte از گارتنر در سال ۱۹۹۶  پیش بینی خود در مورد SOA را بدین صورت بیان کرده بود:

A service-oriented architecture is a style of multitier computing that helps organizations share logic and data among multiple applications and usage modes.

علی رغم این موضوع، اما تا سال ۲۰۰۲  و با رونق وب سرویس ها، SOA  در عمل و در صنعت چندان مورد استفاده و استقبال قرار نگرفت.

هرچند وب سرویس ها soap/xml با هدف server-to-server web communication طراحی شده بود، اما به تدریج به عنوان یک channel جدید ارتباطی بر بستر وب توسط سازمانهای مختلف جهت استفاده از سرویس های داخلی دیگر سرویس ها مورد استفاده قرار گرفت. با بیشتر شدن گرایش به این سمت، به عنوان یک روش و مکانیزم internet-friendly  جهت ارتباط این برنامه ها با هم، با تاکید بر صرفه جویی در هزینه ها، web service ها با سرعت خیره کننده ای در این سازمان ها گرفتار شدند. بر چسب “service-Oriented Architecture” در همین زمان به این رویکردها زده شد، و جنبش SOA از همین جا متولد شد.

همزمان با بشتر شدن تمایل و گرایش به SOA ها و با محبوبیت بیشتر جنبش SOA؛ جهت ساده تر شدن اصل Loose Coupling در SOA ها یک الگوی Integration جدید معرفی شد: Enterprise Service Bus(ESB). هدف و مقصود اصلی ESB وجود یک Integration facilitator سبک وزن در تقابل با الگوی hub-and-spoke Application Integration(EAI) که به عنوان الگویی متدوال در آن زمان استفاده می شد؛ بود موضوعی که بعدا در استفاده از ESB کاملا فراموش شد؛ و مسیر SOA را کاملا عوض نمود. به بیانی می توان گفت که ESB عکس العملی بود در تقابل با ماهیت مونولیت EAI broker ها  که دارای مشکلاتی ؛ از جمله مشکلات پایین بودن نرم افزار؛ وابستگی های بیش از اندازه بین چند تیم؛ و مدیریت ضعیف بود.


همانطور که گارتنر پیش بینی کرده بود؛ ESB در سال 2005 به یک الزام تبدیل شده بود. سازمانهای بزرگ IT جهت مدیریت زیر ساخت های ESB گروه های تحویل متمرکز را تشکیل دادند. ESB به عنوان یک چرخ محرک به معماری های سازمانی SOA در محیط هایی که این معماری های در حال استفاده بودند؛ کمک می کرد. SOA ها از این چرخ ها برای دو هدف استفاده نمودند:بی شک مهمترین و اصلی ترین هدف و چشم انداز عمل کردن به عنوان یک شبکه یکپارچه از سرویس هایی که با هم تعامل دارند بود؛ مفهومی که یادآور یکی از اصول بسیار مهم  جنبش مایکروسرویس ها است. “smart endpoint and dumb pipes”.

با این وجود با محبوبیت بیشتر ESB ها این مفهوم مهم کم کم معانی دیگری در عمل بخود گرفت. گارتنر در سال 2002 پیش بینی کرده بود که بسیار از سازمانها تا سال 2005 اقدام به پیاده سازی ESB خواهند نمود؛ با این وجود ارائه دهندگان hub-and-spoke EAI موفق شده بودند که صنعت را متقاعد کنند که ESB یک pattern نبود؛ بلکه باید از یک محصول یا فریمورک برای یکپارچه سازی برنامه های سازمانی استفاده کرد. این ارائه دهندگان در نهایت موفق شدند که EAI broker های خود را به عنوان ESB به مشتریان خود ارائه دهند. و عملا مسیر در نظر گرفته برای ESB ها کاملا تغییر دادند. در واقع نقطه تمرکز و توجه سازمان بجای اینکه بر روی بیزینس و اهداف مشخص شده برای SOA باشد بر جنبه تکنولوژیک معطوف شد.

  1. کنترل
  2. سازگاری

اهداف اصلی SOA سرعت بخشیدن به تحویل پروژه؛ بالابردن اجایلیتی و کم کردن هزینه های یکپارچه سازی بود. با این وجود سازمانها در ادامه دریافتند که SOA باعث بالا بردن پیچیدگی و ایجاد bottleneck ها جدید تر و بیشتری می شود که پیاده سازی آن(بر پایه ESB ها) را با هزینه مواجه خواهد نمود.

در سال 2009؛ نه تنها دیگر در خواستی برای استفاده از SOA ها بین افراد نبود؛ که حتی باعث از بین بردن SOA نیز شدند.RESTfull Web API به عنوان یک جایگزین lighter-weight برای سرویس های SOAP هم در همین سال ها ظهور پیدا کرد. طبیعت توزیع شده ی زیر ساختارهای Cloud based با ساختارها و توپولوژی های centralize از جمله ESB بشدت با چالش روبرو می شد.

یادگیری و عبرت از SOA

تفاوت یا شباهت های مایکروسرویس ها و SOA شاید در حال حاظر کمتر مورد اهمیت باشد؛ و سوال مهمتر این می باشد که چه درس های جنبش مایکروسرویس می تواند از SOA ها بگیرد؟

  1. بر اهداف اصلی و اولیه در نظر گرفته شده برای مایکروسرویس ها پایبند بمانید.

SOA از زمانی که از اهداف اصلی خود که بالا بردن اجایلیتی و کاهش هزینه ها بود؛ بدور شد دچار مشکلات وابستگی شدید به تکنولوژی شد که در نهایتا منجر به کاهش و از بین رفتن تمایل و گرایش به آن شد. همانطور که در بالا ذکر شد. در عمل بیشترین توجه سازمانها در SOA بر جنبه های تکنولوژی SOA و کمترین توجه معطوف شد بر مشکلات و مسائل بیزینسی که SOA سعی در مرتفع نمودن آنها را داشته بود شد. در مایکروسرویس ها هر چند که بیزینس در مرکز عمل قرار دارد و تمامی سرویس های بر اساس بیزینس طراحی و پیاده سازی می شوند؛ اما در اینجا هم نیز تکنولوژی هایی وجود دارند که مدعی می شوند که اگر آنها بسادگی برنامه های خود را containerize کنند؛ “به پیاده سازی مایکروسرویس ها” رسیدند. جهت موفقیت در مایکروسرویس ها باید قبل از پرداختن بر جزییات تکنولوژی بر روی اهداف؛ مزیت ها و اصول مهم آن تاکید داشته باشید.

  1. با نمونه های موفقیت آمیز شروع کنید.

زمان معرفی و ارائه SOA تعداد کمی از پیاده سازی های جدی و موفق از SOA در صنعت وجود داشت. در واقع SOA ابتدا به عنوان یک  الگوی فکری معرفی شد؛ بدون اینکه در عمل سازمانی آن را پیاده کرده باشد؛ این در حالی است که معماری مایکروسرویس از الگوهای توسعه نرم افزار در سازمان های موفق بزرگ در صنعت نرم افزار مشتق شده است. Amazon و Netflix دو نمونه از این پیش روهای موفق می باشند. همچنین باید گفت که چارچوب مایکروسرویس بسیار گسترده بوده و شامل الگوها؛ اصول؛ culture؛ و رفتار های سازمانی علاوه بر جنبه های تکنولوژی می باشد. جهت رفتن به این سمت از نمونه های موفق در مایکروسرویس درس هایی موفقیت و شکست احتمالی بسیاری می توان گرفت.

  1. اهمیت چشم انداز

مثال های زیادی از گیچی و انحراف در SOA بین سازمان ها وجود دارد. سازمانهایی که بجای ایجاد یک تغییر فرهنگی که لازمه تفکر SOA بود بر روی جنبه های تکنولوژی و ایجاد راه حل های مرکزی تمرکز نمودند. معماری های سازمانی بیشتر بر اساس استانداردها بنا نهاده شده بود انهم بدون اهداف مشخص و روشن. تغیر تعریف و ماهیت ESB توسط این سازمانها هم در نتیجه ی همین تفکرات بود. باید توجه داشت که چشم انداز و نقشه ی راه مایکروسرویس والاتر و ارجح تر بر هر امر دیگری می باشد. که اصولا ماهیت ودلیل وجود و چیستی مایکروسرویس را معنی و مفهوم می بخشد. پس بهیچوجه این چشم اندازها را سبک نشمارید.

  1. هماهنگی و هارمونی در اهداف پیش رو را دنبال کنید؛ قطعیت را دنبال نکنید

SOA با دو هدف متعادل یعنی افزایش زمان پاسخ به بازار و کاهش هزینه های یکپارچگی معرفی شد. در عمل اما بدلیل تمایل شدیدی که به centralize بودن در SOA ها بوجود آمد دستیابی به این دو هدف متوقف شد و در عوض سازمان ها برای کنترل و استاندارد سازی یکپارچگی برنامه های خود تلاش کردند. اینها اهداف غیر متعادل بودند. مایکروسرویس ها هم به دنبال بهبود سرعت تحویل نرم افزار و افزایش سلامت سیستم با بزرگ شدن مقیاس سیستم می باشد. که اینها اهداف هماهنگ ودارای هارمونی در مایکروسرویس هستند. از همه ی افراد و سازمانهای درس بگیرید و سوال بپرسید تکنولوژی را هم نیز جدی بگیرید؛ اما در عمل این شما هستید که باید برای مشکل و بیزینس خود بر اساس ماهیت بیزینس خود راه حل پایه ریزی کنید.

  1. حرف اول و آخر را اصول و الگوها می زنند و نه تکنولوژی

در بحث مقایسه ی مایکروسرویس و SOA یک مورد مهم وجود دارد: معماری مایکروسرویس کاملا با چشم انداز و اهداف اولیه ی SOA ها یعنی” decompose کردن یک سیستم به سرویس های دارای وابستگی کمتر”؛ کاملا منطبق می باشد. این عبارت یک الگو هست. همچنین اصول اصلی SOA یعنی هماهنگی با بیزینس؛ کمینه کردن وابستگی به عنوان اصول اصلی مایکروسرویس ها هستند. تفاوت اصلی و مهم در تکنولوژی می باشد. تکنولوژی با سرعت زیاد معرفی شده و استفاده شده و ممکن است در آینده ی نزدیک تکنولوژی فعلی کارآمد نبوده و به ناچار باید کنار گذاشته شود؛ طبیعتا هر جنبش و حرکتی که وابستگی زیادی به تکنولوژی داشته باشد؛ درچار این زمان زدگی خواهد شد. مایکروسرویس ها هم از این قاعده مستثنی نیستند. تکنولوژی های محبوب و برتری از جمله Docker ممکن است در آینده به ناچار جای خود به تکنولوژی های جدیدتر بدهند!!

درباره ی masoud@admin

همچنین ببینید

ملزومات مایکروسرویس

ملزومات مایکروسرویس آقای مارتین فاولر مقاله ای تحت عنوان MicroservicePrerequisites دارند که در اون به بررسی یک …

Microservices: Lessons from the Frontline

خانم ژامک دهقانی از مشاورین ارشد thoughtworks  و با نگاه و تمرکز بر روی معماری سیستم …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن