Material de la charla impartida en SGCE 2014 sobre micro services

1. µ services
Domingo Suarez Torres
@domix

2. $ whoami

3. $ whoami
• Parte del inmobiliario de Software Gurú

4. $ whoami
• JVM Developer
• Chief Architect @ Grupo Expansión

5. Agenda
• SOA
• REST
• micro services

6. Service Oriented
Architecture

7. SOA
• SOA implica demasiadas cosas. En un mundo
ideal:
• Deseable que las aplicaciones desaparezcan
• Existen core services que proveen lógica de
negocio y datos
• UI que sirven de agregadores y aplican
presentaciones.

8. SOA
• SOA implica demasiadas cosas.
• Comunicación entre sistemas usando una
estructura estándar, generalmente un dialecto
basado en XML. "CORBA with angle brackets"
• WS-*. Infierno de XML.
• Mensajería asíncrona para transferir documentos.
Enterprise Application Integration (EAI)

9. SOA
• Riesgos y problemas principales:
• Demasiada carga, muchas veces innecesaria.
• Costosas implementaciones, tanto en consultoría
como en herramientas y runtimes. No olvidemos la
operación.
• Complejidad innecesaria.
• Vendor lock-in

10. Alternativas al típico SOA
• Soluciones in-house usando frameworks típicos
• OpenSource runtimes & tools

11. ¿Necesitamos SOA?

12. ¿Que tipo de organización
eres?

13. REST
• Todo lo que puedo decirles sobre REST
probablemente sea una mentira (refraseando a
un amigo @tomaslin)

14. RESTafarians dicen:

15. REST
• JSON sobre HTTP
• ¿Hypermedia?
• Hypermedia APIs

16. designinghypermediaapis.com

17. Developer Experience
• En el SXSW de 2014 Jeremiah Lee hablo de
‘Developer Experience’ DX
http://developerexperience.org

18. http://dx.jeremiahlee.com

19. Diseño de APIs
REST simples

20. http://dx.jeremiahlee.com

21. Micro services

22. µ services
• Estilo arquitectónico
• Cada servicio funcional o un conjunto muy pequeño se
ejecutan como procesos independientes.
• Generalmente usan protocolos ligeros y estándar como
HTTP.
• Despliegue independiente.
• Pueden o no contener todos los recursos que
necesitan. Es decir usan otros servicios para funcionar.

23. µ services
• Pueden estar escritos en diferentes lenguajes y
ejecutarse en diversos runtimes.
• Pueden usar diferentes mecanismos de
almacenaje. Relacionales o no-relacionales.
• Es común que los datos no estén centralizados.

24. µ services
• El enfoque es muy similar a SOA.
• La idea principal es no tener paquetes monolíticos de
servicios desplegables.
• Los paquetes monolíticos de servicios es la manera
natural de construir servicios.
• Con el tiempo es difícil mantener un paquete monolítico.
• Base enorme de código. Paquetes enormes para el
despliegue que toma bastante tiempo en despliegue.

25. Servicios monolíticos
• Cambios “pequeños” necesitan desplegar el
paquete completo.
• Dependiendo el entorno y la deuda técnica,
muchas veces implica hacer despliegues en
horas no productivas y tener downtimes.
• A la larga el código termina muy acoplado entre
servicios internos.

26. Componentes en µ services
• La idea es construir componentes, siempre ha sido
nuestro sueño poder rehusar y conectar componentes
existentes.
• Hemos logrado esto parcialmente usando librerías de
componentes. Que al final se convierten en
dependencias de nuestros servicios. Con todo lo que
ello implica.
• Los servicios son componentes que se ejecutan fuera
de nuestros procesos. Solo conocemos la interfaz.

27. Diseño
• En diseños monolíticos, es común que existan
diversos equipos acorde a cada capa definida. Vista,
lógica de negocio, datos, etc.
• Algunos cambios implican que todos los equipos
participen, para una organización significa costo.
• La organización para construir microservices implica
que el equipo sea cross-functional, con habilidades
para cubrir todas las capas necesarias para cada
servicio. Los servicios se organizan en torno a la
capacidad de negocio.

28. µ services es sobre el
ownership del producto

29. Toolkits

31. Dropwizard
• Muy maduro, Yammer lo usa.
• Basado en estándares como JAX-RS con Jersey
• Jackson para JSON
• Muy amistoso para DevOps, usa Metrics para
monitorear salud de los servicios.
• Incluye Jetty y no necesita un AppServer para
ejecutarse. !Mira mamá, sin AppServer¡

35. Ratpack

36. Ratpack
• Súper simple toolkit para crear webapps, como
APIs
• Construido sobre Apache Netty. !Mira mamá, sin
AppServer¡

38. Spring Boot
• Usa la base de Spring Framework
• Soporte para todas las tecnologías de Pivotal
• Se ejecuta sobre Apache Tomcat empotrado
• !Mira mamá, sin AppServer¡

39. Despliegue

40. The AppServer is DEAD

41. DevOps
• ¿Recuerdan que el tema de microservices es
sobre ownership?
• También en despliegue, no solo se trata de
entregar el código y dejar que los SysAdmins se
hagan pelotas.
• Los servicios deben incluir monitoreo para que
la operación sea más sencilla.

42. API management
• Ciertos requerimientos no funcionales no deben ser
implementados en los microservices.
• Existen diversas herramientas para aplicar ciertos servicios
necesarios como:
• Directorio/Descubrimiento
• Seguridad
• Monitoreo
• Métricas
• Escalamiento/Aprovisionamiento

43. Una opción más
• Al final la organización debe analizar que opción
es la ideal para si misma.
• SOAP/WS-* no son la única opción.
• ESB es fantástico si se usa adecuadamente con
mensajería.

44. Y como dice el @chochosmx:
!
“No hagan WebServices por convivir”

45. Preguntas
!
domingo.suarez@gmail.com
!
http://twitter.com/domix

46. Créditos de las fotos
• https://www.flickr.com/photos/kenmainr/9099640785
• https://www.flickr.com/photos/katsrcool/12311382904
• https://www.flickr.com/photos/universalpops/6830228354
• https://www.flickr.com/photos/jeezny/3477733058
• https://www.flickr.com/photos/estherase/128983854
• https://www.flickr.com/photos/thelord89/8375835939/
• https://www.flickr.com/photos/seattlemunicipalarchives/2516780900
• https://www.flickr.com/photos/dvids/9523755479