Nueva tendencia; micro servicios
¿Quién expone que es tendencia?
API tradicional…
Tradicionalmente, de
forma local, una API (Interfaz de programación
de aplicaciones) se expone a través de archivos DLL. Esto supone una dependencia de tecnología y versiones. En la Web,
un API se expone a través de Servicios Web, que permiten que las aplicaciones
cliente obtengan y realicen operaciones con los datos que el servicio expone.
Fortaleciendo el concepto de micro servicios
Una arquitectura de
micro servicios, 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.
§ Cada uno es independiente (sigue los principios SOLID)
§ Una forma de comprobar su independencia, es que,
debería poderse cambiar su lenguajes de programación sin afectar su
funcionamiento.
No hay reglas sobre
qué tamaño tiene que tener cada micro servicio, ni sobre cómo dividir la
aplicación en micro servicios, pero algunos autores como Jon Eaves caracterizan un micro servicio como algo, que
a nivel de código podría ser reescrito en dos semanas.
Arquitectura Monolítico vs. Micro servicios
Imagina que
queremos realizar una aplicación web, tipo Amazon, pero más sencilla. Los
usuarios entran por nuestra web, ven los productos que tenemos en venta, y
cuando compran un artículo, gestionamos el envío del producto a su domicilio.
Visión Monolítica
Una primera
idea de cómo afrontar esta aplicación sería la siguiente arquitectura
monolítica:
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, que
eventualmente se conecta a una base de datos para recuperar información.
Cuando un
usuario compre un producto vía web, mostramos los productos disponibles, etc.,
la aplicación responderá, 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 ejecutable. A este modelo se le conoce como
monolítico.
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 re direccionando 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.
Visión de Micro servicios
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 micro servicio, que implementa la interfaz web con la
que interactúan los usuarios y cierta lógica por debajo para llamar al micro servicio
de pagos, inventario y envíos cuando sea necesario.
Beneficios de esta visión
§ 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
§ 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 micro servicios que tengan más carga.
Podemos formar equipos multifuncionales, que se
encarguen de varios micro servicios, escalando el proceso de desarrollo de
forma más sencilla.
-Bajo esta arquitectura, una buena práctica de
trabajo, es separar a los equipos como unidades independientes integradas, ¿qué
quiere decir esto? Que podemos tener una unidad de trabajo construyendo un
Front-End y paralelamente podemos tener otra unidad, construyendo un
Back-End. Esto abre un abanico de posibilidades, por ejemplo, concentrar el
conocimiento de negocio, en los equipos internos con los procesos Core como
Back-End.
Observación de documentación
Ninguna
arquitectura, ninguna lógica, ningún sistema, por robusto que sea, puede ser
100% exitoso, si carece de documentación.
https://es.wikipedia.org/wiki/Sistemas_monol%C3%ADticos
No hay comentarios:
Publicar un comentario