میکروسرویسها مضر در نظر گرفته میشوند
تیم متابیس
هیاهوی زیادی در مورد میکروسرویسها وجود دارد، و مونولیتزدایی به نظر میرسد که همه خشم در HackerNews و Reddit است. خوب است که بشنویم DHH عقلانیت را به گفتگو برمیگرداند.
شرکتهای بزرگ اغلب دلیل بسیار خوبی برای شکستن تهاجمی برنامهها به سرویسهای Centi، Milli و Micro دارند. برای تیمهایی که تعداد آنها در ارقام تک یا دو رقمی مهندسان است، این کمی کمتر از دیوانگی است.
(میکرو)سرویسها چه چیزی را حل میکنند
میکروسرویسها اساساً مشکل هماهنگی در تیمهای بزرگ مهندسان را حل میکنند.
آنها استقرار مستقل بخشهای مختلف یک برنامه بزرگتر را آسان میکنند. آنها همچنین مشکل را به واحدهای کوچک پیچیدگی که میتوانند بدون نیاز به درک کل سیستم درک، تست و رفع شوند تقسیم میکنند.
هنگامی که یک مونولیت عظیم دریافت میکنید، شکستن آن میتواند به شدت بهرهوری توسعهدهنده را بهبود بخشد زیرا زمان کامپایل، lint و تست به شدت کاهش مییابد اگر فقط در محدوده یک سرویس واحد کار میکنید.
آنها همچنین این جداسازی را با مکانیزم استقرار، در مقابل قرارداد در استفاده از کتابخانهها در یک codebase واحد، اعمال میکنند. این کار را برای مشتریان سختتر میکند که encapsulation کد شما را بشکنند، با مجبور کردن آنها به استفاده از آن از طریق یک API منتشر شده.
بدبینانه، آنها همچنین مشکل دائمی در سیاست شرکتها برای کار خوب با دیگران را حل میکنند. اکنون میتوانید مسائل یکپارچهسازی را نادیده بگیرید و فقط به میکروسرویس خود اشاره کنید و بگویید "همه تستها پاس میشوند و کار میکند!" و در بررسی بعدی خود خوب به نظر برسید.
مشکلاتی که واقعاً دارید را حل کنید
پس، عالی. به نظر میرسد یک راهحل عالی برای مشکلات یک تیم مهندسی با عملکرد بالا و بزرگ در یک مکان بزرگ و پیچیده با سیاستهای زیاد است.
آیا این مشکلات فعلی شما را توصیف میکند؟ اگر یک استارتاپ مرحله اولیه معمولی هستید، مشکلات شما باید شبیه این باشد:
- اعتبارسنجی محصول که به کاربران مورد نظر خود خدمت میکند
- فهمیدن یک استراتژی جذب مشتری و تکرار سریع روی لبههای محصول که این را تسهیل میکند
- خواب بیشتر با آسانتر و کمتر خطاپذیر کردن استقرار
- کمک به بقیه شرکت بیشکار برای انجام کارهای خود
پس... دقیقاً شکستن یک برنامه به سرویسها چه چیزی برای شما میخرد، دوباره؟
مونولیتها برای استارتاپهای مرحله اولیه ایدهآل هستند
استقرار ساده است. CI را راهاندازی کنید، استقرار را خودکار کنید و به طور مکرر استقرار کنید. با مونولیتها میدانید که آیا استقرار یافت یا نه.
تغییرات سراسر سیستم میتواند در یک مکان انجام شود و نیازی به نسخهبندی صریح تغییرات شکستن ندارید زیرا همه کد در یک مکان است. این خیلی سریعتر برای تکرار روی ویژگیهای جدید میکند.
همه چیز در یک مکان واحد است. در حالی که به این معنی است که چیزهای بیشتری برای درک وجود دارد، یک دیدگاه عجیب وجود دارد که تقسیم کد در ۱۰+ repo به نوعی درک سیستم به عنوان یک کل را آسانتر میکند. مطمئناً برای یک dev junior، نگاه کردن به یک سرویس واحد و درک آن آسانتر است. اما ایده ایجاد یک مدل ذهنی از دهها سرویس به نوعی آسانتر از ماژولهای معادل در یک codebase واحد است دیوانگی است. مطمئناً وقتی به ۱M+ خط کد میرسید، دیوانه میشود، اما این مشکلی نیست که الان دارید.
پیامدهای تحلیلی میکروسرویسها
پس جدا از مشکل دائمی کسی در اینترنت اشتباه است، چرا این در وبلاگ Metabase است؟ خوب، عمدتاً به این دلیل که یک پیامد بسیار جدی از استفاده از میکروسرویسها بر توانایی شما برای ارائه تحلیل وجود دارد.
اگر یک مدل داده دارید که جدا شده است، در برخی موارد میخواهید که... آن را دوباره به هم متصل کنید تا بتوانید آنچه با کسبوکار شما اتفاق میافتد را تحلیل کنید. طرفداران اصلی میکروسرویسها تمایل دارند یا مهندسانی در شرکتهای بزرگ باشند (که ارتشهای کوچکی از مهندسان داده برای دوختن چیزها به هم دارند... آیا شما دارید؟)، مشاوران (جایی که هر چیزی که یک مشاور فردی را خوب نشان میدهد و بعداً ساعتهای قابل صورتحساب را جمع میکند یک چیز خوب است)، یا مهندسانی که نمیخواهند با دیگران در شرکت خود هماهنگ کنند.
این اگر "پایگاه داده مناسب برای کار را انتخاب کنید" را روی میکروسرویسها اضافه کنید تشدید میشود. در اینجا، شما ناگهان نیاز به یک داستان ETL پایدار در سراسر همه این دانههای برف کوچک براق خواهید داشت.
چرا اهمیت دارد؟
خوب، بیشتر اوقات وقتی یک استارتاپ مرحله اولیه هستید، دقیقاً نمیدانید چه چیزی بسازید. شما یک ایده، امیدوارم برخی کاربران اولیه و یک رویا خواهید داشت. برای بهبود محصول خود باید هم بفهمید چه اتفاقی میافتد، چه ویژگیهای محصولی کار میکنند، چه کار نمیکنند، کاربران چگونه رفتار میکنند و غیره.
همچنین، طبق تعریف، افراد بسیار کمی برای انجام کار خواهید داشت. بنابراین برای اجرای کسبوکار، باید برای غیرمهندسان (یا در این مورد هر کسی غیر از شخصی که میکروسرویس را نوشته است) آسان کنید که داده را بیرون بکشند.
در برخی موارد، اندازه code base شما را وادار میکند که آن را به سرویسها تقسیم کنید، و همه مشکلات عملیاتی در آن را به عهده بگیرید. تا آن زمان، تا جایی که میتوانید یک مونولیت ساده و خستهکننده را سوار شوید.
خلاصه - میکروسرویسها مشکلاتی را حل میکنند که به عنوان یک استارتاپ مرحله اولیه ندارید و تکرار را دشوارتر میکنند. تا جایی که ممکن است یک مونولیت را سوار شوید.
یک داشبورد فروش بسازید که تیم شما واقعاً استفاده کند. ۱۰ متریک کلیدی، نکات و یک مثال زنده در متابیس را ببینید.
تحلیلهای جاسازیشده به معنای دادن دسترسی به کاربران شما به نمودارها، متریکها و گزارشها مستقیماً در داخل محصول شما است، تا بتوانند دادههای خود را کاوش کنند و بر اساس آن عمل کنند بدون اینکه نیاز به ترک برنامه شما داشته باشند یا برای پاسخ به شخص دیگری تکیه کنند.