Definición micro servicios y diferencias respecto a aplicaciones monoliticas

1. MICROSERVICIOS
JOAN SEBASTIÁN RAMÍREZ PÉREZ
2017

2. AGENDA
• ¿Qué son los microservicios?
• ¿Por qué usar microservicios?
• Microservicios vs monolíticos
• Arquitectura microservicios
• Patrones usados en microservicios
• Herramientas para implementarlo
• Bibliografía

3. ¿QUÉ SON LOS
MICROSERVICIOS?
• Una forma particular de diseñar aplicaciones de
software como un conjunto de independiente de
servicios desplegables.
• Conjunción de diversos servicios independientes
que se despliegan según se vayan necesitando. Por
tanto, tendremos una aplicación modular a base de
pequeñas piezas, que podremos ir ampliando o
reduciendo a medida que sea necesario.

4. CASOS DE ÉXITO

5. ¿POR QUÉ USAR
MICROSERVICIOS?
• Los servicios en sí son muy simples de construir, pues se centran en hacer
solamente una cosa bien, de forma que son fáciles de probar y se puede
asegurar mayor calidad.
• Cada servicio podría construirse con las tecnologías y herramientas más
adecuadas, permitiendo “Polyglot Programming” (las aplicaciones se deben
escribir en una mezcla de lenguajes para explotar sus mejores
características).
• Múltiples equipos pueden trabajar independientemente. Esto fomenta
“continuous delivery” debido a que permite actualizaciones frecuentes
mientras el resto del sistema se mantiene estable.
• Si un servicio deja de funcionar, solo afectará las partes que dependen
directamente de él (si las hay). El resto operará normalmente.

6. ¿POR QUÉ USAR
MICROSERVICIOS?
• Combinar los servicios como nos interese.
• Escalar a nivel de microservicios.
• Simplificación del mantenimiento.
• Su fallo no arrastra a todo el sistema.
• Podemos hacer despliegue progresivo, no
necesariamente todo junto.

7. MICROSERVICIOS VS MONOLÍTICOS

12. ARQUITECTURA
MICROSERVICIOS
HTTPS://MARTINFOWLER.COM/VIDEOS.HTML
#MICROSERVICES

13. ARQUITECTURA
MICROSERVICIOS
HTTPS://MARTINFOWLER.COM/VIDEOS.HTML
#MICROSERVICES

14. PATRONES DE DISEÑO
HTTP://MICROSERVICES.IO/PATTERNS/INDEX.HT
ML

16. PATRONES CORE
• Arquitectura monolítica: arquitectura de una
aplicación como una única unidad desplegable
• Arquitectura micro servicio: arquitectura de una
aplicación como una colección de servicios sin
acoplamiento

17. PATRONES DESCOMPOSICIÓN
• Descomponer por capacidades del negocio: definir
servicios correspondientes a las capacidades del
negocio
• Descomponer por subdominio: definir servicios
correspondiente a subdominio DDD (Domain Driven
Design)

18. PATRONES DE DESPLIEGUE
• Múltiples instancias de servicio por servidor: desplegar múltiples instancias de un
servicio en un único servidor
• Instancia de servicio por servidor: desplegar cada instancia de servicio en su propio
servidor
• Instancia de servicio por máquina virtual :desplegar cada instancia del servicio en su
propia VM.
• Instancia de servicio por contenedor: desplegar cada instancia del servicio en su
propio contenedor
• Despliegue Serverless: desplegar un servicio usando una plataforma de despliegue
Serverless (aplicaciones que dependen de terceros)
• Plataforma de despliegue de servicios: desplegar servicios usando una plataforma de
despliegue altamente automatizada que provea servicios de abstracción

19. PATRONES PREOCUPACIONES
TRANSVERSALES
• Micro servicio chasis: un framework que permite
resolver las preocupaciones transversales y
simplifica el desarrollo de servicios
• Externalizar configuraciones: dejar de manera
externa todas las configuraciones como locación de
base de datos y credenciales

20. PATRONES DE COMUNICACIÓN
• Remote Procedure Invocation: una un protocolo
basado en RPI para comunicación entre servicios
• Messaging: usa mensajes asíncronos para la
comunicación entre servicios
• Protocolo de dominio específico: una un protocolo
de dominio especifico.

21. API EXTERNA
• API gateway: un servicio que provee a cada cliente
una interface unificada de servicios
• Backend for front-end: un API gateway for each
separado para cada tipo de cliente.

22. API GATEWAY
• Es una capa abstracta que oculta a todos los
microservicios, dejando un único Endpoint para que
los clientes se comuniquen. Las solicitudes que
lleguen al Gateway serán procesadas/enrutadas
hacia los servicios específicos. El Gateway también
nos permite monitorear fácilmente el tráfico y uso de
los servicios.

23. DESCUBRIMIENTO DE
SERVICIOS
• Descubrimiento en el lado del cliente: consultas en el cliente a un registrador
de servicios para descubrir la locación de las instancias de servicios
• Descubrimiento en el lado del servidor: consultas a un registrador de servicios
para obtener la locación de las instancias de los servicios
• Registrador de servicio: una base de datos para encontrar las instancias de
los servicios
• Registro a si mismo: instancia del servicio que se registra a si mismo con el
registrador de servicio
• Registro tercera parte: registradores de un tercero que registra la instancia del
servicio con el registrador de servicios

24. CONFIABILIDAD
• Cortacircuitos: busca prevenir fallos en cascada de
los servicios por problemas de red. Para esto invoca
un servicio remoto a través de un proxy que falla de
inmediato cuando hay una tasa de fallo o el llamado
excede la capacidad

25. GESTIONAR CONSISTENCIA DE
DATOS
• Base de datos por servicio: cada servicio tiene su propia base de datos privada
• Base de datos compartida: servicios comparten una base de datos
• Arquitectura basa en eventos: usar eventos para mantener la consistencia de la
información a través de los servicios.
• Fuente de eventos: persistir agregados como secuencias de eventos.
• Cola de los de transacciones: publicar cambios como se capturan en el registro de
transacciones de la base de datos como mensajes
• Disparadores de base de datos: usar triggers para capturar cambios en los datos.
• Eventos de aplicación: la aplicación inserta eventos en una tabla de la base de datos que
es usada como una cola de mensajes
• CQRS: mantener una o más vistas materializadas que pueden hacer consultas eficientes

26. SEGURIDAD
• Token de acceso: un token que almacena de
manera segura la información sobre el usuario y
que se intercambia entre los servicios

27. TESTING
• Service Component Test: un conjunto de pruebas
de un servicio aislado usando simulaciones para
cualquier otro servicio que invoque.
• Service Integration Contract Test: un conjunto de
pruebas para un servicio que es escrito por los
desarrolladores de otro servicio que consume.

28. OBSERVABILIDAD
• Logs de aplicación: agregar logs a la aplicación
• Métricas de aplicación: instrumentar un código de servicio para obtener
estadísticas sobre operaciones.
• Logging de auditoria: almacenar las actividades del usuario en una base de datos
• Traza distribuida: instrumentar servicios con un código que se asigna a cada
petición externa con un identificador único que se pasa entre los servicios
• Rastreo de excepciones: reporta todas las excepciones en un servicio de
monitoreo de excepciones que agrega, deja traza y notifica a los desarrolladores
• Validar salud de la API: servicio de la API que retorna la salud de un servicio y al
cual se le puede hacer ping

29. PATRONES UI
• Composición fragmento de página en el lado del
servidor: construir una página web en el lado del
servidor componiendo fragmentos HTML que son
pintados por múltiples componentes
• Composición UI del lado del cliente: construir una
interfaz de usuario en el lado del cliente compuesta
por fragmentos que son pintados por múltiples
componentes

30. HERRAMIENTAS

31. HYSTRIX PARA INGENIERÍA
RESILIENTE
• Hystrix es una librería ,
creada por Netflix,
diseñada para controlar la
interacción entre servicios
distribuidos; provee una
gran tolerancia a la
latencia y a los fallos.
• http://github.com/Netflix/H
ystrix

32. SPRING BOOT
• Permite crear fácilmente aplicaciones stand-alone,
aplicaciones que solo se necesita ejecutar.
• https://projects.spring.io/spring-boot/

33. NO TODO ES COLOR ROSA
ALGUNAS CONSIDERACIONES

34. TENER MUY PRESENTE
• Los micro servicios generan mayor complejidad en la arquitectura
• Se requiere cluster para conmutación por fallas y resiliencia
• Un simple llamado tradicional podría convertirse en un llamado de
procedimiento remoto (RPC), un REST o un mensaje asincrónico.
Los desarrolladores necesitan pensar más en problemas como la
latencia entre servicios, tolerancia a fallos, control de versiones, etc.
• Son más fáciles de probar por sí mismos, las pruebas de integración
end-to-end son más difíciles. Como el flujo de código es complejo,
puede ser difícil identificar en qué parte de la cadena se presentan
los errores.

35. “WHILE OUR EXPERIENCES SO FAR ARE POSITIVE COMPARED TO
MONOLITHIC APPLICATIONS, WE'RE CONSCIOUS OF THE FACT THAT
NOT ENOUGH TIME HAS PASSED FOR US TO MAKE A FULL
JUDGEMENT.”
JAMES LEWIS AND MARTIN FOWLER
HTTPS://MARTINFOWLER.COM/MICROSERVICES/

36. BIBLIOGRAFÍA
• Microservices [En línea]
<https://martinfowler.com/articles/microservices.html> [Consulta: 15 Enero
2017]
• ¿Por qué usar un enfoque de microservicios para crear aplicaciones? [En
línea] <https://docs.microsoft.com/es-es/azure/service-fabric/service-fabric-
overview-microservices> [Consulta: 15 Enero 2017]
• [En línea] <http://microservices.io/patterns/> [Consulta: 15 Enero 2017]
• [En línea] <https://projects.spring.io/spring-boot/> [Consulta: 15 Enero
2017]
• [En línea] <https://github.com/Netflix/Hystrix> [Consulta: 15 Enero 2017]