Seminario Web

MongoDB & Paradigma

Desarrolle aplicaciones más escalables utilizando

microservicios
Ruben Terceño Miguel Garrido
Senior Solutions Architect Senior Solutions Architect
MongoDB Paradigma Digital
 Introducción a los microservicios:
¿Por qué han surgido? ¿Qué beneficios aportan frente a
arquitecturas tradicionales?

Agenda Nuevas tecnologías que ayudan en arquitecturas de

microservicios

¿Qué beneficios aporta el uso de MongoDB en este

tipo de arquitecturas?
INTRODUCCIÓN A LOS
MICROSERVICIOS
 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.”

5
 Un poco de historia
Equipo de
desarrollo

Arquitecturas monolíticas (pre- Arquitecturas SOA Microservicios

SOA)
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 El nuevo paradigma de desarrollo
manera más autónoma pero los equipos
deben coordinarse con otros para que
los cambios encajen en el diseño
general.

6
 Arquitecturas monolíticas

• 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

7
 Arquitecturas SOA

• 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

8
 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

9
 Retos de una arquitectura de microservicios
Consumidores

• ¿Dónde se encuentran desplegados los servicios?

• ¿Qué pasa si alguno falla?

Servicio de enrutamiento

• ¿Cómo se configuran? Servicio de

Registro de Microservici Microservici
o1 o2 orquestación
contenedores
• ¿Dónde se guardan las trazas? Servicio de
descubrimiento
Microservici Microservici
o3 o4
• ¿Cómo los monitorizamos? Servicios de logging /
monitorización

• ¿Cómo los desplegamos? Servicio de

configuración

PaaS
• Gestionar el aumento del tráfico interno
Herramient
a de CI

Control de
versiones
Almacenamiento

10
 Herramientas
Consumidores

Servicio de enrutamiento

Microservicio Microservicio Servicio de orquestación

1 2

Servicio de
descubrimiento
Docker registry Microservicio Microservicio
Devops 3 4
Servicios de logging /
monitorización

Servicio de configuración

11
 Herramientas
Encargado del
pipeline de Gestión de imágenes Consumidores
Continuous Delivery docker de los
diferentes
microservicios

Servicio de enrutamiento

Microservicio Microservicio Servicio de orquestación

1 2

Servicio de
descubrimiento
Docker registry Microservicio Microservicio
Devops 3 4
Servicios de logging /
monitorización

Servicio de configuración
Gestión del código
fuente de los
microservicios

Motor de base de
datos

12
 Ejemplo de una arquitectura de microservicios
Consumidor 1 Consumidor 2 Consumidor 3 Consumidor 4 Consumidor 5 Consumidor 6

Gestión de Gestión de Gestión de Gestión de Gestión de

Eureka Zuul Master 3
clientes pedidos clientes pedidos clientes

Gestión de Gestión de Spring Cloud Spring Cloud Gestión de Gestión de

Zuul Eureka
usuarios artículos Config Config usuarios artículos

Node 1 Node 2 Node 3 Node 4 MongoDB

Arbiter

Master 1 Master 2 CPD 3

CPD 1 MongoDB MongoDB CPD 2 MongoDB MongoDB (virtual)
PaaS

13
 Microservicios y APIs

• 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.

API
– Incrementan la agilidad en los procesos de transformación.

– Acercan la omnicanalidad a la empresa

Servicio

14
 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

15
 Proyecciones y expansiones
Proyecciones Expansiones

• Funcionamiento similar a MongoDB • Proporcionan mayor rendimiento y menor

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

16
 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: Ok

Servicio 2

Servicio 1

• Reintentar: en situaciones de caída puntual o no Servicio 3

Reintento
disponibilidad parcial del servicio (caída de un nodo por
ejemplo), reintentar la operación puede ser una solución Ok
Servicio 3

válida.

Deshacer Servicio 2

• Abortar la operación completa: en esta situación,

debe existir una operación de ‘compensación’ para
Servicio 1

volver a un estado de consistencia. Servicio 3

• Transacción distribuida: basa su funcionamiento en la Preparar

Servicio 2

la existencia de un proceso de gobierno de la Servicio 1 Coordinador Commit

transacción (‘transaction manager’).

Servicio 3

17
TECNOLOGÍAS MICROSERVICIOS
 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

19
 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

20
 Broker de mensajería

• Broker de mensajería publisher / subscriber con persistencia en disco

•
- Dependencia entre servicios
Conecta microservicios - Gestión de errores y
reintentos en el servicio
llamante

• Desacopla llamadas entre microservicios

• Proporciona alta disponibilidad

- Añadir un nuevo servicio Microservicio 1 Microservicio 2

implica sólo suscripción
- Gestión de reintentos en Almacenamiento
Kafka
- Desacoplamiento entre
servicios

Microservicio 1 Microservicio 2

Almacenamiento

21
MICROSERVICIOS Y MONGODB
 Bases de datos NoSQL
Lenguaje de búsqueda expresivo
Flexibilidad
Índices secundarios
• Esquema flexible
• Datos no estructurados
• Sin relaciones complejas

Consistencia Fuerte Escalable y distribuido

• Escalabilidad horizontal
• Cloud

Rendimiento
Integración con herramientas • Usuarios globales
de gestión • Muy alta disponibilidad
23
 MongoDB Nexus Architecture
The only NoSQL Database that combines best of RDBMS + NoSQL

Lenguaje de búsqueda expresivo

Flexibilidad
Índices secundarios
• Esquema flexible
• Datos no estructurados
• Sin relaciones complejas

Consistencia Fuerte Escalable y distribuido

• Escalabilidad horizontal
• Cloud

Rendimiento
Integración con herramientas • Usuarios globales
24 de gestión • Muy alta disponibilidad
 Modelo de datos flexible
• El esquema flexible de MongoDB permite que cada
Consumidor A Consumidor B 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

Microservicio 1

• Las vistas read-only permiten exponer el modelo de

datos de forma polimórfica y realizar ofuscación

25
 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

Replica set

Nodo 1 Nodo 2 Nodo 3 Nodo 4 Arbiter

CPD 1 CPD 2 Cloud

26
 MongoDB and Microservices – Flexibility
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.
Application Layer

Frontend Backend Digital & Mobile Operational & BI

Applications Applications Apps … Reporting

API Access Layer

Microservices
Layer

Flexibilidad para modelar estructuras de datos

Database 1
cambiantes sin necesidad de parar la
Layer
plataforma para realizar mantenimiento.
 MongoDB and Microservices – Scalability
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. Application Layer

Frontend Backend Digital & Mobile Operational & BI

Applications Applications Apps … Reporting

API Access Layer

Microservices
Layer
La escalabilidad y alta disponibilidad nativas se
2
dan la mano con el alto rendimiento necesario
en una plataforma de microservicios.

Database
Layer
 MongoDB and Microservices – Security
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.
Application Layer

Frontend Backend Digital & Mobile Operational & BI

Applications Applications Apps … Reporting

API Access Layer

Microservices
Layer

Seguridad nativa que protege los datos y

Database 3
facilita el desarrollo de aplicaciones al asumir
Layer
el control de accesos y la visibilidad.
 Orquestación de MongoDB con Docker

Nuestra receta:
 Ecosistema Docker

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
 Docker

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
 Porqué Swarm?

Evaluación de plataformas a
gran escala

1000 instancias EC2 en un

clúster

¿Rendimiento?
https://www.docker.com/survey-2016

¿Capacidad operativa?
5x más rápido 7x más rápido que
¿Facilidad de soporte? que Kubernetes Kubernetes en listar
para lanzar un los contenedores
nuevo contenedor activos
https://medium.com/on-docker/evaluating-container-platforms-at-scale-
5e7b44d93f2c#.k2fxds8c2
 Redes multi host de Swarm

¿Cómo conectamos los diferentes procesos mongod?

• Swarm proporciona redes host a host
• Utiliza el hostname definido en el archivo Compose

magic
swarm-node-1 swarm-node-3

magic magic
swarm-node-2
 Despliegue en alta disponibilidad
APP

PRIMARY SECONDARY SECONDARY

1

cgroup/docker cgroup/docker cgroup/docker Tendremos un primario y al menos dos

secundarios por aplicación.
APP

PRIMARY SECONDARY SECONDARY

2

cgroup/docker cgroup/docker cgroup/docker Definiremos reglas de afinidad en Docker

Compose para evitar que los miembros de
un mismo replicaset se desplieguen el en
APP

SECONDARY PRIMARY SECONDARY

3

cgroup/docker cgroup/docker cgroup/docker mismo servidor físico.

APP

SECONDARY PRIMARY SECONDARY Con Linux cgroups aislaremos los

4

cgroup/docker cgroup/docker cgroup/docker

recursos (RAM / CPU / BlockIO) a lo que
tendrá acceso cada mongod.
APP

SECONDARY SECONDARY PRIMARY

5

cgroup/docker cgroup/docker cgroup/docker

MongoDB Ops/Cloud Manager es clave
en este proceso ya que permite la
APP

SECONDARY SECONDARY PRIMARY

provisión programática !
6

cgroup/docker cgroup/docker cgroup/docker

MACHINE 1 MACHINE 2 MACHINE 3

 Evento de HA (La ley de Murphy)
APP

PRIMARY PRIMARY SECONDARY

1

cgroup/docker cgroup/docker cgroup/docker

APP

PRIMARY PRIMARY SECONDARY

2

cgroup/docker cgroup/docker cgroup/docker

En caso de fallo a nivel de servidor alguno
de los nodos secundarios tomará el rol de
APP

SECONDARY PRIMARY SECONDARY

3

cgroup/docker cgroup/docker cgroup/docker

primario.

Cuando los contenedores de la máquina

APP

SECONDARY PRIMARY SECONDARY

4

cgroup/docker cgroup/docker cgroup/docker en fallo se vuelvan a levantar, siempre que

respeten los nombres la arquitectura se
resincroniza.
APP

SECONDARY SECONDARY PRIMARY

5

cgroup/docker cgroup/docker cgroup/docker

APP

SECONDARY SECONDARY PRIMARY

6

cgroup/docker cgroup/docker cgroup/docker

MACHINE 1 MACHINE 2 MACHINE 3

 Arquitectura de referencia
Application Layer

Modelo Uno: Frontend Backend Digital & Mobile … Operational & BI

Contenedores para todos Applications Applications Apps Reporting

Pros:
• Se despliega como un todo
API Access Layer
• Se migra fácilmente entre
entornos
Microservice
Cons: s
• El storage debe ser Layer

persistente Database
• La comunicación intra nodo es Application

más compleja
• Más difícil de debugear

Storage
 Arquitectura de referencia
Application Layer

Modelo Dos: Frontend Backend Digital & Mobile … Operational & BI

Contenedores para la aplicación Applications Applications Apps Reporting

Pros:
• Permite a la base de datos
API Access Layer
manejear su propia HA y
escalado
• Permite la separación entre
Microservice
las capas lógicas y de datos s
Layer
(Seguridad)
• Más fácil de debuguear

Cons:
• La base de datos se
Database Cluster
provisiona de forma
independiente.
 MongoDB Atlas
Base de datos como servicio de MongoDB

Ya lo
Completamente
hacemos Sin trucos
seguro
nosotros

• Nuevos clústers en • Con autenticación y • Pago or uso.

segundos cifrado Facturación por
horas
• Despliegues con • Backup continuo
redundancia y alta con recuperación a • Soporte multi cloud
disponibilidad la carta (AWS ahora mismo,
Azure & Google
• Completamente • Alertas Cloud antes de
elástico, sin pérdida personalizables y verano)
de servicio monitorización fina
• Fácil migración
• Parches mediante
automáticos y herramientas a
acceso inmediato a despliegues cloud,
nuevas on premise o
funcionalidades híbridos.
Preguntas

Gracias.

ruben@mongodb.com

@mongodb

www.mongodb.com