۱. به دلیل وجود سرویس های مستقل و کوچک در مایکروسرویسها(Microservices) پیچیدگی در برنامه زیاد می شود که قبلا در معماری یکپارچه(Monolithic) وجود نداشت. در واقع مایکرو سرویس نیاز به سطح بالایی از بلوغ عملیاتی دارد. اگر شرکت حاضر به سرمایه گذاری در امور خودکار سازی(Automation)، مانیتورینگ و مقیاس پذیری نیست نباید از مایکرو سرویس استفاده شود.
۲. مدل رایج برای استقرار مایکرو سرویس این هست که به ازای هر سرویس یک کانتینر(Container) استفاده شود . در برنامه های بزرگ تعداد کانتینرهای خیلی زیاد می شود، بنابراین مدیریت و مانیتوریگ سرویس های عملیاتی بسیار پیچیده خواهد بود. انعطاف پذیری مایکرو سرویس ها بایستی در مقابل اجرای عملیاتی همه سرورهای مربوطه سنجیده شود.
۳. مایکرو سرویسها به گونه ای طراحی شده اند که قابل استفاده مجدد بوده و بتوانند در برنامه هایی که نیاز به پایداری و مقیاس پذیری بالایی دارند استفاده شوند. اگر برنامه ایی که می خواهید بسازید کوچک است و کاربران زیادی ندارد در این صورت مایکروسرویس پیشنهاد نمی شود. چون هزینه های آن بیشتر از ارزش آن خواهد بود.
۴. اگر برنامه مد نظر از تجمیع یا تبدیل داده بین منابع داده ای استفاده می کند و تراکنش های(Transactions) زیادی انجام می دهد. ماهیت مایکرو سرویس باعث سختر شدن این کار می شود. در این صورت مایکروسرویسها مسٔولیت های زیادی خواهند داشت و حتی ممکن است کارایی کمتری نسبت به معماری یکپارچه داشته باشد.
۵. اگر به اندازی مناسب و کافی نیروی انسانی ندارید که بتوانند سرویس ها را توسعه دهند. در این صورت استفاد از معماری مایکرو سرویس می تواند باعث تاخیر در تحویل پروژه شود.
۶. در مواردی مثل سیستم های Embedded (که تاخیر می تواند صدمات جبران ناپذیری ایجاد کند)، سیستم های پردازش سریع استریمی از داده های واقعی(که افزودن هر لایه ارتباطی جدید باعث ایجاد تاخیر می شود) از مواردی هست که معماری مایکرو سرویس مناسب آنها نیست.
برگرفته از کتاب Spring Microservices in Action
