Intro a microservicios.

1. Erasmo Domínguez
http://www.meetup.com/es-ES/Dev_Ops_Tnf/
@erasmolpa
Introducción a Microservicios

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

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

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

7. VERSIONANDO EL MONOLITO
http://www.slideshare.net/Codemotion/refactor-microservices

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

9. You build it, you run it.
Werner Vogels

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

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

12. Y QUE PASA CON SOA?
• SOA  Service Oriented Architecture
• https://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios

13. 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) ?

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

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

16. DOMAIN DRIVEN DESING “DDD”.
http://martinfowler.com/bliki/BoundedContext.html
Bounded context
Las 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.

17. FRAMEWORKS
• Node.js
• Senecajs
• Strongloop(Loopback )
• Java
• Spring Boot
• Spring Cloud “Netflix OSS”
• Dropwizard

18. @XEBECH
DEL MONOLITO HACIA MICROSERVICES

19. UNA DE TANTOS PLANTEAMIENTOS...
Monitoring
(logs)
Configuration
Management
Service Discovery
(Circuit Breaker)
Load
Balancer
Service
Registry
Edge
Service
(GateAway)
Service
Client
Central (Proxy) Loadbalancer
Service
Service
Service

20. Ejemplo

21. Ejemplo

22. Ejemplo

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

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

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

26. EUREKA

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

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

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

31. Eureka, Zuul y Ribbon

32. VISUALIZACION DE DEPENDENCIAS
WTF!!!!

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

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

36. DEVOPS-CONTENEDORES

37. MICROSERVICIO 

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

39. 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/

40. Auto escalado?
En la próxima charla…Introducción a Kubernetes que ya toca!!!!