Presentación acerca de Microservicios y Gestion de APIs

1. Microservicios y
Gestión de APIs
Jorge Rodriguez Flores
@jorgedison

2. Arquitectura monolítica vs SOA vs microservicios
Descomposición de servicios
Comunicación entre servicios
Gestión de APIs
Caso de Uso

3. Arquitectura monolítica vs SOA vs microservicios
Descomposición de servicios
Comunicación entre servicios
Gestión de APIs
Caso de Uso

4. …el estilo arquitectónico de microservicios es un enfoque para
desarrollar una única aplicación, como un conjunto de pequeños
servicios, cada uno ejecutándose en su propio proceso y
comunicándose con mecanismos ligeros.
- Martin Fowler

6. Arquitectura
monolítica

7. Arquitectura
monolítica

8. Arquitectura
monolítica

9. 2016 - Mastering Chaos - A Netflix Guide to Microservices
Josh Evans - Director of Operations Engineering

10. Arquitectura monolítica
Aplicaciones simples
➔ Simple de desarrollar
➔ Simples de Probar
➔ Simples de desplegar
➔ Simple de escalar
Aplicaciones complejas
➔ Complejo manejo de cambios
➔ Mayores tiempos de desarrollo
➔ Calidad no garantizada
➔ Escalabilidad disminuida

11. SOA
Paradigma de arquitectura para diseñar y desarrollar sistemas
distribuidos y modulares
Creadas para satisfacer los objetivos de negocio los cuales
incluyen facilidad y flexibilidad de integración con sistemas
legados.
Alineados directamente a los procesos de negocio.

12. SOA

13. SOA
Ventajas
➔ Reduce el nivel de acoplamiento.
➔ Clara definición de roles de
desarrollo.
➔ Favorece la reutilización.
➔ Favorece el desarrollo en paralelo.
➔ Permite un mapeo directo entre los
procesos y los sistemas.
➔ Permite la interoperabilidad.
Desventajas
➔ Depende de la implementación de
estándares.
➔ Sobrecarga de servicios, tiempos de
ejecución.
➔ Gestión de servicios complejos,
intercambio de mensajes.
➔ Alto costo de inversión.

15. Microservicios
Paradigma de arquitectura para diseñar y desarrollar sistemas
distribuidos.
Creadas para satisfacer los objetivos de negocio los cuales
incluyen facilidad y flexibilidad de integración con sistemas
legados.
Alineados directamente a los procesos de negocio.

16. Arquitectura monolítica vs SOA vs microservicios
Descomposición de servicios
Comunicación entre servicios
Gestión de APIs
Caso de Uso

17. Descomposición de Servicios

18. Descomposición de Servicios
The Art of Scalability - Martin Abbott y Michael Fisher
Eje X: Duplicación

19. Descomposición de Servicios
The Art of Scalability - Martin Abbott y Michael Fisher
Eje X: Duplicación
Eje Y: Divisiones
orientadas al cliente

20. Descomposición de Servicios
The Art of Scalability - Martin Abbott y Michael Fisher
Eje X: Duplicación
Eje Z: Divisiones
orientadas al cliente
Eje Y: División por
función o servicios

21. Descomposición de Servicios
The Art of Scalability - Martin Abbott y Michael Fisher
Eje X: Duplicación
Eje Z: Divisiones
orientadas al cliente
Eje Y: División por
función o servicios
División por
servicio o
información
similar
Punto de
partida,
sistema
monolitico
Varios
sistemas, c/u
clonado,
balanceo de
carga
Mas datos
orientado al
usuario/cliente
Escalamiento
casi infinito

22. ➔ Redis (Key-value cache store): para las sesiones
de usuarios
➔ MySQL (RDBMS SQL): para los datos de
transacciones de pago
➔ MongoDB (Document store): para el catálogo de
productos
➔ Neo4J (Graph store): para el uso de las
recomendaciones
➔ Cassandra (Key-value store): para el análisis de
logs y analytics
Descomposición de Servicios

23. Microservicios
❏ Servicios pequeños e independientes.
❏ Unidades de despliegue pequeñas.
❏ Reducción de tiempo de desarrollo.
❏ Agilidad en hotfixes.
❏ Multitecnología.
❏ Fácil escalado horizontal.

24. Microservicios
❏ Localización de los servicios.
❏ Tolerancia a fallos.
❏ Gestión de la configuración.
❏ Gestión de logs.
❏ Gestión de los despliegues.
Consideraciones

25. Microservicios
❏ Modelo de referencia
❏ Modelo de implementación
❏ Modelo de despliegue.
Aspectos principales:

26. Microservicios
Modelo de referencia
Microservicio
Microservicio
Microservicio
Microservicio
Servicio de configuración
Servicio de registro
Balanceador de carga
Tolerancia a fallos
Servicio perimetral
Administración de logs

27. Microservicios
Modelo de implementación

28. Microservicios
Modelo de implementación
Servicio de configuración
Servicio de registro
Balanceador de carga
Tolerancia a fallos
Servicio perimetral
Administración de logs
Ribbon

29. Microservicios
Modelo de despliegue

30. Microservicios
Ventajas
➔ Cada servicio es relativamente
pequeño
➔ Cada servicio puede ser desplegado
independientemente de otros.
➔ Es más fácil escalar el desarrollo.
➔ Mejora el aislamiento de fallas.
➔ Elimina el compromiso de atarse con
una tecnología en particular.
Desventajas
➔ Complejidad adicional de trabajar
con un sistema distribuido.
➔ Testing
➔ Los desarrolladores deben
implementar mecanismos de
comunicación.
➔ Complejidad en la implementación.
➔ Complejidad despliegue.

31. Arquitectura monolítica vs SOA vs microservicios
Descomposición de servicios
Comunicación entre servicios
Gestión de APIs
Caso de Uso

32. Comunicación entre servicios
Mecanismos
❏ Síncrono
❏ Asíncrono
Protocolos
❏ HTTP (Hypertext Transfer Protocol)
❏ AMQP (Advanced Message Queuing
Protocol)

33. Comunicación entre servicios
Mecanismos
❏ Síncrono
❏ Asíncrono
Protocolos
❏ HTTP (Hypertext Transfer Protocol)
❏ AMQP (Advanced Message Queuing
Protocol)

34. Arquitectura monolítica vs SOA vs microservicios
Descomposición de servicios
Comunicación entre servicios
Gestión de APIs
Caso de Uso

35. Gestión de APIs
Microservicio
Microservicio
Microservicio
Microservicio
Servicio de configuración
Servicio de registro
Balanceador de carga
Tolerancia a fallos
Servicio perimetral
Administración de logs

38. Gestión de APIs

39. Arquitectura monolítica vs SOA vs microservicios
Descomposición de servicios
Comunicación entre servicios
Gestión de APIs
Caso de Uso

45. https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/
El secreto del éxito de Amazon - APIs internas
1. Todos los equipos tienen que exponer sus datos y funcionalidad vía APIs.
2. Los equipos se comunican entre sí vía API.
3. No se permite ningún otro método de comunicación: ni compartir bases
de datos, ni mandarse excels por email, nada... La única comunicación
posible es vía APIs.
4. Da igual qué tecnología se use para construir cada API.
5. Todas las APIs deben estar diseñadas para publicarse al exterior cuando
sea necesario. Sin excepciones.
6. Quien no haga esto, a la calle. Gracias.

46. https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/
El secreto del éxito de Amazon - APIs internas
Algunas de las lecciones que Amazon aprendió en el camino:
1. Soporte. Para la interfaz de su equipo se vuelve crítico
2. Seguridad. Cada equipo se convierte en un potencial atacante de DOS que
requiere niveles de servicio, cuotas y limitación
3. Monitoreo/Control de calidad: el monitoreo y el control de calidad están
interconectados.
4. Descubrimiento. Necesitará saber qué APIs hay, si están disponibles y dónde.
5. Pruebas: el sandbox y la depuración son esenciales para todas las API

47. Referencias
● https://martinfowler.com/articles/microservices.html
● https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/
● https://microservices.io/
● https://microservices.io/patterns/microservices.html
● https://store.docker.com/images/kong
● http://ptgmedia.pearsoncmg.com/images/9780134032801/samplepages/9780134032801.pdf