En esta ocasión estaremos hablando de microservicios, una tendencia de desarrollo que ha surgido en los últimos años, impulsada, principalmente, por grandes empresas de software las cuales desarrollan productos bajo un enfoque agilista.
Este post es bastante interesante así que no perdamos más el tiempo y comencemos 😎
Sistemas monolíticos
Para comprender de una mejor manera los microservicios primero debemos de definir y comprender que es un sistema monolítico. Veamos 😃.
Imaginemos que nos encontramos desarrollando un sistema el cual nos permite realizar compras en línea.
El sistema será capaz de trabajar con múltiples usuarios, realizar búsquedas, crear carritos de compras, realizar pagos y por supuesto, monitorear la existencia de productos (todo esto a muy grandes rasgos).
El siguiente diagrama ilustra de una mejor manera el sistema utilizando una arquitectura centralizada.
Nuestro sistema es un típico sistema monolítico ya que todas las reglas de negocio se encuentran en una sola aplicación y todos los datos se encuentran almacenados en una sola base de datos.
Un sistema monolítico no es más que un sistema autónomo, un sistema el cual no depende de otras piezas de software y obedece únicamente a los componentes que están en su interior.
Si el sistema se mantiene pequeño nuestra aplicación será fácil de mantener. Sin embargo, la tendencia de una aplicación es crecer, incorporar nuevos features, nuevas reglas de negocio, nuevas vistas, etc...
Con el paso del tiempo las aplicaciones incrementarán su tamaño y con esto la complejidad del mantenimiento. Realizar cambios sobre un proyecto monolítico podrá llegar a ser una tarea complicada, que implique grandes riesgos, principalmente, por el alto grado de acoplamiento que posee el software.
Cuando dos o más piezas de software se encuentran estrechamente relacionadas podemos decir que poseen un alto grado de Cohesión.
Al encontrarse todos los módulos del sistema en una sola aplicación, estos poseen una estabilidad muy debil. Cada modulo depende de otros para su correcto funcionamiento. Si un modulo falla este puede ocasionar que otros así lo hagan y con esto el sistema completo 😰.
Oye, pero no todo es malo, también existen ventajas de trabajar con sistemas monolíticos. Por ejemplo:
- Comenzar un proyecto es muy sencillo. Todo se esculpe bajo una misma pieza.
- Una base de datos centralizada simplifica el diseño y la organización de la información.
- Realizar el deploy de una solo aplicación es una tarea "fácil".
Microservicios
Debido al fuerte acomplamiento del software y al gran coste en cuanto a tiempo y recursos para realizar modificacones a sistemas monolíticos, surge la necesidad de los microservicios.
Los microservicios son una arquitectura en la cual diferentes piezas de software son diseñadas como servicios individuales.
Cada uno de estos servicios son puestos en producción de forma separada y tienen comunicación unos con otros a través de una red previamente definida. Comunmente la comunicación se hará a traves del protocolo HTTP mediante un arquitectura REST. Los datos serán transferidos mediante un formato JSON, aun que también es posible utilizar XML o YAML.
Los microservicios serán diseñados lo más pequeños posible, de tal forma que estos se encuentren enfocados en realizar una y solo una tarea.
Nuestro sistema utilizando microservicios pudiese verse ilustrado de la siguiente manera.
Con este enfoque no existe una base de datos centralizada, cada uno de los servicios interactúa con sus propios datos.
Alguno de los beneficios de utilizar microservicios son:
- Separación del problema (Divide y vencerás).
- Pequeños proyectos.
- Mayor escalabilidad y opciones de deploy.
Examinemos más en detalles cada una de estas ventajas.
Separación del problema
Al nosotros dividir el problema, cada microservicio podrá ser desarrollado de forma independiente por un equipo separado. El microservicio podrá ser desarrollado con cualquier lenguaje de programación o base de datos, podrá ser compilado y ejecutado por cualquier sistema operativo.
Este desacoplamiento responde al principio de responsabilidad simple, en donde se especifica que una clase debe de tener una y solo una razón para cambiar. En otras palabras una clase debe de realizar una y solo una tarea.
Pequeños proyectos
Al tener un pequeños proyectos el control sobre estos será mayor. Cualquier cambió podrá ser monitoreado y en caso de algún fallo este no afectará al funcionamiento global de la aplicación.
Si el equipo de trabajo quiere experimentar con algún nuevo lenguaje o tecnología es posible crear un prototipo funcional e implementarlo en la API sin restructurar todo el proyecto.
Los servicios son independientes, estos no tienen por que conocer el funcionamiento de otros. Unicamente deben de saber los datos a enviar y la salia esperada.
Mayor escalabilidad y opciones de deploy
Al nosotros dividir el sistema en pequeños servicios estos se vuelven fáciles de escalar. Cada microservicio puede encontrarse en servidores diferentes, servidores con especificaciones técnicas diversas.
Quizás tengamos la necesidad de ejecutar servicios sobre equipos los cuales tengan un hardaware en concreto. No será lo mismo en cuanto a términos computacionales ejecutar un microservicio que procese imágenes en comparación con uno que genere PDF's.
Los microservicios tienen muchas ventajas, por ejemplo, mayor rapidez en cuando a entregas, mayor seguridad de datos o menor grado de errores, sin embargo, nada es perfecto. Los microservicios también poseen desventajas. La principal desventaja es que al introducir esta arquitectura a un proyecto la dificultad tecnica se incrementa. Con los microservicios se pasa de tener un equipo pequeño de desarrollo a multiples equipos (Pensando que cada equipo mantiene un servicio).
Los microservicios no son para todos. Si el equipo en donde te encuentras trabajando no es muy grande, 10, 20 o 30 desarrolladores, quizás, tu proyecto aun no merezca un cambio de arquitectura. Recueda, es mucho mejor enfocarse en mejorar el producto que en las dificultades tecnicas de un cambio de enfoque 😃.