Auch wenn vieles dafür spricht, Systeme auf Basis von Microservice-Architekturen aufzubauen, muss das moderne Vorgehen nicht für jedes Unternehmen bzw. jedes Projekt die richtige Lösung sein. Gerade für kleinere Computerprogramme, die ohnehin nur wenige Aufgaben bewältigen, kann die Etablierung von Microservices einen erhöhten Aufwand bedeuten. Nicht nur die Erstellung der Services, sondern auch Wartung, Weiterentwicklung und Monitoring sind vergleichsweise aufwendig. Gerade auch bei der Überwachung der Prozesse (Monitoring) muss genauestens abgewogen werden, ob diese mit Microservices besser oder schlechter gelingt: Auf der einen Seite sind einzelne Microservices sehr einfach zu analysieren und zu messen. Durch die Masse an Microservices wächst diese Aufgabe aber enorm.
Schaut man sich die Vorteile der Arbeitsabläufe an, wird ersichtlich, dass dies nicht für jedes Projekt – vor allem nicht kurzfristig – sinnvoll ist. Ein Pluspunkt bei der Arbeit mit Microservices ist die Unabhängigkeit der einzelnen Teams. Man möchte z. B. vermeiden, dass ein Team auf die Ergebnisse eines anderen warten muss. Wenn das komplette Entwicklerteam aber ohnehin nur aus wenigen Personen besteht, hat diese Trennung wenig Sinn. Zudem wird – wenn man dem Gesetz von Conway folgt – ein kleines Team, in dem man aus pragmatischen Gründen keine klaren Trennlinien ziehen kann und vieles in Personalunion erledigt, ohnehin ein anderes Ergebnis erzielen.
Und auch bei größeren Teams ist eine umfangreiche Umstellung nötig: Positionen, die die Entwicklung zentral steuern, fallen vermehrt weg, stattdessen organisieren sich Entwicklerteams selbst. Eine solche Umstrukturierung ist sowohl zeit- als auch kostenintensiv. Auch dies darf man bei einer eventuellen Umstellung des Systems nicht außer Acht lassen.
Einige Befürworter von Microservice-Architekturen empfehlen daher eine Monolith-first-Strategie. Demnach ist es sinnvoll, ein Programmierprojekt zunächst als Monolithen anzugehen und die Vorteile dieser Herangehensweise vor allem in den Anfangstagen auszuschöpfen. Erst wenn das Projekt einen entsprechenden Umfang angenommen hat, sollte man auf eine Microservice-Architektur umsteigen. Zwischen beiden Systemen findet man die serviceorientierte Architektur (SOA), die als guter Zwischenschritt geeignet ist. Auch hierbei wird modularisiert vorgegangen. Die einzelnen Dienste sollen dabei Geschäftsprozesse abbilden.