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

2. Índice
◦ 12 factors
◦ Concepts of Design Pattern
◦ Micro-monolith
◦ AntiPatterns
◦ Design Patterns in action
◦ Frameworks

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

8. Design Patterns in action

9. Business Domain
Business capabilities
Business capabilities design
Domain
Subdomain
Business
Capabilities
Domain 1 Domain 2 Domain 3
Subdomain 1
Subdomain 2
Capability 1
Capability 2
Capability 3
Capability 4
Capability 5
Subdomain 3
Subdomain 4
Capability 6
Capability 7
Capability 8
Capability 9
Subdomain 5
Capability 10
Capability 11
Capability 12
Capability 13
Capability 14
Subdomain 6

10. Domain-driven design
Bounded
Context 1
Bounded
Context 3
Bounded
Context 2
Business
Capability 1
Bounded
Context 5
Bounded
Context 4
Business
Capability 2
Business Domain
Business capabilities

11. Domain-driven design
User
Customer
Preferences
Customer
Loyalty
Customer
Campaigns
Marketing
Management
Loyalty
ManagementCustomer
Management
Business Domain
Business capabilities

12. Business Domain
Domain-driven Design
Eric Evans 2003 - Domain-Driven Design - Tackling Complexity in the Heart of Software

13. Business Domain
Domain-driven Design
Eric Evans 2003 - Domain-Driven Design - Tackling Complexity in the Heart of Software

14. Business Domain
Domain-driven Design
Eric Evans 2003 - Domain-Driven Design - Tackling Complexity in the Heart of Software

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

16. Architecture
Microservices architecture

17. Architecture
Event-driven architecture

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.

19. Microservices/Cloud
Event Sourcing
“All changes to an application state are stored as a sequence of events.”
Martin Fowler
Order state
Flight state
Checkin state

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.

21. Microservices/Cloud
API GATEWAY

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

23. Microservices/Cloud
API Composition

24. Microservices/Cloud
ConfigServer

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

28. Best Practices
swagger interface

29. Best Practices
swagger interface

30. https://azure.microsoft.com/en-us/resources/infographics/cloud-design-patterns/

31. Frameworks
JPA
springboot
springcloud

32. ¿Quienes se motivaron?
Jesús
Rodríguez
Founder - Organizer
Natalia Rivera
Co-Organizer
Oliver Fierro
Co-Organizer
Jonathan
González
Co-Organizer

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