Esta presentación intenta abarcar los pasos para enfrentar una migración Monolítica a arquitecturas actuales como Microservicios.

1. Refactorización
Progresiva de una
Aplicación Monolítica.
Por Matías Cappato.
1

2. Esta presentación no sugiere
lenguajes particulares ni se
sumerge en detalles técnicos.
2

3. A veces es necesario escalar una aplicación
monolítica, lanzar actualizaciones más rápido
o administrar grandes equipos de diversas
habilidades. Un enfoque es rediseñar su
aplicación en un conjunto de microservicios
que se implementan en la nube.
3

4. Esta refactorización puede ser un proceso
largo para un producto complejo. También
puede ser desalentador para gente nueva en
la arquitectura de microservicios.
4

5. Repaso del patrón MVC. Expectativa...
5

6. ...Realidad...
6

7. Sus alteraciones en el tiempo...
7

8. Repaso de una
Arquitectura
Monolítica.
8

9. 9

10. 10

11. Front & Back
Una Arquitectura
Moderna.
11

12. API Service
Arquitectura Front & Back
12

13. Otra vista de la Arquitectura
Front & Back.
13

14. ApplicationAPI GATEWAY
14

15. FRONTEND.
15

16. ARQUITECTURA
SPA.
16

17. BACKEND.
Una Arquitectura basada en Servicios
API.
17

18. ¿Qué son Las API Web?.
18

19. Una API es un contrato que proporciona una
guía para que un consumidor use el servicio
subyacente.
19

20. Son Interfaces que
permiten
interacciones entre
la empresa
proveedora
y las apps que
utilizan sus
activos.
20

21. Otras representaciones de la arquitectura de
Servicio API
21

22. Backend Monolítico
vs
Backend de servicios API.
22

23. Monolítico Basado en APIs
23

24. ¿Son las APIs sólo otro nombre
para los Servicios?.
24

25. Los Servicios tienen foco en las
necesidades del proveedor.
Las APIs tienen foco en las necesidades
de los consumidores.
25

26. Proveedores de Servicios y
Consumidores de APIs.
Tres verdades.
26

27. Para un proveedor de servicios, la
reutilización se trata de un esfuerzo de
entrega.
Para un consumidor de API, reutilizar se
trata de velocidad de entrega, sin
importar el costo para el proveedor.
1
27

28. Para un proveedor de servicios,
compartir es cuestión de eficacia.
Para un consumidor de API, si no es
conveniente no se utilizará la API.
2
28

29. Para un proveedor de servicios, la
encapsulación es menos para cambiar.
Para un consumidor de API, si la interfaz
es compleja no se utilizará la API.
3
29

30. En Resumen, todo apunta a Microservicios...
30

31. La modularidad es esencial
cuando se desarrollan
aplicaciones grandes y
complejas.
31

32. La arquitectura de microservicio
utiliza servicios como la unidad
de modularidad.
32

33. El objetivo principal de los
microservicios es tener
pequeños servicios
independientes que estén
desacoplados lo más posible.
33

34. Pero la Arquitectura de
microservicios extiende la
implementación de estas unidades
más pequeñas y las técnicas de
aislamiento a la infraestructura del
servidor.
34

35. Incluso dicta la estructura del
equipo y los roles de TI: los equipos
de desarrollo estarán separados por
los servicios que construyen.
35

36. Microservicio es tanto una
arquitectura de infraestructura
como una aplicación de software.
36

37. La ventaja es que la infraestructura
en la que se ejecuta cada servicio
es independiente entre sí, por lo
que mantiene su autonomía tanto
en la capa del servidor como en el
código.
37

38. La desventaja es bastante seria, la
sobrecarga adicional sobre el
equipo de TI es enorme. Requiere
un monitoreo más sólido.
38

39. Es extremadamente difícil encontrar buenos
arquitectos para crear la arquitectura
Microservice de manera correcta.
39

40. 40

41. Múltiples solicitudes del cliente al backend para
crear la interfaz de usuario, puede resultar
ineficaz a través de Internet y poco práctico a
través de una red móvil.
41

42. Los Microservicios son
expuestos a través de APIS.
Relación API Microservicio
42

43. Las APIS utilizan el Protocolo
HTTP (Rest) para exponer
servicios y comunicarse.
Relación API Microservicio
43

44. Gateway API
44

45. Una forma de abordar este problema es ocultar
estos servicios detrás de una nueva capa de
servicio y proporcionar una API que se adapte a
cada cliente.
Esta capa de servicio agregador también se
conoce como una puerta de enlace API.
45

46. Comunicación HTTP Rest cliente-servicio a
través de puertas de enlace o Gateway API.
46

47. 47

48. 48

49. 49

50. 50
Principales Funciones de un servicio de API Gateway
Enrutamiento
Seguridad
Limitación de velocidad
Vigilancia
Configuración de Alertas.

51. ¿Cuando son ideales los
Microservicios?.
51

52. Tienen varios equipos de desarrollo centrados en
diferentes áreas de negocio de la aplicación.
La aplicación debe ser capaz de implementarse en
varios entornos de infraestructura (varias nubes
públicas y locales)
Debe ser multiplataforma, capaz de cambiar con
facilidad de Linux a Windows (o viceversa).
52

53. Por último, también hay que tener en cuenta
problemas de seguridad.
Se deben proteger tanto las acciones del
usuario como las interacciones entre los
servicios.
53

54. 54
Seguridad

55. JWT es un estándar abierto basado en JSON
propuesto por IETF para la creación de tokens
de acceso que permiten la propagación de
identidad y privilegios o claims en inglés.
Tokens de seguridad.
55

56. Así se ve un Token de seguridad.
Tokens de seguridad.
56

57. Uso de tokens
¿Cómo se implementan?
57

58. 58

59. 59

60. Ver más recomendaciones de seguridad para API por
RedHat en
https://www.redhat.com/es/topics/security/api-security
Tokens de seguridad.
60

61. FIN.
61

62. Conclusión.
MVC, SOA, MICROSERVICIOS comparten una misma idea,
dividir las aplicaciones en componentes más pequeños, más
discretos y más fáciles de administrar.
62

63. Conclusión.
Las Arquitecturas o patrones de diseño pueden sufrir
modificaciones a fin de adaptarse según su caso de uso,
concurrencia, Número de servicios, Equipos de desarrollo
involucrados, etc.
63

64. Conclusión.
Es una buena estrategia escoger dentro de nuestra
aplicación monolítica una funcionalidad finita, bien
definida, que no sea crítica y extraerle en su propio
microservicio.
64

65. Conclusión.
Una vez alcanzada esta arquitectura será mucho más fácil
“reescribir” una aplicación en lenguajes más modernos y
posteriormente tomar decisiones a nivel servidor o incluso
el uso de tecnologías FaaS sin servidor.
65