Del monolito a los servicios
Un microservicio no se define por su tamaño. Se define por una propiedad verificable: se puede desplegar solo. Podés cambiarlo y llevarlo a producción sin cambiar ni volver a desplegar ningún otro servicio. Newman insiste en ese despliegue independiente porque es la que entrega los beneficios prometidos: autonomía, fallas aisladas, escalado por separado.
De ahí salen las otras dos características: está modelado alrededor de un dominio de negocio y es dueño de su propio estado. Sus datos son privados y se llegan únicamente a través de su API.
Los dos destinos
El monolito modular es una sola unidad desplegable dividida por dentro en módulos con límites explícitos. Es un destino legítimo: te da los límites de dominio sin pagar particiones de red ni transacciones distribuidas.
El monolito distribuido es el modo de falla: servicios repartidos por la red que igual hay que desplegar juntos, encadenados por llamadas sincrónicas y por una base compartida. Paga todos los costos de la distribución y no cobra ninguno de los beneficios. Si no se puede liberar solo, no es un microservicio.
Migrar de a poco
El patrón strangler fig —bautizado por Martin Fowler— intercepta las peticiones en un perímetro y las redirige funcionalidad por funcionalidad a la implementación nueva; cuando ya nada rutea al código viejo, ese código se retira. Fowler es explícito: esto no vuelve fácil la tarea. La ventaja es que la inversión y el retorno pasan de a poco y a la vista.