Las arquitecturas de microservicios han sido adoptados muy rápidamente, debido a su capacidad para proveer modularidad, escalabilidad y alta disponibilidad En este seminario web grabado, nuestros expertos, Rubén Terceño de MongoDB y Miguel Garrido de Paradigma Digital le explican cómo se puede usar microservicios para: Alinear las estructuras de tu organización Realizar aplicaciones más rápidamente Hacer un uso eficiente de tus recursos

1. Seminario Web
MongoDB & Paradigma
Desarrolle aplicaciones más escalables utilizando
microservicios

2. Ruben Terceño
Senior Solutions Architect
MongoDB
Miguel Garrido
Senior Solutions Architect
Paradigma Digital

3. Agenda
Introducción a los microservicios:
¿Por qué han surgido? ¿Qué beneficios aportan frente a
arquitecturas tradicionales?
Nuevas tecnologías que ayudan en arquitecturas de
microservicios
¿Qué beneficios aporta el uso de MongoDB en este
tipo de arquitecturas?

4. INTRODUCCIÓN A LOS
MICROSERVICIOS

5. 5
Definición de microservicio
“Microservices is a software
architecture style, in which complex
applications are composed of small,
independent processes communicating
with each other using language-
agnostic APIs. These services are
small, highly decoupled and focus on
doing a small task.”

6. 6
Un poco de historia
Equipo de
desarrollo
Arquitecturas monolíticas (pre-
SOA)
Arquitecturas SOA Microservicios
En arquitecturas monolíticas cualquier
cambio afecta al producto completo y
todos los equipos deben estar de
acuerdo en implementarlo.
Los elementos en SOA se desarrollan de
manera más autónoma pero los equipos
deben coordinarse con otros para que
los cambios encajen en el diseño
general.
El nuevo paradigma de desarrollo

7. 7
• Alto nivel de acoplamiento
• Complejidad de código
• Un pequeño cambio de código en la aplicación implica un despliegue
completo
• Escalado ineficiente
• Menos especialización
Arquitecturas monolíticas

8. 8
• Menor acoplamiento entre servicios
• Bus de servicios que mapea el servicio lógico y llama al servicio físico
• Se premia la reusabilidad, lo que puede llevar a que contengan
demasiado código
• Los servicios tienen estado
• Suelen utilizar modelos de datos relacionales
• En algunos casos, es complicado separar la funcionalidad entre
servicios
Arquitecturas SOA

9. 9
Arquitecturas de microservicios
• Principio de responsabilidad única
• Desarrollo eficiente
• Escalado elástico
• Ciclo de vida independiente
• Menor Time-to-Market (Continuous Delivery)
• Facilidad de integración con otros sistemas

10. 10
Retos de una arquitectura de microservicios
• ¿Dónde se encuentran desplegados los servicios?
• ¿Qué pasa si alguno falla?
• ¿Cómo se configuran?
• ¿Dónde se guardan las trazas?
• ¿Cómo los monitorizamos?
• ¿Cómo los desplegamos?
• Gestionar el aumento del tráfico interno
PaaS
Microservici
o 1
Microservici
o 2
Microservici
o 3
Microservici
o 4
Servicio de enrutamiento
Almacenamiento
Servicio de
orquestación
Servicio de
descubrimiento
Registro de
contenedores
Consumidores
Servicios de logging /
monitorización
Servicio de
configuración
Herramient
a de CI
Control de
versiones

11. 11
Herramientas
Microservicio
1
Microservicio
2
Microservicio
3
Microservicio
4
Servicio de enrutamiento
Docker registry
Servicio de orquestación
Servicio de
descubrimiento
Devops
Consumidores
Servicios de logging /
monitorización
Servicio de configuración

12. 12
Herramientas
Microservicio
1
Microservicio
2
Microservicio
3
Microservicio
4
Servicio de enrutamiento
Docker registry
Servicio de orquestación
Servicio de
descubrimiento
Devops
Consumidores
Servicios de logging /
monitorización
Servicio de configuración
Encargado del
pipeline de
Continuous Delivery
Gestión del código
fuente de los
microservicios
Gestión de imágenes
docker de los
diferentes
microservicios
Motor de base de
datos

13. 13
Ejemplo de una arquitectura de microservicios
PaaS
Consumidor 1
CPD 1
Node 1
Gestión de
pedidos
Gestión de
clientes
Gestión de
artículos
Gestión de
usuarios
Node 2
Eureka
Gestión de
clientes
CPD 2
Node 3
Gestión de
pedidos
Node 4
Gestión de
clientes
Gestión de
artículos
Gestión de
usuarios
Zuul
Zuul
Spring Cloud
Config
Eureka
Spring Cloud
Config
MongoDBMongoDB
CPD 3
(virtual)
MongoDB
Arbiter
Master 1 Master 2
MongoDBMongoDB
Master 3
Consumidor 2 Consumidor 3 Consumidor 4 Consumidor 5 Consumidor 6

14. 14
• Como hemos visto, la manera de comunicarse entre microservicios son los protocolos de red, especialmente el
protocolo http, definiendo APIs REST como interfaz de comunicación. Estas APIs proporcionan:
– Organizan sistemas internos para dar apoyo a nuevos proyectos innovadores de una manera uniforme.
– Reducen costes de mantenimiento.
– Incrementan la agilidad en los procesos de transformación.
– Acercan la omnicanalidad a la empresa
Microservicios y APIs
Servicio
API

15. 15
JSON como formato de intercambio
• JSON son las siglas de JavaScript Object Notation, y fue originalmente pensado para llevar la notación nativa
usada para declarar objetos en JavaScript a otros lenguajes. Proporciona:
– Flexibilidad
– Ligereza
– Evita transformaciones con bases de datos en formato JSON
– Modelo de datos autoexplicativo

16. 16
Proyecciones y expansiones
• Funcionamiento similar a MongoDB
• Minimizan el tráfico y optimizan el servicio en
casos de acceso a múltiples datastores
• Ejemplo de llamada con proyección:
rest/api/content?type=page&spaceKey=TEST&proje
ctions=version, history
• Proporcionan mayor rendimiento y menor
consumo, limitando el número de llamadas a un
API
• Permiten la expansión de campos e items
embebidos de un recurso
• Ejemplo de llamada con expansión:
rest/api/content?type=page&spaceKey=TEST&expa
nd=version,history.lastUpdated
Proyecciones Expansiones

17. 17
Transaccionalidad en microservicios
La división de los datos en diferentes repositorios (base de datos, colas de mensajes, etc) y su accesibilidad a través
de servicios que los envuelven supone perder la transaccionalidad nativa a nivel de base de datos:
Existen diversos patrones que permiten tratar esta situación:
• Reintentar: en situaciones de caída puntual o no
disponibilidad parcial del servicio (caída de un nodo por
ejemplo), reintentar la operación puede ser una solución
válida.
• Abortar la operación completa: en esta situación,
debe existir una operación de ‘compensación’ para
volver a un estado de consistencia.
• Transacción distribuida: basa su funcionamiento en la
la existencia de un proceso de gobierno de la
transacción (‘transaction manager’).
Ok
Servicio 1
Servicio 2
Servicio 3
Servicio 3
Ok
Reintento
Servicio 1
Servicio 2
Servicio 3
Deshacer
Coordinador
Servicio 2
Servicio 3
Preparar
Servicio 1 Commit

18. TECNOLOGÍAS MICROSERVICIOS

19. 19
Cloud, IaaS y PaaS
• Ayudan con la gestión eficiente de recursos
• Posibilitan escalado ilimitado
• Delegación de responsabilidad en piezas propias (balanceo de
carga, enrutamiento, descubrimiento, seguridad...etc)
• Monitorización de servicios
• Logs centralizados
• Trazabilidad de servicios
• Despliegue automatizado con estrategias de balanceo
automáticas

20. 20
Docker containers
• Proveen entornos aislados gestionados por
procesos (hypervisor) con el mínimo kernel de
sistema operativo en cada contenedor
• Con el mismo hardware se pueden ejecutar más
contenedores que con máquinas virtuales
• Docker ha conseguido un gran seguimiento de la
comunidad con un repositorio público de
imágenes, Docker Hub, que contiene sobre
400.000 imágenes

21. 21
Broker de mensajería
• Broker de mensajería publisher / subscriber con persistencia en disco
• Conecta microservicios
• Desacopla llamadas entre microservicios
• Proporciona alta disponibilidad
Microservicio 1 Microservicio 2
Almacenamiento
Microservicio 1 Microservicio 2
Almacenamiento
- Dependencia entre servicios
- Gestión de errores y
reintentos en el servicio
llamante
- Añadir un nuevo servicio
implica sólo suscripción
- Gestión de reintentos en
Kafka
- Desacoplamiento entre
servicios

22. MICROSERVICIOS Y MONGODB

23. 23
Bases de datos NoSQL
Lenguaje de búsqueda expresivo
Índices secundarios
Consistencia Fuerte
Integración con herramientas
de gestión
Escalable y distribuido
• Escalabilidad horizontal
• Cloud
Rendimiento
• Usuarios globales
• Muy alta disponibilidad
Flexibilidad
• Esquema flexible
• Datos no estructurados
• Sin relaciones complejas

24. 24
MongoDB Nexus Architecture
Lenguaje de búsqueda expresivo
Índices secundarios
Consistencia Fuerte
Integración con herramientas
de gestión
The only NoSQL Database that combines best of RDBMS + NoSQL
Escalable y distribuido
• Escalabilidad horizontal
• Cloud
Rendimiento
• Usuarios globales
• Muy alta disponibilidad
Flexibilidad
• Esquema flexible
• Datos no estructurados
• Sin relaciones complejas

25. 25
Modelo de datos flexible
Consumidor A Consumidor B
Microservicio 1
• El esquema flexible de MongoDB permite que cada
consumidor del servicio pueda tener una percepción
propia de un modelo común, sin afectar esto a la
morfología del dato en MongoDB
• La propagación de los cambios en el modelo de
datos de los consumidores es automática
• Las vistas read-only permiten exponer el modelo de
datos de forma polimórfica y realizar ofuscación

26. 26
Redundancia
Debido a la naturaleza distribuida de los microservicios, estos tienen que ser diseñados teniendo en cuenta la
redundancia del dato. MongoDB encaja perfectamente en este requerimiento, ya que proporciona de base redundancia
a través de sus replica set.
Es muy importante destacar MongoDB permite que la política de redundancia puede ser variable por petición y por
criticidad del dato
CloudCPD 2CPD 1
Replica set
Nodo 1 Nodo 2 ArbiterNodo 3 Nodo 4

27. Los microservicios no se pueden interrumpir para hacer cambios en su esquema de datos. MongoDB
puede adaptarse a cambios en el esquema de datos sin ninguna pérdida de servicio. Su arquitectura
independiente de la plataforma proporciona facilidad de portabilidad.
Frontend
Applications
Digital & Mobile
Apps
Backend
Applications …
Operational & BI
Reporting
Application Layer
API Access Layer
Microservices
Layer
Database
Layer
Flexibilidad para modelar estructuras de datos
cambiantes sin necesidad de parar la
plataforma para realizar mantenimiento.
1
MongoDB and Microservices – Flexibility

28. La habilidad de escalar rapidamente para adaptarse a una demanda cambiante es un atributo clave
de los microservicios. La arquitectura de MongoDB permite escalado y alta disponibilidad de forma
nativa.
Frontend
Applications
Digital & Mobile
Apps
Backend
Applications …
Operational & BI
Reporting
Application Layer
API Access Layer
Microservices
Layer
Database
Layer
2
La escalabilidad y alta disponibilidad nativas se
dan la mano con el alto rendimiento necesario
en una plataforma de microservicios.
MongoDB and Microservices – Scalability

29. MongoDB proporciona funcionalidad de autenticación, control de acceso, auditoría y cifrado para
proteger los despliegues de MongoDB. Las vistas read-only permiten exponer el modelo de datos de
forma polimórfica y realizar ofuscación.
Frontend
Applications
Digital & Mobile
Apps
Backend
Applications …
Operational & BI
Reporting
Application Layer
API Access Layer
Microservices
Layer
Database
Layer
3
Seguridad nativa que protege los datos y
facilita el desarrollo de aplicaciones al asumir
el control de accesos y la visibilidad.
MongoDB and Microservices – Security

30. Nuestra receta:
Orquestación de MongoDB con Docker

31. Gestiona y provisiona los contenedores
Convierte un grupo de contenedores en un único servicio
Define una aplicación multicontenedor en un único
fichero de descripción
Ecosistema Docker

32. Orquestación
Coordina los contenedores de MongoDB para realizar un
despliegue según las mejores prácticas.
Control de Recursos
Dimensionado de cada instancia (y cada clúster) para evitar
contención de recursos
Docker

33. 5x más rápido
que Kubernetes
para lanzar un
nuevo contenedor
7x más rápido que
Kubernetes en listar
los contenedores
activos
Evaluación de plataformas a
gran escala
1000 instancias EC2 en un
clúster
¿Rendimiento?
¿Capacidad operativa?
¿Facilidad de soporte?
https://medium.com/on-docker/evaluating-container-platforms-at-scale-
5e7b44d93f2c#.k2fxds8c2
https://www.docker.com/survey-2016
Porqué Swarm?

34. swarm-node-2
swarm-node-3swarm-node-1
¿Cómo conectamos los diferentes procesos mongod?
• Swarm proporciona redes host a host
• Utiliza el hostname definido en el archivo Compose
magicmagic
magic
Redes multi host de Swarm

35. SECONDARY
cgroup/docker
cgroup/docker cgroup/docker cgroup/docker
cgroup/docker cgroup/docker
cgroup/dockercgroup/docker cgroup/docker
cgroup/dockercgroup/docker cgroup/docker
cgroup/dockercgroup/docker cgroup/docker
cgroup/dockercgroup/docker cgroup/docker
PRIMARY SECONDARY SECONDARY
PRIMARY SECONDARY
PRIMARYSECONDARY SECONDARY
PRIMARYSECONDARY SECONDARY
PRIMARYSECONDARY SECONDARY
PRIMARYSECONDARY SECONDARY
Tendremos un primario y al menos dos
secundarios por aplicación.
Definiremos reglas de afinidad en Docker
Compose para evitar que los miembros de
un mismo replicaset se desplieguen el en
mismo servidor físico.
Con Linux cgroups aislaremos los
recursos (RAM / CPU / BlockIO) a lo que
tendrá acceso cada mongod.
MongoDB Ops/Cloud Manager es clave
en este proceso ya que permite la
provisión programática !
MACHINE 1
APP
1
MACHINE 2 MACHINE 3
APP
2
APP
3
APP
4
APP
5
APP
6
SECONDARY
Despliegue en alta disponibilidad

36. SECONDARY
cgroup/docker
cgroup/docker cgroup/docker cgroup/docker
cgroup/docker cgroup/docker
cgroup/dockercgroup/docker cgroup/docker
cgroup/dockercgroup/docker cgroup/docker
cgroup/dockercgroup/docker cgroup/docker
cgroup/dockercgroup/docker cgroup/docker
PRIMARY PRIMARY SECONDARY
PRIMARY PRIMARY
PRIMARYSECONDARY SECONDARY
PRIMARYSECONDARY SECONDARY
PRIMARYSECONDARY SECONDARY
PRIMARYSECONDARY SECONDARY
MACHINE 1
APP
1
MACHINE 2 MACHINE 3
APP
2
APP
3
APP
4
APP
5
APP
6
SECONDARY
En caso de fallo a nivel de servidor alguno
de los nodos secundarios tomará el rol de
primario.
Cuando los contenedores de la máquina
en fallo se vuelvan a levantar, siempre que
respeten los nombres la arquitectura se
resincroniza.
Evento de HA (La ley de Murphy)

37. Frontend
Applications
Digital & Mobile
Apps
Backend
Applications
… Operational & BI
Reporting
Application Layer
API Access Layer
Microservice
s
Layer
Database
Application
Storage
Modelo Uno:
Contenedores para todos
Pros:
• Se despliega como un todo
• Se migra fácilmente entre
entornos
Cons:
• El storage debe ser
persistente
• La comunicación intra nodo es
más compleja
• Más difícil de debugear
Arquitectura de referencia

38. Frontend
Applications
Digital & Mobile
Apps
Backend
Applications
… Operational & BI
Reporting
Application Layer
API Access Layer
Microservice
s
Layer
Database Cluster
Modelo Dos:
Contenedores para la aplicación
Pros:
• Permite a la base de datos
manejear su propia HA y
escalado
• Permite la separación entre
las capas lógicas y de datos
(Seguridad)
• Más fácil de debuguear
Cons:
• La base de datos se
provisiona de forma
independiente.
Arquitectura de referencia

39. • Nuevos clústers en
segundos
• Despliegues con
redundancia y alta
disponibilidad
• Completamente
elástico, sin pérdida
de servicio
• Parches
automáticos y
acceso inmediato a
nuevas
funcionalidades
• Con autenticación y
cifrado
• Backup continuo
con recuperación a
la carta
• Alertas
personalizables y
monitorización fina
Completamente
seguro
Ya lo
hacemos
nosotros
• Pago or uso.
Facturación por
horas
• Soporte multi cloud
(AWS ahora mismo,
Azure & Google
Cloud antes de
verano)
• Fácil migración
mediante
herramientas a
despliegues cloud,
on premise o
híbridos.
Sin trucos
MongoDB Atlas
Base de datos como servicio de MongoDB

40. Preguntas
Gracias.
ruben@mongodb.com
@mongodb
www.mongodb.com