Building Micro Services
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.
¿Qué son los micro servicios?
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
Ventajas
Las principales ventajas de su uso son:
- Desarrollar microservicios, repercute en poder aislar los errores, cuando se producen y facilitar su resolución.
- Se produce una mezcla de tecnologías, lo cual, enriquece el conjunto.
- Se facilita la escalabilidad cuando las necesidades lo requieren.
- Cada micro servicio puede aislar sus datos, si la lógica de negocio así lo indicará.
Características
Alguna de las características más importantes son:
- Los microservicios son pequeños e independientes, de modo que el desarrollo lo puede realizar un equipo pequeño.
- Los detalles de la implementación interna de cada servicio se ocultan frente a otros servicios.
- No es necesario que los servicios compartan la misma tecnología, o bibliotecas.
- La comunicación se realiza a través de una API bien definida. Este será uno de los ejes principales en el desarrollo de servicios.
¿Cómo lo logramos?
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.
OSGI (Open Services Gateway Initiative)
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
- Bundles: Componentes OSGI creados por los desarrolladores.
- Servicios: Capa encargada de conectar distintos bundles de manera dinámica.
- Ciclo de vida: API que permite instalar, iniciar, parar, actualizar y desinstalar bundles sin necesidad de reiniciar el framework.
- Módulos: Capa que define cómo importar/exportar código fuente de un bundle.
- Seguridad: Capa que administra los aspectos de seguridad del framework.
- Entorno de ejecución: Especifica qué métodos están disponibles en la plataforma.
Resolución de Dependencias
Major: Actualizaciones incompatibles para ambos, el consumidor y el publicador de la API.
- Minor: Actualizaciones compatibles para el consumidor pero no para el proveedor de la API.
- Micro: Actualizaciones que no afectan al API, por ejemplo, un fix.
- Qualifier: Un identificador como puede ser un timestamp.
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. 😉 !!!!.