En un post anterior hablaba de cajas y cómo desmontar un programa (caja) en operaciones (cajas más simples) para encontrar una rápida y mejor solución. Cuando hablamos de microservicios, podemos hacer un símil con la solución anterior, pero llevándolo a un contexto más complejo, como son los servicios en la nube.
Los microservicios son tanto un estilo de arquitectura como un modo de programar. Con los microservicios, las aplicaciones se dividen en elementos más pequeños e independientes entre sí. A diferencia del enfoque tradicional y monolítico de las aplicaciones, en el que todo se compila en una sola pieza, los microservicios son elementos independientes que funcionan en conjunto para llevar a cabo diferentes tareas. Cada uno de esos elementos o procesos comentados anteriormente son un microservicio.
Fuente: RedHat
Fuente: Microsoft
Las principales ventajas de su uso son:
Alguna de las características más importantes son:
Para lograrlo, en primer lugar hemos de hacer uso de frameworks que nos permiten la construcción de pequeños módulos, que se puedan comunicar, y que sean independientes los unos de los otros. Existen diferentes para lograrlo, y en este post se describirán las características básicas de dos de estos.
Es un framework que nace en Marzo de 1999, orientado a Servicios e implementado en Java, que define una forma de crear módulos y la forma en que estos interactúan entre sí en tiempo de ejecución. Este es apoyado por la OSGi Alliance, es un consorcio de empresas tecnológicas a nivel mundial que trata de asegurar la interoperabilidad de las aplicaciones y servicios. Algunos ejemplos de miembros: Motorola, Nokia, Mitsubishi Electric Corporation, Vodafone Group Services, LinkedIn, LG Electronics, etc. Como en otros proyectos, un grupo de empresas apoyan un proyecto para solventar sus necesidades.
Este framework provee al desarrollador de un entorno Java gestionado y seguro que permite el despliegue de aplicaciones denominadas bundles. El framework de OSGI permite la descarga, instalación y borrado de bundles en tiempo de ejecución.
OSGi intenta solventar los problemas del tradicional “classloader” de la máquina virtual y de los servidores de aplicaciones Java. Para ello, en OSGI cada bundle tiene su propio classpath separado del resto de classpath de los demás módulos. Destacaría esta como la principal característica del desarrollo a través de bundles, siendo totalmente opuesto a los .jar característicos de Java.
La arquitectura OSGI se divide en capas, tal y como se muestra en la siguiente figura, las cuales se detallan a continuación:
Fuente: OSGI.ORG
Major: Actualizaciones incompatibles para ambos, el consumidor y el publicador de la API.
El consumidor de una API deberá importar un rango donde el primer elemento es la versión mínima y termina con la versión mayor, que deja de ser compatible. Por ejemplo: [4.2,5).
¡¡¡ Sed buenos, disfrutad programando y recuerda que el siguiente post está a medio cocer. 😉 !!!!.