Una “arquitectura de microservicios” es un enfoque para desarrollar una aplicación software como una serie de pequeños servicios, cada uno ejecutándose de forma autónoma y comunicándose entre sí, por ejemplo, a través de peticiones HTTP a sus API. Normalmente hay un número mínimo de servicios que gestionan cosas comunes para los demás (como el acceso a base de datos), pero cada microservicio es pequeño y corresponde a un área de negocio de la aplicación. Además cada uno es independiente y su código debe poder ser desplegado sin afectar a los demás. Incluso cada uno de ellos puede escribirse en un lenguaje de programación diferente, ya que solo exponen la API (una interfaz común, a la que le da igual el lenguaje de programación en la que el microservicio esté programado por debajo) al resto de microservicios. No hay reglas sobre qué tamaño tiene que tener cada microservicio, ni sobre cómo dividir la aplicación en microservicios, pero algunos autores como Jon Eaves caracterizan un microservicio como algo que a nivel de código podría ser reescrito en dos semanas.

En una aplicación basada en la arquitectura monolítica, todos sus módulos están empaquetados en un mismo archivo o ejecutable, por lo que si alguna vez se requiere modificar alguno de los módulos, será necesario volver a empaquetar todos los módulos aun que no se hayan modificado todos.   Podemos acceder a la página web de la tienda, realizar compras, etc., gracias a un servidor, una máquina que está ejecutando el código de la aplicación, en forma de archivo war, que eventualmente se conecta a una base de datos para recuperar información. Cuando un usuario compre un producto vía web, mostremos los productos disponibles, etc., la aplicación responderá de una forma u otra, según la hayamos programado, pero el código de las distintas lógicas de negocio (inventario, pagos, envíos) aunque puede estar separado en distintos módulos del código, finalmente se empaqueta en un único archivo ejecutable. Por eso la llamo arquitectura monolítica. Si hago un cambio en el módulo de pagos, tendré que subir a producción de nuevo todo el código, incluido los módulos de inventario y envíos, a pesar de no haberlos cambiado. Además, para escalar la aplicación (por ejemplo dar servicio a muchos usuarios) tendré que ir ejecutando copias de mi aplicación bajo balanceadores de carga, que vayan redireccionando a los usuarios hacia un sitio u otro, en función de si el sistema está muy saturado. En este caso, tendré que replicar toda la aplicación, aunque solo sea el módulo de pagos el que concentre la sobrecarga. Pero por otra parte, si mi aplicación no es muy compleja, la subida será sencilla y fácil de gestionar, ya que en este caso hablamos de un único archivo ejecutable.

En vez de tener un único ejecutable, cada componente es un ejecutable por si mismo, y los servicios se comunican entre sí a través de llamadas. En este caso también tenemos un microservicio que implementa la interfaz web con la que interactúan los usuarios y cierta lógica por debajo para llamar al microservicio de pagos, inventario y envíos cuando sea necesario. Beneficios – Cada microservicio se puede desplegar de forma independiente: un cambio en el módulo de inventario, no afectará a los demás, solo tendremos que subir ese módulo. – Es fácil de entender, ya que la lógica de negocio está bien separada. – Facilita la gestión de equipos multifuncionales y autónomos. Por sí mismo, cada microservicio es mutlifuncional: tiene una parte de base de datos, de backend, etc., además de ser independiente de los demás. Podemos formar equipos multifuncionales que se encarguen de varios microservicios, escalando el proceso de desarrollo de forma más sencilla (recuerda el post de la ley de Conway, tu arquitectura es reflejo de la organización de tu equipo y al revés, y puede llegar a facilitar o dificultar la gestión técnica). – Es más fácil de escalar a nivel de software, ya que en lugar de replicar toda la aplicación y gestionarlo con balanceadores, replicaremos los microservicios que tengan más carga.

Retos y consejos Una arquitectura de microservicios puede parecer muy beneficiosa, pero como todo, tiene sus pros y contras. Como cualquier arquitectura software. Además, está muy extendida la idea de que solo con microservicios se puede llegar al despliegue continuo o a la entrega continua, pero esto no es así. Empresas como Facebook tienen despliegue continuo sin tener una arquitectura de microservicios. Lo que hay que tener en cuenta es que los microservicios introducen complejidad, que hay que gestionar. Hay que hacer un gran esfuerzo en despliegues automáticos (si tienes 300 microservicios no puedes estar desplegando cada uno de ellos a mano), monitorización (si falla uno, no puedes ir mirando uno a uno a ver qué pasa), gestionar fallos, consistencia de datos, estrategia de pruebas y más factores que introducen los sistemas distribuidos. Como dice Martin Fowler: “hay formas conocidas de gestionar todo esto, pero es esfuerzo extra, y nadie que conozco en desarrollo software parece tener muchísimo tiempo libre.” Por otra parte, yo diría que si tu software es muy simple, no te metieras en un enfoque de microservicios. En cambio, si ya se vuelve muy complejo de gestionar y vale la pena invertir esfuerzo en ello, adelante. Empresas muy grandes lo han hecho. Puede que haya gente que desarrolle una aplicación nueva utilizando microservicios, pero el enfoque que más me he encontrado es de empresas que han visto que gestionar su software como “monolito” es tan complejo, que han empezado a separar la aplicación en microservicios o a gestionar desarrollos nuevos de esa manera. En este caso, si aconsejaría evolucionar la arquitectura hacia microservicios, pero poco a poco, manteniendo una parte monolítica, combinada con ciertos microservicios separados (las zonas más urgentes de la aplicación que necesitan ser desacopladas). Para hacer esto, por ejemplo, podemos utilizar la técnica de Branch By Abstraction, entre otras estrategias. Pero no lo olvides, analiza la situación, no quieras implantar microservicios porque sea lo “que se lleva ahora”. Hay muchos tipos de arquitecturas y soluciones, la cuestión está en ver qué es lo que más nos conviene en cada momento.

http://www.javiergarzas.com/2015/06/microservicios.html