تاثیر متقابل سازمان و معماری مایکروسرویس

چکیده

در سال‌های اخیر، معماری مایکروسرویس به یکی از جذاب‌ترین الگوهای طراحی سیستم‌های نرم‌افزاری مقیاس‌پذیر تبدیل شده است. سازمان‌هایی که به سمت این معماری می‌روند، معمولاً تمرکز خود را بر جنبه‌های فنی آن معطوف می‌کنند؛ از ابزارهای مدرن گرفته تا تکنیک‌های استقرار و تست. با این حال، تجربه‌های میدانی و مطالعات متعدد نشان می‌دهد که بسیاری از مشکلات رایج در پروژه‌های مایکروسرویس، برخلاف ظاهر فنی‌شان، ریشه در ساختار و فرهنگ سازمانی دارند.

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

مقدمه

مایکروسرویس فقط یک معماری فنی نیست، بلکه یک سبک تفکر در طراحی و توسعه نرم‌افزار است که بر استقلال تیم‌ها، خودمختاری سرویس‌ها، و استقرار مداوم تأکید دارد. اما در عمل، بسیاری از سازمان‌ها بدون درک کامل از پیش‌نیازهای فرهنگی و سازمانی این معماری، صرفاً به‌دلیل جذابیت‌های فنی آن به سمتش حرکت می‌کنند.

در چنین شرایطی، تمرکز اصلی تیم‌ها به‌جای بازآفرینی مدل سازمانی و ساختار تیمی، صرفاً بر اجرای تکنولوژی‌هایی مانند Docker، Kubernetes، و ابزارهای مانیتورینگ قرار می‌گیرد. این در حالی‌ست که طبق تفکر چابک، در خط اول از بیانیه Agile آمده است: «افراد و تعاملاتشان مهم‌تر از فرایندها و ابزارها هستند.» در نتیجه اگر تعامل بین افراد و ساختار تیمی با معماری انتخاب‌شده ناسازگار باشد، هیچ ابزاری نمی‌تواند سازمان را نجات دهد.

این مقاله با اتکا بر قوانین بنیادی مانند قانون کانوی (Conway’s Law) و نظریه بار شناختی (Cognitive Load Theory) تلاش می‌کند نشان دهد که چگونه ساختار سازمانی، بر کیفیت، قابلیت مقیاس‌پذیری و موفقیت معماری مایکروسرویس اثر مستقیم دارد.

پیشینه تاریخی معماری مایکرویس

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

• 1999: معرفی مفهوم CI در XP (یکپارچه‌سازی مستمر)

• 2001: تولد Agile Manifesto

• 2003: Domain-Driven Design توسط Eric Evans

• 2005: Micro Web Services در کنفرانس Cloud Computing

• 2006–2010: DevOps ، AWS و Azure

• 2012: ثبت واژه Microservice در Thoughtworks Radar

• 2013–2014: معرفی Docker، Kubernetes و تعریف رسمی توسط Fowler و Lewis

سایت Thoghtworks منبع بسیار غنی از اطلاعات صنعت نرم افزار است که بصورت کاملا شماتیک و کاربردی هر سال دو مرتبه Platforms ،Languages ،Techniques و Tools را در صنعت نرم‌افزار به دو صورت دسته بندی می‌کند: یکی از لحاظ قرارگیری در دسته‌بندهای Trial ،Access ،Hold و Adopt و دیگری در دسته‌بندی New ،Move in/out No Change . موارد ذکر شده در بالا هم قبیله ای‌های تکنیک مایکروسرویس هستند. تصویر۱ مربوط به سال ۲۰۱۲ میلادی است که مایکروسرویس به نقطه Access رسیده است.

در این بخش مشاهده می‌شود که پیشینه مایکروسرویس در برگیردنده چه مواردی است و ما را موظف می‌کند که این معماری را باید با حفظ پیشینه فکری آن پیاده کنیم تا در این مسیر موفق شویم. المان‌های اشاره شده در زمان خود علت وجود المان‌های بعدی می‌باشد مثلا اگر فرهنگ DevOps شکل نمی‌گرفت Docker جایگاهی در این مسیر نداشت.

حال باید به این سوال بیاندیشیم که آیا سازمانی که قرار است مایکروسرویس را در آن پیاده کنیم با هم‌قبیله‌ها و پیشینه ای که مایکروسرویس با خودش به همراه دارد همسو است یا خیر؟

مایکروسرویس مانند یه گیاه است که در بستر آب و خاک مناسبش کارمد و تاثیرگذار است و چه بسا در بیرون از آب و خاک مناسب خودش فقط هزینه و پیجیدگی غیرمفید برجای بگذارد.

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

اصول فنی و غیرفنی طراحی مایکروسرویس

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

• حذف تمرکزگرایی (Decentralize Everything) : هیچ چیزی را کانونی و مرکزی نباید کرد.

• استقرار مستقل (Deploy Independently) : سرویس‌ها باید این قابلیت را داشته باشند که بصورت مستقل بیلد و دیپلوی شوند.

• ایزوله‌سازی خطا (Isolate Failure): کنترل و جداسازی خطاهای هر سرویس بصورت جداگانه باید انجام شود.

• مانیتورینگ دقیق (Highly Observable): مانیتورینگ و رصد سرویس‌ها بطور واضح باید انجام شود.

• مدلسازی حول بیزینس (Business-Driven Modeling): معماری با محوریت بیزینس باید مدلسازی شود نه موضوعات فنی.

• فرهنگ اتوماسیون (Automation Culture): پذیرفتن فرهنگ خودکارسازی فرایند بیلد و دیپلویی

• پنهان‌سازی جزئیات (Hide Implementation Detail)
  

در دل قوانین فنی ذکر شده می‌توان به قانون Conway Law و Cognitive Load Theory اشاره کرد.

بر اساس قانون Conway « سیستمی که هر سازمان طراحی می‌کند یک کپی از ساختار و ارتباطات موجود بین افراد سازمان است.»

در این قانون علاوه بر ساختار به ارتباط بین افراد هم اشاره شده است؛ با وجود این اصل اگر سازمانی ساختار سلسله‌مراتبی و ارتباطات کند دارد، سیستم نرم‌افزاری‌اش هم چنین خواهد شد حتی با داشتن یک معماری مدرن. مایکروسرویس مستلزم تیم‌های کوچک، چندتخصصی، مستقل و خودگردان است. اگر سازمانی این قابلیت را ندارد، معماری شکست می‌خورد. همچنین Authority افراد نیز در سطوح مختلف سازمان بر روی طراحی فنی معماری بسیار تاثیرگذار است.

بر اساس نظریه Cognitive Load «اگر بار ذهنی روی افراد زیاد باشد در نتیجه Context Switch کارایی و قدرت افراد کاهش میابد.»

طبق نظریه Cognitive Load ذهن انسان توان محدودی دارد. اگر تیم‌ها به چند زمینه مختلف فکر کنند، کارایی‌شان افت می‌کند. در مایکروسرویس، باید بار ذهنی تیم‌ها محدود باشد. کوچک بودن تیم‌ها و تمرکز روی یک دامنه، کلید موفقیت در این معماری است. سازمان‌هایی با تیم‌های بزرگ، وابسته یا چندوظیفه‌ای، مناسب این معماری نیستند.

در ارتباط با اصل Business-Driven Modeling تیم‌ها را باید با محوریت بیزینس بنا کرد. در معماری مایکروسرویس تعیین Service Boundary صحیح خود به‌ خود از بروز بسیاری از مشکلات جلوگیری می‌کند.

پترن UL (Ubiquities Langugae) از پرکاربردترین‌ها زمینه تعیین Boundary است. اما term های این پترن برگرفته از کدام منبع است؟ پاسخ این است که از ترکیب بیزینس و ساختار سازمان استخراج می‌شود. به این ترتیب برای تعیین مرز مسولیت تیم‌ها از همان term های Boundary Context استفاده می‌شود پس سازمان‌هایی مناسب این معماری هستند که تیم‌های کوچک و خودمختار را به رسمیت بشناسند. اگر سازمان ما نمی‌تواند تیم‌های کوچک داشته باشد پس آمادگی پذیرش این معماری را ندارد.

تعامل معماری، فرایند و سازمان

سازمان، فرآیند و معماری سه ضلع مثلثی‌اند که روی هم اثر می‌گذارند:

طبق تصویر ۲ معماری می‌تواند روی سازمان و فرایند تاثیر بگذارد به شرطی دست قدرت داشته باشد و مغلوب صدرصد ساختار و ارتباطات بین سازمانی نشود. اگر معماری قدرتمند باشد، می‌تواند ساختار و فرایند را اصلاح کند.

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

معماری زمانی موفق است که سازمان، ظرفیت پذیرش و پشتیبانی از آن را داشته باشد.

نتیجه گیری

در پایان این مقاله، به این نکته‌ی کلیدی رسیدیم که معماری مایکروسرویس صرفاً یک انتخاب فنی نیست، بلکه یک تصمیم عمیقاً سازمانی و فرهنگی است.
اگر سازمانی نتواند تیم‌های کوچک، چندتخصصی و مستقل داشته باشد، تعاملات انسانی مؤثر را اولویت دهد، فرآیندها و ساختارهای قدیمی را بازطراحی کند، و فرهنگ DevOps و چابکی را بپذیرد، آن‌گاه استفاده از معماری مایکروسرویس، نه‌تنها مزیتی به همراه ندارد، بلکه ممکن است منجر به پیچیدگی، اتلاف منابع و حتی شکست پروژه شود.
در مقابل، سازمان‌هایی که به بلوغ سازمانی، فرهنگی و فنی لازم رسیده‌اند، می‌توانند از مزایای واقعی این معماری بهره‌مند شوند؛ مانند مقیاس‌پذیری مؤثر، استقرار مستقل، افزایش تاب‌آوری سیستم‌ها.
در نهایت، این پرسش‌ها باید پیش از تصمیم به استفاده از معماری مایکروسرویس در هر سازمانی مطرح شوند:
آیا ساختار سازمان ما با الگوی تیم‌های مستقل و مسئولیت‌پذیر همخوانی دارد؟
آیا تصمیم‌گیری فنی در سازمان از استقلال کافی برخوردار است؟
آیا ما فرهنگ تعامل، یادگیری و اتوماسیون را در سازمان جا انداخته‌ایم؟
و مهم‌تر از همه، آیا به‌جای دنباله‌روی از مدها و ترندهای فنی، نیاز واقعی خود را شناخته‌ایم؟
اگر پاسخ این پرسش‌ها مثبت باشد، آنگاه مایکروسرویس می‌تواند برای ما نه یک بار، بلکه یک مزیت راهبردی باشد.

منابع

1. Vernon, Vaughn. Implementing Domain-Driven Design. Addison-Wesley, 2013.

2. Evans, Eric. Domain-Driven Design, 2004.

3. ThoughtWorks Technology Radar (https://www.thoughtworks.com)

4. Microsoft Application Architecture Guide, 2nd Edition ( http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle.)

5. Conway’s Law (Melvin Conway, 1967)

6. Team Topologies (Matthew Skelton & Manuel Pais, 2019)