کافه بازار هم مثل خیلی از شرکتهای دیگه، در زمان شروع یه monolith کوچیک بود و به مرور زمان بزرگ شد و از یه جایی به بعد دیگه اینقدر هم خودش بزرگ شده بود و هم تعداد توسعهدهندههاش زیاد شده بودن که دیگه کار کردن سخت شده بود. سختیهاش هم الان که دیگه مشخصه، ولی چندتا نمونهش رو بخوام بگم coupling زیاد کدها، توسعه رو سخت کرده بود و ریسک دیپلویها رو هم افزایش داده بود. همینطور تعدد توسعهدهندگان روی این monolith هم باعث شده بود توسعههای همزمان زیادی روی این سرویس اتفاق بیافته و در نتیجه تعداد زیادی merge request دارای conflict تولید میشد که باعث شده بود رفت و برگشتها و هزینه توسعه زیاد بشه. دیگه بقیه چالشهاش رو فاکتور میگیرم چون الان دیگه اکثرا باهاش آشنا هستیم. برای رفع این مشکلات، شرکت تصمیم گرفته بود که بخشهایی از لاجیکی که داخل این monolith هست که از لحاظ پروداکتی استقلال بیشتری داشتن رو از این monolith بیرون بکشه و بجای داشتن یک سرویس، چندتا سرویس داشته باشیم که با هم دائما در حال ارتباط هستن. این کار باعث شد بخش قابل توجهی از مشکلات توسعهای رفع بشه. اما وضعیتی که بوجود اومده بود اون زمان بهش میگفتیم از یه monolith به چندتا monolith تغییر پیدا کردیم. یعنی به جای اینکه یه هیولا داشته باشیم، چندتا هیولای کوچکتر داشتیم که هنوز خیلی به هم گره خورده بودن و مستقل رفتار نمیکردن. این شد که به همت مهران اخوان که CTO اون زمان بود، یه حرکتی شکل گرفت که این کار رو اصولیتر پیش ببریم و monolithهامون رو به microservice تعریف کنیم. برای این کار (و خیلی کارهای دیگه) یه گروهی تشکیل شده بود که بهش میگفتیم چپتر بکند، که متشکل از CTO و تعدادی تکلید بود، که هر کدوم از تکلیدها، نماینده یکی از تیمهای فنی/محصولی در زمینه مسائل فنی بودن. اینکه مهران چی تو ذهنش داشته و چطور پیش رفته رو که باید از خود مهران بپرسیم، ولی من این روند رو از نگاه خودم که اون موقع به عنوان یه تکلید عضو این چپتر بودم روایت میکنم که چه مسیری رو رفتیم و چرا اینجوری پیش رفتیم.
کلید این پروژه اواسط سال ۹۶ خورد و مسئله توی چپتر مطرح شد. مهاجرت به میکروسرویس، و به طور کلی نگاهمون به میکروسرویسها، چیزی نیست که بشه از یه جای کپی کرد و عینا پیادهسازیش کرد. یه جملهای از آدرین کاککرافت هست که میگه «People try to copy Netflix, but they can only copy what they can see. They copy the results, not the process» یا به عبارتی «مردم سعی میکنن نتفلیکس رو کپی کنن، ولی فقط میتونن چیزی که میبینن رو کپی کنن، در واقع بجای کپی کردن فرایند، نتایج رو کپی میکنن». نتفلیکس و سایر شرکتهایی که توی این زمینهها پیشرو محسوب میشن، کارهایی که میکنن رو بر اساس خیلی پارامترها مثل فرهنگ اون شرکت Tune میکنن و وقتی ما عینا همون موارد رو بخوایم کپی کنیم، بخاطر تفاوتهای فرهنگیای که داریم ممکنه یا قابل اجرا نباشن، یا حتی نتیجه معکوس بدن. در نتیجه لازم بود ما هم استانداردهای مخصوص خودمون رو داشته باشیم که با فرهنگ و شرایط کاری ما همخونی داشته باشه.
اولین مرحله از این فرایند مطالعه بود. ما یکم از پایهتر هم شروع کردیم و سعی کردیم در این لایه هم بررسی کنیم که اصلا میکروسرویس شدن مناسب ما هست یا نه و باید به سلوشنهای دیگهای مثل SOA و اینجور چیزها فکر کنیم و بعدش بریم روی اون سلوشن تمرکز کنیم. توی این مرحله بیشتر مطالعه میکردیم و منابعی مثل مقالات مارتینفاولر، کتاب Release It مایکل نیگارد، کتاب Building Microservices سم نیومن، کتاب Production Ready Microservices سوزان فاولر و هر چیز دیگهای که میتونستیم تو اینترنت پیدا کنیم رو لیست کردیم و بین خودمون تقسیم کردیم تا بخونیم که ببینیم داستان چیه و بهترین سلوشن برای مشکلات ما چیه.
خلاصه جمعبندیمون این شد که بله، میکروسرویس احتمالا مناسبترین گزینه برای ما باشه و حالا سوال این بود که چطور باید به سمتش بریم، تعریف ما از میکروسرویس چیه و چطوری شرکت رو با این تغییر همراه کنیم. اینجا هم هنوز نیاز قابل توجهی به مطالعه داشتیم، ولی میزان ابهام کمتر شده بود و کلیت مسئله دستمون اومده بود. برای اینکه سرعت کار بیشتر بشه، ما بخشهای مختلفی که میکروسرویسها روشون تمرکز میکردن رو بین خودمون تقسیم کردیم و هر نفر مسئول یکی دو بخش شد که بره مطالعه کنه و یه خلاصهای رو آماده کنه که برای چپتر ارائه بده. به نظرم اینجا هدفمون این نبود که یه چارچوب سفت و سخت بذاریم و شرکت رو مجبور کنیم در این راستا حرکت کنن، و بجاش بیشتر هدفمون این بود که سعی کنیم فرهنگش رو توی فرهنگ فنیمون جا بندازیم تا این سلوشن رو کنار سلوشنهای دیگهای که وجود داره ببینیم. برای این کار تصمیم گرفتیم یه تکتاک داشته باشیم و نتیجه این بررسیها رو به شرکت ارائه بدیم، و همینطور تکلیدی که توی هر تیم هست هم سعی کنه کمک کنه که سلوشن میکروسرویس شدن هم در بررسیهای فنی تیمها بررسی بشه. در نتیجه هدف این بخش از مطالعه هم این بود که دانش خودمون رو افزایش بدیم، و هم برای یه تاک توی شرکت آماده بشیم.
بخشهای مختلفی که در موردشون قرار بود مطالعه و صحبت کنیم رو اگه بخوام لیست وار بگم، اینا بود:
چون تمرکز این نوشته روی خود فرایندِ، نمیخوام وارد جزئیات اون تاک بشم، و بیشتر روی خود فرایند متمرکز میمونم. خلاصه که رفتیم و خوندیم و نوشتیم و به اشتراک گذاشتیم و چَکُشکاریش کردیم و در نهایت حدود اردیبهشت ۹۷ بود که این تاک رو تونستیم داخل شرکت داشته باشیم و تقریبا از اونجا به بعد، این بحث کم کم وارد تصمیمهای مهم فنی شد و بعد از اون تاک، توی چندتا از پروژههامون از مدل میکروسرویس استفاده کردیم.
توی هر تیم بسته شرایط و نیازشون، روی یه بخشی از این موارد تمرکز کردن. مثلا جایی که مشکلات و داونتایم بیشتر داشتیم، از شفافیت سرویس شروع کردیم و سعی کردیم مانیتورینگ، لاگینگ، Error Aggregation و اینجور مسائل رو بیشتر روش متمرکز بشیم که بتونیم ریشه مشکلات رو سریعتر پیدا کنیم. یه تیمی API Gateway رو توسعه داد. تیمهایی که دیپلویمنتهای ریسکیای داشتن روی بهبود فرایندهای دیپلویمنتشون متمرکز شدن. در واقع همه از یه جا شروع نکردن، ولی هر تیمی با توجه به اولویتهای خودش یه تیکه از مسیر رو برداشت و رفت جلو. اینطوری شد که آروم آروم به این سمت رفتیم که تعدادی میکروسرویس درست و حسابی داشتیم و هم درد توسعه و هم درد نگهداریمون کاهش پیدا کرد.
این مسیر فقط یه تغییر فنی نبود. برای خیلیهامون یه جور یادگیری جدیای بود که چطور یه مسئله بزرگ رو به بخشهای کوچک تقسیم کنیم، چطور همدلانه مطالعه کنیم، و چطور تصمیمهای فنی رو با فرهنگ شرکت هماهنگ کنیم.
تجربه شما از این زمینه چطور بوده؟ شما هم مسیر مشابهی رو طی کردین؟ یا بر اساس شرایط تصمیم گرفتین monolith بمونین؟
