Presentación de la arquitectura de microservicios del Málaga JUG de Marzo de 2018

1. ARQUITECTURA
DE
MICROSERVICIOS
El mapa completo
15/Mar/18

2. Sobre nosotros
■ Julio Palma
■ Twitter: @restalion
■ GitHub: github.com/restalion
■ Technology Architect en Tecnilógica
■ Juanma Cintas
■ Twitter: @juanmacintas
■ GitHub: github.com/juanmacintas
■ Senior Analyst en Tecnilógica

3. Objetivos de la sesión
 Tener una solución basada en microservicios en producción y poder dormir todas
las noches.
 Entender las diferencias entre una arquitectura monolítica y otra basada en
microservicios.
 Crear un mapa de todos los servicios que necesitaremos de la outer architecture
que nos permita “montar” una solución completa.
 Identificar algunas alternativas para cubrir cada una de las áreas de la outer
architecture.

4. Objetivos de la sesión
 Tener una solución basada en microservicios en producción y poder dormir todas
las noches.
 Entender las diferencias entre una arquitectura monolítica y otra basada en
microservicios.
 Crear un mapa de todos los servicios que necesitaremos de la outer architecture
que nos permita “montar” una solución completa.
 Identificar algunas alternativas para cubrir cada una de las áreas de la outer
architecture.
¿Qué es la Outer
Architecture?

5. Monolito
Monolito

6. Monolito
Monolito
Un único .war
representa una
“Solución”

7. Monolito
Monolito
EIS

8. Servicios
DAO
Monolito
Monolito
EIS
Presentación

9. Métricas
Gestión de erroresServicios
DAO
Monolito
Monolito
PresentaciónConfiguración
Logs
Auditoría
Inversión del
Control
EIS
Seguridad

10. Métricas
Gestión de erroresServicios
DAO
Monolito
Monolito
Presentación
Inversión del
Control
EIS
DAO DAO
EIS EIS
Configuración
Logs
Auditoría
Seguridad

11. Métricas
Gestión de errores
Servicio
DAO
Monolito
Monolito
Presentación
Inversión del
Control
EIS
DAO DAO
EIS EIS
Servicio Servicio Servicio
Configuración
Logs
Auditoría
Seguridad

12. Monolito
1. Una única aplicación para implementar toda la funcionalidad.
2. Un ecosistema común para todas las piezas de la aplicación.
3. Reutilización basada en los componentes (importación).
4. Sencillez de despliegue.
5. Una única versión de los componentes.
6. Aplicaciones complejas cuya responsabilidad es implementar todo el negocio.
7. Fragilidad: un error en cualquier pieza tumba todo el monolito.

13. Métricas
Gestión de errores
Servicio
DAO
Microservicios
Monolito
Presentación
Inversión del
Control
EIS
DAO DAO
EIS EIS
Servicio Servicio Servicio
Configuración
Logs
Auditoría
Seguridad

14. Métricas
Gestión de errores
Servicio
DAO
Microservicios
Presentación
Inversión del
Control
EIS
DAO DAO
EIS EIS
Servicio Servicio Servicio
Configuración
Logs
Auditoría
Seguridad

15. Métricas
Gestión de errores
Servicio
DAO
Microservicios
Presentación
Inversión del
Control
EIS
DAO DAO
EIS EIS
Servicio Servicio Servicio
Configuración
Logs
Auditoría
Seguridad
*HTTP

16. Métricas
Resistencia
a errores
Servicio
DAO
Microservicios
Presentación
Localización de
servicios
EIS
DAO DAO
EIS EIS
Servicio Servicio Servicio
Configuración
centralizada
Logs distribuidos
Auditoría
Seguridad
(MMI y M2M)

17. Métricas
Resistencia
a errores
Servicio
DAO
Microservicios
Presentación
Localización de
servicios
EIS
DAO DAO
EIS EIS
Servicio Servicio Servicio
Configuración
centralizada
Logs distribuidos
Auditoría
Seguridad
(H2M y M2M)
Composición
de la solución
Gestión de
la carga
Documentación de
interfaces

18. Microservicios
1. Muchas aplicaciones que implementan la funcionalidad completa.
2. Ecosistema políglota dentro de una misma solución.
3. Reutilización basada en uso (llamada a interfaces).
4. Despliegue sencillo de cada aplicación, complejo en la solución completa.
5. Varias versiones de la misma aplicación pueden convivir en ejecución.
6. Cada aplicación tiene la responsabilidad (y exclusiva) en un área concreta de la
solución.
7. Se pueden desplegar de forma independiente.
8. Se incrementa la latencia y el tráfico de red.

19. Objetivos de la sesión
 Tener una solución basada en microservicios en producción y poder dormir todas
las noches.
 Entender las diferencias entre una arquitectura monolítica y otra basada en
microservicios.
 Crear un mapa de todos los servicios que necesitaremos de la outer architecture
que nos permita “montar” una solución completa.
 Identificar algunas alternativas para cubrir cada una de las áreas de la outer
architecture.

20. Estructura de los microservicios
1. BBDD H2 en memoria
2. Acceso con Spring Data
3. Servicios Spring
4. REST Interface
5. Project Lombok
6. Swagger

21. Servicios de ejemplo

22. Outer Architecture
Métricas
Resistencia
a errores
Localización de
servicios
Configuración
centralizada
Logs distribuidos
Auditoría
Seguridad
(H2M y M2M)
Composición
de la solución
Gestión de
la carga
Documentación de
interfaces

23. Configuración
Outer Architecture - Monolito
■ En una aplicación monolítica la configuración de la aplicación se puede realizar
mediante múltiples formas:
– Fichero de propiedades
– Parámetros de configuración en la ejecución
■ La configuración no suele ser un gran problema podemos tener varios tipos de
ficheros, perfiles… que se seleccionan en el momento de “levantar” la aplicación.
■ Tenemos un número limitado de instancias (desarrollo, preproducción,
producción,…) cada una con su configuración específica.
■ Normalmente es el equipo de operaciones el encargado de configurar y mantener
la configuración de los distintos entornos.

24. Outer Architecture - Microservicios
Configuración
centralizada
■ En un esquema de microservicios la operación se complica:
– Múltiples instancias de la misma aplicación con el mismo perfil, o distinto.
– Versiones distintas del mismo servicio en el mismo entorno.
■ El mantenimiento de las aplicaciones en ejecución se puede llevar desde una
plataforma (sin intervención humana directa).
■ Rolling updates, de los servicios

25. Outer Architecture - Microservicios
Configuración
centralizada
■ Ejemplo: Config server
■ Distintos tipos de clientes dependiendo de la naturaleza de la aplicación.

26. Seguridad
Outer Architecture - Monolito
■ El control de acceso a la aplicación se realiza una vez.
– Si tienes acceso mientras dure tu sesión podrás ejecutar todos los servicios
que te permita tu perfil.
■ El acceso al frontal y a los servicios está unificado.

27. Outer Architecture - Microservicios
Seguridad
(H2M y M2M)
■ Podemos tener esquemas de seguridad independientes por cada servicio o
frontal.
■ Hay que diferenciar entre la seguridad para el acceso a la aplicación por parte
de humanos y las llamadas entre máquinas.
■ Nos permite granularidad a la hora de definir quién tiene acceso a qué servicio
o funcionalidad.
■ Podemos establecer criterios como cuotas de uso.
■ Permite monetizar el consumo de servicios.

28. Outer Architecture - Microservicios
Seguridad
(H2M y M2M)
IAM
Presentación
Authorization Server
µServices
1
2
3
4
5
6 78
9 10
Acceso a la aplicación de presentación (SAML)
1. El usuario accede a la aplicación de presentación.
2. Se comprueba si está presente el token SAML. Si no redirigimos
al IAM.
3. El IAM muestra la pantalla de login.
4. El usuario introduce sus credenciales.
5. Si son válidas, el IAM genera el token SAML y redirige a la
aplicación de presentación.
Acceso a la aplicación de backend (OAuth2)
6. Se solicita el token al authorization server con las credenciales
del consumidor.
7. Si son válidas genera un token y lo devuelve.
8. Se realiza la llamada al servicio.
9. El resource server captura el token y comprueba contra el
authorization server que sea correcto.
10. Si lo es se realiza la llamada al servicio.
Resource
Server

29. Outer Architecture - Microservicios
Seguridad
(H2M y M2M)
■ Ejemplo: CAS + SAML para la parte frontal
■ Ejemplo: Okta + SAML para la parte frontal
■ Ejemplo: Oauth2 para la M2M.
■ Ejemplo: 3Scale para el API Management.

30. Logs
Outer Architecture - Monolito
■ Los logs se escriben en ficheros directamente desde la aplicación.
■ Utilizamos distintos niveles de log dependiendo del entorno (para no penalizar los
entornos productivos).
■ Se pueden consultar los ficheros físicos en el servidor.
■ Utilizamos herramientas como PERL para facilitar el trabajo de análisis de los
ficheros de log.

31. Outer Architecture - Microservicios
Logs
distribuidos
■ Las instancias de los microservicios son desechables, cuando dejan de tener
utilidad se destruyen.
■ Los ficheros físicos pueden dejar de existir cuando se destruyen los servicios.
■ Incluso en el mejor de los casos podríamos tener muchos ficheros distintos en
distintas localizaciones.
■ El planteamiento en estos casos es la creación de un servicio de logs que los
guarda de forma unificada en una BBDD que nos permite una consulta sencilla
de los mismos.
■ También el uso de herramientas que nos permite trazar la ejecución completa
de la solución por las distintas aplicaciones.

32. Outer Architecture - Microservicios
Logs
distribuidos
■ Ejemplo: Servcio custom + ElasticSearch + Kibana
■ Ejemplo: Sleuth + Zipkin + ElasticSearch + Kibana

33. Gestión de errores
Outer Architecture - Monolito
■ Desarrollamos nuestro código para responder correctamente ante los errores.
■ Cuando se produce una excepción la tratamos si es posible de forma que la
aplicación siga funcionando.
■ Si se produce un error catastrófico toda la solución deja de funcionar.

34. Outer Architecture - Microservicios
Resistencia
a errores
■ Cuando un microservicio falla de forma catastrófica se cae pero su rol puede
ser cubierto por otra instancia del mismo.
■ Además de los errores propios de la aplicación tenemos que ser capaces de
responder ante los errores de los servicios que consumimos.
– Tenemos que ser capaces de responder ante el caso de que un servicio al
que llamamos no responda, o devuelva un error.
■ Definimos mecanismos que nos permiten responder ante este tipo de errores.

35. Outer Architecture - Microservicios
Resistencia
a errores
■ Ejemplo: Hystrix

36. Inversión del Control
Outer Architecture - Monolito
■ Mecanismo para localizar los servicios a los que llamamos.
■ Evitamos el mecanismo “clásico” de instanciar los servicios para poder utilizarlos.
■ Se optimizan los recursos utilizados ya que sólo utilizamos el número de instancias
realmente necesarias.

37. Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
Eureka

38. Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1
Eureka
1

39. Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2
Eureka
1, 2

40. Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3
Eureka
1, 2
3

41. Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4
Eureka
1, 2
3, 4

42. Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4 5
Eureka
1, 2, 5
3, 4

43. Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4 5 6
Eureka
1, 2, 5, 6
3, 4

44. Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4 5 6 7
Eureka
1, 2, 5, 6
3, 4
7

45. Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4 5 6 7
Eureka
1, 2, 5, 6
3, 4
7

46. Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4 5 6 7
Eureka
1, 2, 5, 6
3, 4
7

47. Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4 5 6 7
Eureka
1, 2, 5, 6
3, 4
7

48. Outer Architecture - Microservicios
Localización
de servicios
■ Ejemplo: Eureka + Feign

49. Outer Architecture - Microservicios
Documentación
de los interfaces
■ Una nueva necesidad del modelo de microservicios.
■ Debido a la gran cantidad de servicios necesitamos un mecanismo que nos
permita documentar todos los interfaces disponibles.
■ En el código indicamos esta información y un servicio lo publica y permite su
consumo.

50. Outer Architecture - Microservicios
Documentación
de los interfaces
■ Ejemplo: Swagger

51. Outer Architecture - Microservicios
Composición
de la solución
■ Una nueva necesidad del modelo de microservicios.
■ Ya no disponemos de “un war” que nos permite desplegar la solución.
■ Es necesario definir la forma completa de la misma para que el montaje sea
repetible.
■ Se puede realizar a varios niveles y apoyándonos en diversas tecnologías.

52. Outer Architecture - Microservicios
Composición
de la solución
■ Ejemplo: Docker compose

53. Outer Architecture - Microservicios
Gestión de
la carga
■ Los servicios se consumen desde distintos orígenes.
■ No podemos controlar cuántas solicitudes vamos a tener en un momento
determinado.
■ ¿Qué hacer cuando el servicio puede empezar a no responder?
■ Establecemos límites de carga a partir de los cuales crecemos horizontalmente.

54. Outer Architecture - Microservicios
Gestión de
la carga
■ Ejemplo: Openshift +
3Scale
■ Zuul
m4.2xlarge m4.2xlarge m4.2xlarge
m4.xlarge m4.xlarge m4.xlarge m4.xlarge
t2.micro
Bastion Host
m4.large m4.large m4.large
2 Tb 2 Tb 2 Tb

55. Objetivos de la sesión
 Tener una solución basada en microservicios en producción y poder dormir todas
las noches.
 Entender las diferencias entre una arquitectura monolítica y otra basada en
microservicios.
 Crear un mapa de todos los servicios que necesitaremos de la outer architecture
que nos permita “montar” una solución completa.
 Identificar algunas alternativas para cubrir cada una de las áreas de la outer
architecture.

56. Conclusiones
■ Los microservicios no son la respuesta a todos los problemas.
■ Las arquitecturas basadas en microservicios complican el despliegue frente a
las monolíticas.
■ Proporcionan elasticidad ante cargas inesperadas.
■ La definición de los servicios de arquitectura tiene adaptarse al modelo
seleccionado para la solución.

57. To take away
HACKERS WANTED https://github.com/juanmacintas/ejercicioMircroserviciosSpringCloud