Implementando una Arquitectura de Microservicios

Implementando una arquitectura de

microservicios

13/06/2015

FEDERICO LOZADA MOSTOTwitter: @mostofreddyWeb: mostofreddy.com.arFacebook: /mostofreddyLinkedin: ar.linkedin.com/in/federicolozadamostoGithub: /mostofreddy

Arquitectura monolítica

BundleA

Data Access

BundleB BundleC

Browser

Monolithic App

Database

Arquitectura monolítica

UX

BundleA

BundleB

BundleC

Monolithic App

Database

Arquitectura monolítica

Data Access

UX

$ cd /var/www$ tree MyProject -L 2MyProject├── app/├── src/│ ├── Bundle1/│ ├── Bundle2/│ ├── Bundle3/│ ├── ...│ ├── BundleN/├── web/├── vendor/└── ...

Arquitectura monolítica

Monolithic

Arquitectura monolítica - Ups!

mobile

systems

IOT

tablet

Arquitectura

Compleja+ acoplamiento

Difícil documentaciónDifícil sincronización

¿Cómo afecta un cambio?

Cambios

lentosdifíciles

Cambios

lentosdifíciles

Hotfix!!!

Deploy

App Completa

HotfixTesting

ReleaseCoordinación

RiesgoInterrupción completa

Rollback complejo

U$S+ Recursos

+ Infraestructura

+ Tiempo para migrar app

Microservicios

Microservicios

E-commerce

Payment Gateway Stock

Public API

Reports

Auth

CRM integration

Logistic...

Public API

Microservicios

Payment Gateway

E-commerce

Stock

CRM integration

NotificationLogistic

Reports

Auth

Servicio 1

Servicio 2

Servicio 3

Servicio 4

Servicio 5

Servicio 6

Servicio 7Servicio 8

Public API

Microservicios

Payment Gateway

Stock

CRM integration

NotificationLogistic

Auth

Is an approach to developing a single application

as a suite of small services, each running in its

own process and communicating with lightweight

mechanisms, often an HTTP resource API.

- Martin fowlerhttp://martinfowler.com/articles/microservices.html

¿Quienes usan Microservios?

Características

Arquitectura

Sencilla- acoplamiento + cohesión

Comunicación mediante APIs HTTPPequeños

No afecta a otros servicios

Desarrollo

SencilloServicios pequeños

Independientes

Mayor controlImplemente una necesidad de negocio

Cambios

RápidosIndependientes

mejor “time to market”

Deploy

Por servicio

HotfixTesting

Release- Coordinación

Equipos

Especializados

Geodistribuidos

Independiente a la tecnología

Eficiente

EscalabilidadAuto Scalling

Serv 2

LB

Serv 3 Serv 3

Serv 3

Serv 1

Mobile+

API

First

Servicio

Independiente

Especializados

Pequeño

Key words

Buenas prácticasy

desafíos

Principios SOLID

✓ Single responsability

✓ Liskov Substitution

✓ Interface Segregation

✓ Dependency inversion

✓ HATEOAS✓ HAL✓ JSON-API

Automagic service discovery

DB distribuidas

✓ Cada servicio con su DB✓ NO acoplar servicios por DB

✓ Sincronización de datos✓ Consistencia de datos

DB distribuidas

APIs documentadas

✓ RAML✓ Swagger

✓ Restfull✓ AMQP (ZeroMQ, RabbitMQ, etc)

✓ NO ESB

Comunidación sencilla

✓ Api Blueprint

✓ SNS/SQS✓ Redis

Versionado✓ ¿Se versiona por servicio?✓ NO acoplar servicios por DB

✓ Un componente puede ser un servicio

Componentes

Productos✓ Productos en vez de proyectos

✓ Centralizar logs (Loggly, Logstash)✓ Centralizar monitoreo (Zabix, New Relic)

Monitoreo

✓ 1 servidor → N servidores / containers✓ 1 app → N servicos✓ Troubleshooting

Monitoreo

✓ 1 deploy → N deploy✓ AWS✓ Vagrant / Docker✓ Puppet / Chef

Automatizar deploy

Testing

✓ ¿Como probar enteramente la solución?

BundleA

Data Access

BundleB BundleC

UX

BundleA

Data Access

BundleB BundleC

UX

BundleA

Data Access

BundleB

BundleCUX

Composer

BundleA

Data Access

BundleB

UX

Lógica

API Rest

BundleC

BundleA

Data Access

BundleB

UX

Lógica

API Rest

BundleC

BundleA

Data Access

BundleB

UX

Lógica

API Rest

ServicioC

BundleA

Data Access

BundleB

UX

Lógica

API Rest

ServicioC

Servicio 1

Servicio 2

Legacy

API Gateway

Servicio N

¿Preguntas?

Thanks!

FEDERICO LOZADA MOSTOTW: @mostofreddyWeb: mostofreddy.com.arFB: mostofreddyIn: ar.linkedin.com/in/federicolozadamostoGit: mostofreddy