Ampliación - Arquitectura basada en microservicios PDF

Preview

Summary

Arquitectura basada en microservicios...

Description

Ampliación

Luis Guajardo Homs

Arquitectura basada en microservicios Actividad Ampliación

Luis Guajardo Homs

1

Ampliación

Luis Guajardo Homs

Índice

Introducción ………………………………………………………….…………3 Definición ……………………………………………………………….....……3 Diferencias entre Arquitectura tradicional y Microservicios …………...…..4 Beneficios ……………………………………………………………….….…..5 Contras ………………………………………………………………….….…..6 Implementación ……………………………………………………….…….…6 modelo de referencia ………………………………………………...6 modelo de implementación ……………………………….………....7 despliegue de microservicios …………………………………….....8 Ejemplos de microservicios ……………………………………………….....9 Conclusiones ………………………………………………..………………...11 Bibliografía ………………………………………………………………...…..12

2

Ampliación

Luis Guajardo Homs

Introducción

La historia de los microservicios podríamos decir que se inicia con un grupo de arquitectos de software que se pusieron de acuerdo en utilizar la palabra para caracterizar los sistemas en cuyo desarrollo estaban involucrados. Con la influencia de algunos de los pioneros en el campo, los microservicios han ido ganando presencia y, hoy en día, se aceptan en la industria como un estilo arquitectónico bien establecido. Muchas organizaciones están migrando sus sistemas a esta arquitectura, descomponiendo sus monolitos en unidades más pequeñas y distribuidas.

La gran ventaja de una arquitectura de microservicios es que ofrece cada uno de los componentes de forma aislada, siendo más fáciles de mantener y de responder frente a distintos niveles de escalabilidad. Permite replicar aquellas instancias de microservicios que sean necesarios, evitando, como es en el caso de la arquitectura monolítica, tener que replicar una copia de toda la aplicación en su conjunto.

Definición

Los microservicios consiste en construir una aplicación como un conjunto de pequeños servicios, los cuales se ejecutan en su propio proceso y se comunican con mecanismos ligeros

Los microservicios son tanto un estilo de arquitectura como un modo de programar software. Con ellos, las aplicaciones se dividen en sus 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 las mismas tareas. Cada uno de esos elementos o procesos es un microservicio. Los podemos resumir como un tipo de arquitectura que sirve para diseñar aplicaciones. Tradicionalmente, la arquitectura de las aplicaciones es monolítica, es decir que nuestra aplicación está compuesta por un solo programa que usa una base de datos. Una arquitectura monolítica es autónoma, es decir, no depende de otros servicios externos a ella y únicamente se centra en sus propios componentes.

3

Ampliación

Luis Guajardo Homs

La arquitectura de microservicios en cambio, se caracteriza por modularizar las aplicaciones en muchos programas diferentes que comunican entre sí, para en conjunto cumplir con los requerimientos del sistema. Cada microservicio se encarga de implementar un componente de la aplicación entera. Son muchos servicios pequeños que conversan. Usualmente la comunicación se hace con REST.

Diferencias entre Arquitectura tradicional y Microservicios

Lo que distingue a la arquitectura de microservicios de los enfoques tradicionales y monolíticos es la forma en que desglosa una aplicación en sus funciones principales. Cada función se denomina servicio y se puede diseñar e implementar de forma independiente. Esto permite que funcionen separados (y también, fallen por separado) sin afectar a los demás.

Una arquitectura de microservicios no solo se refiere a las funciones principales de una aplicación que no están conectadas directamente. Descomponen una aplicación en sus funciones principales y evitan los riesgos de las arquitecturas monolíticas

En los inicios del desarrollo de software (y aún en muchos negocios hoy), existe el concepto de monolítico.Llamamos a una aplicación “monolítico" porque el código fuente para toda la aplicación se crea en una única pieza de implementación. Si las actualizaciones de una parte de la aplicación generan errores, se debe desconectar toda la unidad, analizar y solucionar el error. Todos los componentes de la aplicación residen en un área, incluida la capa de interfaz gráfica, la capa de lógica de negocios y la capa de acceso a datos. Crear aplicaciones monolíticas es un proceso fácil y natural, y la mayoría de proyectos comienzan de esta manera. Pero agregar funcionalidad a la base de código provoca un aumento tanto en el tamaño como en la complejidad, y permitir que este tipo de aplicaciones crezca conlleva desventajas con el tiempo. Si bien este enfoque todavía es viable para las aplicaciones pequeñas, las empresas en crecimiento no pueden permitirse ese tiempo de inactividad.

4

Ampliación

Luis Guajardo Homs

En un principio se crearon las aplicaciones web ejecutadas en el servidor en lo que ahora denominamos monolitos. Más recientemente con las nuevas posibilidades de la virtualización, los contenedores, la computación en nube con la flexibilidad que aporta de reservar recursos de computación bajo demanda en minutos y para evitar varios problemas que presentan los monolitos se evoluciona hacia microservicios. Esto no quiere decir que los monolitos, con este nombre con cierto matiz peyorativo que ha adquirido, no sigan siendo perfectamente válidos en algunos contextos en los que ahora se usan. Sin embargo, en el contexto de la computación en la nube y servicios para un gran número de peticiones, usuarios o aplicación funcionalmente grandes los microservicios se adaptan mucho mejor.

Los problemas que presentan las aplicaciones monolíticas donde toda la lógica de una aplicación está en un servidor son: ●

Son grandes y difíciles de modificar.

●

Realizan múltiples funcionalidades.

●

Hay un único punto de fallo, un error puede afectar al sistema entero.

●

Requieren escalar el monolito entero, lo que es poco eficiente.

●

Hacen muy difícil emplear la tecnología más adecuada para cada problema de la aplicación o adoptar nuevas.

●

Los despliegues de nuevas versiones pueden ser problemáticos por el tamaño de la aplicación.

5

Ampliación

Luis Guajardo Homs

En definitiva, las aplicaciones monolíticas son muy difíciles de mantener debido principalmente a su falta de modularidad y escalabilidad.

Beneficios Los microservicios surgen como alternativa tratando de resolver los problemas de las aplicaciones monolíticas aunque planteando nuevos retos pero también varios beneficios: ●

Las aplicaciones basadas en microservicios se componen de múltiples aplicaciones cada una con un contexto delimitado pequeño que se comunican mediante la red.

●

Son más pequeños con una base de código menor y por tanto más fáciles de modificar o en su caso reemplazar siempre se implemente la misma interfaz o contrato.

●

No son tan dependientes de la tecnología pudiendo elegir la más adecuada en cada uno de ellos. Son aplicaciones más abiertas, los desarrolladores tienen la libertad de elegir los mejores lenguajes y tecnologías para la función que se necesita.

●

Al ser más pequeños se pueden escalar más fácilmente horizontalmente. Basta con escalar el servicio que lo requiera. Tiene por tanto una gran capacidad de expansión, es posible realizar implementaciones en distintos servidores.

●

Accesibilidad - las aplicaciones más grandes se desglosan en piezas más pequeñas. Los desarrolladores pueden comprender, actualizar y mejorar más fácilmente esas piezas; de esta manera, se obtienen ciclos de desarrollo más rápidos

●

Arrancan más rápido y son más fáciles de desplegar.

●

Cada microservicio puede estar desarrollado por un equipo diferente centrado en ese servicio.

●

Capacidad de recuperación - si una parte falla, no afecta a toda la aplicación, a diferencia del modelo de aplicaciones monolíticas.

Contras Un gran número de servicios puede dar lugar a grandes bloques de información que gestionar. Será labor de los desarrolladores lidiar con aspectos como la latencia de la red, tolerancia a fallos, balanceo de carga, cantidad de formatos admitidos, etc… Sistema distribuido puede llegar a significar doble trabajo entre pruebas y tests. Esta tecnología suele incurrir en un alto consumo de memoria.

6

Ampliación

Luis Guajardo Homs

Fragmentar una aplicación en diferentes microservicios puede llevar muchas horas de planificación (y casi podría considerarse un arte).

El objetivo es distribuir sistemas de software de calidad con mayor rapidez, pero también se deben considerar otros aspectos. Dividir las aplicaciones en microservicios no es suficiente; es necesario administrarlos, coordinarlos y gestionar los datos que crean y modifican.

Implementación Para la implantación de una arquitectura de microservicios hemos tener en cuenta 3 aspectos principalmente: ●

Un modelo de referencia en el que definir las necesidades de una arquitectura de microservicios.

●

Un modelo de implementación en el que decidiremos y concretamos la implementación de los componentes vistos en el modelo de referencia.

●

Un modelo de despliegue donde definir cómo se van a desplegar los distintos componentes de la arquitectura en los diferentes entornos.

Modelo de referencia Los siguientes serán los componentes que vamos a necesitar en una arquitectura de microservicios: ●

Servidor de configuración central Este componente se encargará de centralizar y proveer remotamente la configuración

a

cada

microservicio.

Esta

configuración

se

mantiene

convencionalmente en un repositorio Git, lo que nos permitirá gestionar su propio ciclo de vida.

●

Servicio de registro / descubrimiento Este servicio centralizado será el encargado de proveer los endpoints de los servicios para su consumo.

●

Balanceo de carga

7

Ampliación

Luis Guajardo Homs

Este patrón de implementación permite el balanceo entre distintas instancias de forma transparente a la hora de consumir un servicio.

●

Tolerancia a fallos Mediante este patrón conseguiremos que cuando se produzca un fallo, este no se propague en cascada por todo el pipe de llamadas, y poder gestionar el error de forma controlada a nivel local del servicio donde se produjo.

●

Servidor perimetral / exposición de servicios (Edge server) Será un gateway en el que se expondrán los servicios a consumir.

●

Centralización de logs Se hace necesario un mecanismo para centralizar la gestión de logs. Pues sería inviable la consulta de cada log individual de cada uno de los microservicios.

●

Servidor de Autorización Para implementar la capa de seguridad (recomendable en la capa de servicios API)

●

Monitorización Es interesante el poder disponer de mecanismos y algún dashboard para monitorizar aspectos de los nodos como, salud, carga de trabajo…

Modelo de implementación

A pesar del aumento de la competencia, Java continúa no solo sobreviviendo sino también sobresaliendo. Muchos de los equipos encargados del desarrollo de arquitecturas de microservicio siguen utilizando Java. Las arquitecturas de software son totalmente ajenas a los lenguajes de programación, pues solo establecen la forma en la que las tecnologías deberían de funcionar y no como fueron implementadas, es por eso que tenemos una gran variedad de frameworks que nos ayudan a implementar microservicios, se podría programar de formas diferentes, pero son profundamente parecidas en la forma en que trabajan.

8

Ampliación

Luis Guajardo Homs

Existen frameworks que implementan esta arquitectura para facilitarnos la vida, como es el caso de Spring Boot en Java o Express para NodeJS.

Despliegue de microservicios Nos referimos al modo en que vamos a organizar y gestionar los despliegues de los microservicios, así como a las tecnologías que podemos usar para tal fin. Existen convencionalmente dos tendencias en este sentido a la hora de encapsular microservicios: ●

Máquinas virtuales.

●

Contenedores.

Los microservicios están muy ligados al concepto de contenedor, una unidad estándar de software que empaqueta el código junto a todas de sus dependencias para que el servicio o aplicación se ejecute de forma rápida y fiable de un entorno informático a otro. Se trata pues de una imagen portátil que contiene todo lo necesario para ser ejecutada en entornos distintos y su comportamiento será siempre el mismo independientemente del entorno. Con el fin de conseguir aislamiento entre procesos y aplicaciones, existen técnicas como la virtualización que permiten ejecutar partes de aplicación o servicios en entornos aislados e independientes. Sin embargo, presenta una serie de desventajas como: redundancia del kernel para cada máquina virtual, sistemas operativos duplicados en muchos casos, consumo elevado de recursos al aumentar la cantidad de máquinas en ejecución... Así fue cómo surgió la necesidad de los contenedores: un enfoque nuevo basado en técnicas de virtualización ligera que permite aislar completamente a las aplicaciones haciendo uso de un único sistema operativo

Por otro lado tenemos el concepto Docker, una plataforma de contenedores cuyo fin es ejecutar aplicaciones de forma aislada y eficiente. Es un software de gestión de contenedores empresariales. Puede considerar a un contenedor como una máquina virtual muy sencilla. Un contenedor le permite ejecutar aplicaciones en su propio espacio de memoria aislado y mantener el acceso a recursos comunes, como los sistemas de archivos. Los Dockers necesitan de una imagen para su encapsulación. Una imagen de Docker consiste en un paquete de software independiente y ejecutable que incluye todo lo necesario para ejecutar una aplicación: código, tiempo de ejecución, herramientas del

9

Ampliación

Luis Guajardo Homs

sistema, librerías y configuraciones. Los Dockers aíslan el software de su entorno y garantizan que funcione de manera uniforme. Además, un Docker no solo se utiliza para desplegar aplicaciones en producción, sino también para crear entornos de desarrollo replicables entre todos los miembros de un equipo, asegurar que las aplicaciones se van a ejecutar igual en todos los entornos, etc.

Ejemplos de Microservicios. La arquitectura de microservicios ya está muy de moda y muchas empresas quieren implementarla.

No hay mejor forma de conocer el alcance que ha tenido este método de desarrollo que ver quiénes lo han implementado. Multitud de webs que sirven aplicaciones a gran escala han decidido invertir en la evolución hacia los microservicios en vistas de un futuro donde el mantenimiento y escalabilidad de sus productos es mucho más simple, efectivo y rápido. Vamos a destacar algunas de estas compañías:

Netflix es la empresa que más popularizó la arquitectura de microservicios. Ahora tienen miles de servicios que trabajan juntos para que puedas mirar la última serie en streaming. Pero también Ebay, Amazon, Facebook, Uber y muchas empresas más están usando microservicios. Muchas más están migrando su monolito a una arquitectura de microservicios.

10

Ampliación

Luis Guajardo Homs

Netflix tiene una arquitectura generalizada que desde hace ya unos cuantos años se pasó a los microservicios para el funcionamiento de sus productos. Le permite ofrecer servicios de streaming digital de calidad en centenares de distintas pantallas y dispositivos a millones de clientes en todo el mundo.

Tomando Netflix como ejemplo, podríamos imaginar que tengan un microservicio diferente para: ●

el sistema de recomendación según lo que miras

●

manejar los pagos

●

comprimir el vídeo

●

encontrar subtítulos según el lenguaje

●

etc

Amazon, no soporta tantos dispositivos como Netflix, pero tampoco es que sea fundamental para cubrir su sector. Migró hace años a la arquitectura de microservicios siendo una de las primeras grandes compañías que la implementan en producción. No hay cifra aproximada de la cantidad de solicitudes que pueden recibir a diario, pero no son pocas. Entre éstas encontramos multitud de aplicaciones, las API del servicio web que ofrecen o la propia web de Amazon, cuyos ingenieros reconocen que habría sido imposible sobre la arquitectura monolítica con la que trabajaban previamente.

Twitter también adoptó los microservicios para poder soportar la ingente cantidad de tráfico que recibe.

Otra de las empresas que apuesta por los microservicios es Ebay, una de las empresas con mayor visión de futuro, pionera en la adopción de tecnologías como Docker o la de microservicios. Su aplicación principal comprende varios servicios autónomos, y cada uno ejecutará la lógica propia de cada área funcional que se ofrece a los clientes.

11

Ampliación

Luis Guajardo Homs

Conclusiones: La arquitectura de microservicios definen una forma de trabajar con grandes aplicaciones más desacopladas y surge para atender unas demandas muy exigentes en cuanto a alta disponibilidad y capacidad de adaptación y cambio. No tiene por qué ser la mejor solución para todos los caso. En general, está indicado para grandes aplicaciones, con grandes volúmenes de peticiones (especialmente si se sufren fuertes picos de demanda) y con necesidad de alta disponibilidad. Si esta es la situación, esta arquitectura nos ayudará a ser más ágiles y conseguir atender nuestras necesidades de una forma estructurada y probada. Una aplicación que no esté apoyada sobre este tipo de arquitectura de microservicios a futuro nos puede provocar inconvenientes en su evolución o mantenimiento.

Podemos decir que los microservicios son el futuro para el desarrollo de aplicaciones. Responden a las necesidades que las aplicaciones tienen hoy en día dentro de un marco empresarial. Son sistemas de alto rendimiento, ofrecen alta disponibilidad, y también, al ser más pequeños y especializados aportan mayor eficiencia. Las empresas deberían invertir en este tipo de tecnologías. Cuando hablamos de inversión hay que tener en cuenta que va vinculado a un proyecto y como en cualquier proyecto, hay una fase previa de análisis en la que se va a tener como resultado cuál es la solución más adecuada. En cualquier caso, está claro que los microservicios están aquí para quedarse y quizá fusionarse con otras explosiones tecnológicas como la IoT.

12

Ampliación

Luis Guajardo Homs

Bibliografía Comunytek.

Introducción

a

los

Microservicios.

comunytek.com.

Enlace:https://comunytek.com/introduccion-a-los-microservicios/ RedHat. ¿Qué son y para qué sirven los microservicios? redhat.com. Enlace: https://www.redhat.com/es/topics/microservices Daniel

Sanchez(2016).

Arquitectura

de

micro...