introducción a microservicios

Erasmo Domínguez

http://www.meetup.com/es-ES/Dev_Ops_Tnf/

@erasmolpa

Introducción a Microservicios

Arquitectura de Software

• Definir algo (software), en componentes y sus interacciones.

Structura

Visión

Solución

• Se toman decisiones significativas del diseño del software.

• El resultado ha de ser un producto que solucione el problema planteado y facilite futuras obras de mejoras y mantenimiento.

Arquitectura Monolítica

MONOLITO JAVA http://www.slideshare.net/Codemotion/refactor-microservices

MONOLITO JAVA http://www.slideshare.net/Codemotion/refactor-microservices

VERSIONANDO EL MONOLITOhttp://www.slideshare.net/Codemotion/refactor-microservices

Características

• Fácil de “testear” y depurar.

• Fácil de escalar horizontalmente.

• El código está centralizado en un mismo sitio, integrado en un IDE.

• Equipo Dev y equipo Ops centralizados y claramente identificado.

You build it, you run it.Werner Vogels

MARTIN FOWLER

“A particular way of designing software applications as suites of independently deployable services.”

“Microservices is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs”

Y QUE PASA CON SOA?

• SOA Service Oriented Architecture• https://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios

CARACTERÍSTICAS I• Principio responsabilidad única.”Independencia”,”Aislamiento”.

• Entregas rápidas y facilidad de marcha atrás

• Independencia en la entrega entre diferentes equipos / servicios.

• Tecnología /framework / lenguaje adecuado para cada problema. ”Implementación y configuración óptima”.

• Domain Driven Desing “DDD”.

• “Mantenibilidad”

• Incrementa la agilidad y productividad de negocio. ”Entrega contínua”.

• Facilita la escalabilidad. Horizontal y vertical. ”Sólo crece lo que necesita crecer”

• Fundamental aplicar “DevOps”.Eje: (1 Microservicio = Container) ?

CARACTERÍSTICAS II

• Organizado alrededor de capacidades de negocio.

• Se crean componentes que son servicios. Actualizables y fácil de sustituir por otra pieza.

• Enfocado a producto y no a proyecto.

• Automatización de la infraestructura.

• Diseñado para el fallo.

A TENER EN CUENTA….• Deploy independientes

• Cultura de Automatización

• Estrategia de escalado

• Testing Necesidad de probar el “ecosistema” al completo. No es suficiente con pruebas centradas en el microservicio. Tolerancia a fallos.

• Monitorizar el ecosistema Ejm usando frameworks como ELK

• Service Discovery “Auto descubrimiento” No es fácil de gestionar / optimizar.

• Sistemas distribuidos (latencia, tolerancia a fallos…)

• “Fan out” de peticiones Aumento conciderable de tráfico.

DOMAIN DRIVEN DESING “DDD”.

http://martinfowler.com/bliki/BoundedContext.html

Bounded contextLas fronteras de estos contextos son los puntos por los cuales se pueden comunicar los subdominio de un contexto con otro, Esta comunicación se hace mediante servicios.

FRAMEWORKS• Node.js

• Senecajs

• Strongloop(Loopback )

• Java

• Spring Boot

• Spring Cloud “Netflix OSS”

• Dropwizard

@XEBECH

DEL MONOLITO HACIA MICROSERVICES

UNA DE TANTOS PLANTEAMIENTOS...

Monitoring(logs)

ConfigurationManagement

Service Discovery(Circuit Breaker)

Load Balancer

Service Registry

Edge Service

(GateAway)

Service Client

Serv

icio

de

Cach

é Se

rvic

io d

e Se

gurid

ad

Central (Proxy) Loadbalancer

Service Service

Service

Ejemplo

Ejemplo

Ejemplo

• Zuul Punto de entrada al ecosistema.• Eureka Registro y descubrimiento de servicios.

• Ribbon Balanceo de carga.

• Hystrix Circuit Breaker.Tolerancia a fallos.

https://netflix.github.io/

ALGUNAS PIEZAS DE NETFLIX

ZUUL• Punto de entrada al ecosistema de microservicios y será el encargado de enrutar, balancear,

securizar, monitorizar las peticiones.

• Wiki oficial del desarrollo de Zuul: https://github.com/Netflix/zuul/wiki

EUREKA• Se encargar de registrar las diferentes instancias de microservicios existentes, su localización,

estado, metadatos.

• Cada microservicio durante su arranque se comunicará con el servidor Eureka para notificar que está disponible. Eureka consulta “heartbeats” cada x tiempo si el servicio esta disponible y en caso contrario , tras varios reintentos lo elimina de su registro.

• Integrado con Spring Cloud Config y Asgard.

• Wiki oficial del desarrollo de Eureka: https://github.com/Netflix/eureka/wiki

EUREKA

HYSTRIX• Gestiona las interacciones entre servicios en sistemas distribuidos añadiendo lógica de

latencia y tolerancia a fallos. Es el famoso patrón circuit Breaker y nos permite programar que hacer en caso de fallo.

• Esto hay que verlo ttps://github.cohttps://github.com/Netflix/Hystrix/wiki/How-it-Works#Flowm/Netflix/Hystrix/wiki/How-it-Works#Flow

• Demo https://github.com/marcelbirkner/docker-hystrix-demo

• Wiki oficial del desarrollo de Hystrix https://github.com/Netflix/Hystrix/wiki

A single “bad” service can still bring your service down

RIBBON• Se encarga de la comunicación entre procesos en la nube que realiza balanceo de carga en el

lado cliente.

• Wiki oficial del desarrollo de Ribbon: https://github.com/Netflix/ribbon/wiki

Eureka, Zuul y Ribbon

VISUALIZACION DE DEPENDENCIASWTF!!!!

• Cuantas dependencias tiene mi servicio?

• Cuál es el volumen de llamadas a mi servicio?

• Que hago si mi servicio falla? .Es un fallo en mi invocación? Es un fallo por un servicio que invoco?.

• Cuál de mis procesos de negocio es el más lento. Caso de uso más “pesado”

• Podría responder a la pregunta, de cuantos y que tipos de errores he tenido en peticiones a mi servicio en los últimos x minutos?

http://neo4j.com/graphgist/4f1e5fe25088209dcc26/

DEPENDENCIAS ENTRE SERVICIOS

OTROS PROYECTOS DE NETFLIX• Spring Cloud Netflix http://cloud.spring.io/spring-cloud-netflix/

• Cloud -config https://github.com/spring-cloud/spring-cloud-config

• Turbine https://github.com/Netflix/Turbine/wiki

• Asgard https://github.com/Netflix/asgard/wiki

• Simian Army https://github.com/Netflix/SimianArmy

• Archaius https://github.com/Netflix/archaius

DEVOPS-CONTENEDORES

MICROSERVICIO

Conclusiones• Apps Monolíticas Ideales para organizaciones pequeñas.

• MicroServices Presenta multiples ventajas con respecto a un planteamiento más tradicional.

• Tu compañía / proyecto necesita Escalar?

• Proveedor de Cloud son el entorno ideal para este tipo de arquitecturas. Auto Scalado!

• NetflixOSS Proporciona todas las librerias y piezas de infraestructura para montar la arquitectura.

MÁS SITIOS….

• http://es.slideshare.net/AmazonWebServices/convert-your-code-into-a-microservice-using-aws-lambda

• http://martinfowler.com/bliki/BoundedContext.html

• http://martinfowler.com/bliki/CircuitBreaker.html

• http://www.oodesign.com/command-pattern.html

• http://fabric8.io/presentations/kubernetes-for-java-developers/#/

• http://microservices.io/index.html

• http://start.spring.io/

Donde va todo esto? Auto escalado?

En la próxima charla…Introducción a Kubernetes que ya toca!!!!