Reestructuración y Optimización de una de una Aplicación Monolítica.
- 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
- 7. Sus alteraciones en el tiempo... 7
- 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
- 15. FRONTEND. 15
- 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