Los patrones están en todos lados. Los patrones de diseño han existido desde hace mucho tiempo para las arquitecturas tradicionales (monolíticas). Los patrones nos permiten tener un abanico de opciones de diseño predeterminadas, que se pueden aplicar según cada problema de negocio y tecnológico, dándonos una ventaja en el diseño de la solución, dado que son estructuras que han sido probadas durante el tiempo en forma repetitiva, hasta consolidarse como un patrón. Sin embargo, los patrones de diseño han cambiado con la llegada de la nube y el enfoque de microservicios. En esta oportunidad vamos a discutir en profundidad estos patrones de diseño y su aplicabilidad.
https://www.meetup.com/Cloud-Native-Chile/
1. Cloud Design Patterns
in a microservices world
https://www.miti.cl
OLIVER FIERRO V. – ARQUITECTO DE SOLUCIONES
HT TPS://CL.LINKEDIN.COM/IN/OLIVERFIERRO
https://www.meetup.com/Cloud-Native-Chile
3. 12 factors 2
Dependencies
1 Codebase
4 Backing
services
5 Build,
Release, Run
7 Port binding6 Processes
12 Admin
processes
11 Logs
9 Disposability
10 Dev/prod
parity
8
Concurrency
3 Config1. One codebase tracked in revision control, many deploys
2. Explicitly declare and isolate dependencies
3. Store config in the environment
4. Treat backing services as attached resources
5. Strictly separate build and run stages
6. Execute the app as one or more stateless processes
7. Export services via port binding
8. Scale out via the process model
9. Maximize robustness with fast startup and graceful
shutdown
10. Keep development, staging, and production as similar as
possible
11. Treat logs as event streams
12. Run admin/management tasks as one-off processes
4. Concepts of Design Patterns
Best practices accepted by the industry, applied to the design of
a cloud oriented distributed solution, with the purpose to solve
an especific and recurrent problem.
5. Micro-monolith
▪ Develop services without having the boundary of the domain or
business capability.
▪ Overcharge of a service with funtionalities from several domains or
busness capabilities.
▪ Mantain a monolithic database without define the bounded context of
the information.
▪ Migrate a SOA service to a Microservice (one to one), only considering
a technology factor.
6. Anti-Patterns
A very dangerous style
Be carefully with the migration strategy!!
- The services have full access to all objects in the database
- The same team organization, with a new name: cell
7. Design Patterns in action
Business Domain
• Business capabilities design
• Domain-driven design
Architecture
• Microservices architecture
(paradigm)
• Event-driven architecture
Microservices/Cloud
Business Domain
Architecture
Microservices/Cloud
15. Architecture
Microservices architecture
1. Identify operations
2. Identify Services
3. Define service API
and collaborations
Eric Evans 2003 - Domain-Driven Design - Tackling Complexity in the Heart of Software
18. Architecture
Event-driven architecture
The services use a combination of
notifications, request/response,
and publish/subscribe.
1.- The passenger’s smartphone
sends a notification to request a
pickup.
2.- The Trip Management service
verifies that the passenger’s account
is active by using request/response
to invoke the Passenger Service.
3.- The Trip Management service then creates the trip
and uses publish/subscribe to notify other services
including the Dispatcher, which locates an available
driver.
20. Microservices/Cloud
SAGAS
1. Book a seat on flight F1
from Seattle to London.
2. Book a seat on flight F2
from London to Paris.
3. Book a seat on flight F3
from Paris to Seattle.
4. Reserve a room at hotel
H1 in London.
5.Reserve a room at hotel
H2 in Paris.
22. La granularidad de las
API’s provistas por los
microservicios es
frecuentemente distinta a
la que requieren los
clientes o consumidores.
Construyo un api Gateway
para cada tipo de cliente.
Microservices/Cloud
BACKEND FOR FRONT END
25. Best Practices
▪ Configuraciones externalizadas
ConfigServer + Repositorio.
◦ Variables de entorno (conexiones a bases de
datos, datos de correo electrónico)
◦ Profiles active (develop, test, production)
▪ Confidencialidad de Variables
Datos confidenciales o sensibles como
secretos (User, Password)
▪ Log externalizado
Escribir en la salida estándar (contenedor)
Logstash (estructura) + Kibana (visualiza)
▪ Services Isolation
Servicios contenerizados (Docker)
26. Best Practices
▪ Estándar de Interoperabilidad
Verbos HTTP + Rest API (Restful)
• Autodescubrimiento de servicios
Kubernates / Eureka + zulu
• Seguridad de API
Gateway: apikey
Servicio: JSON Web Token / OAUTH
▪ API Status
HealthCheck
▪ Dependencias de librerías externas
Maven
27. Best Practices
▪ Operaciones de api como interfaz
Swagger (estándar openapi)
▪ Gateway como punto único de acceso
Kong (apikey)
▪ Modelo de datos
Autónomo, No relacional (mongodb)
▪ Inmutabilidad de los servicios
Orientado a contenedores: Docker
▪ Caché inteligente
Memcaché, Redis u otro para acceso rápido
desde la nube pública.
▪ Orientación a Eventos
Mecanismo de integración asíncrono por
evento y/o streaming (Kafka, Pub/Sus, Colas
u otro)
▪ Autoescalabilidad
Definición de mínima y máxima capacidad
automática
33. Cloud Design Patterns
in a microservices world
https://www.miti.cl
OLIVER FIERRO V. – ARQUITECTO DE SOLUCIONES
HT TPS://CL.LINKEDIN.COM/IN/OLIVERFIERRO
https://www.meetup.com/Cloud-Native-Chile