Aun siendo muchos los factores que hablan a favor del desarrollo de sistemas basados en microservicios, este método no tiene que ser la mejor solución para cualquier empresa o proyecto. Especialmente para programas informáticos sencillos que han de solucionar pocas tareas, la utilización de microservicios puede conllevar un esfuerzo comparablemente mayor porque, además de la creación de los servicios, su mantenimiento, su desarrollo posterior y su monitorización también significan mucho trabajo. Precisamente es durante el control de los procesos cuando se ha de sopesar de la forma más exacta posible si los microservicios lo favorecen o lo perjudican, ya que si bien son muy fáciles de analizar y medir, si crece demasiado su número esta tarea se vuelve titánica.
Echando un vistazo a las ventajas de este método de trabajo se ve claro que no conviene a cualquier proyecto, por lo menos a corto plazo. Un punto fuerte del trabajo con microservicios es la autonomía de los distintos equipos, que tiene el objetivo de evitar, por ejemplo, que un equipo tenga que esperar a los resultados de otro. Sin embargo, cuando el equipo entero solo se compone de unas pocas personas, tal separación pierde su sentido. Además, y siguiendo la ley de Conway, un equipo pequeño que en la práctica no necesita divisiones y todo se soluciona en común persigue un fin distinto.
También en los grandes equipos la introducción de este enfoque requiere un cambio profundo. Los puestos que dirigen el desarrollo suelen desaparecer, porque los equipos se organizan a sí mismos. Una reestructuración así requiere una inversión de tiempo y costes, un factor que no debe dejarse de lado en caso de llevarla a cabo.
Algunos partidarios de las arquitecturas de microservicios recomiendan en consecuencia una estrategia Monolith first. Según esta, al comienzo conviene iniciar un proyecto como monolito y agotar las ventajas de esta concepción sobre todo en los primeros días. Solo cuando el proyecto ya ha adquirido una envergadura suficiente debería cambiarse a una arquitectura de microservicios. Entre ambos sistemas se encuentra la arquitectura orientada a servicios o SOA, adecuada como paso intermedio y con la cual también se procede con módulos. Aquí, cada uno de los servicios representa procesos de negocio.