µ services
Domingo Suarez Torres
@domix
$ whoami
$ whoami
• Parte del inmobiliario de Software Gurú
$ whoami
• JVM Developer
• Chief Architect @ Grupo Expansión
Agenda
• SOA
• REST
• micro services
Service Oriented
Architecture
SOA
• SOA implica demasiadas cosas. En un mundo
ideal:
• Deseable que las aplicaciones desaparezcan
• Existen core service...
SOA
• SOA implica demasiadas cosas.
• Comunicación entre sistemas usando una
estructura estándar, generalmente un dialecto...
SOA
• Riesgos y problemas principales:
• Demasiada carga, muchas veces innecesaria.
• Costosas implementaciones, tanto en ...
Alternativas al típico SOA
• Soluciones in-house usando frameworks típicos
• OpenSource runtimes & tools
¿Necesitamos SOA?
¿Que tipo de organización
eres?
REST
• Todo lo que puedo decirles sobre REST
probablemente sea una mentira (refraseando a
un amigo @tomaslin)
RESTafarians dicen:
REST
• JSON sobre HTTP
• ¿Hypermedia?
• Hypermedia APIs
designinghypermediaapis.com
Developer Experience
• En el SXSW de 2014 Jeremiah Lee hablo de
‘Developer Experience’ DX
http://developerexperience.org
http://dx.jeremiahlee.com
Diseño de APIs
REST simples
http://dx.jeremiahlee.com
Micro services
µ services
• Estilo arquitectónico
• Cada servicio funcional o un conjunto muy pequeño se
ejecutan como procesos independi...
µ services
• Pueden estar escritos en diferentes lenguajes y
ejecutarse en diversos runtimes.
• Pueden usar diferentes mec...
µ services
• El enfoque es muy similar a SOA.
• La idea principal es no tener paquetes monolíticos de
servicios desplegabl...
Servicios monolíticos
• Cambios “pequeños” necesitan desplegar el
paquete completo.
• Dependiendo el entorno y la deuda té...
Componentes en µ services
• La idea es construir componentes, siempre ha sido
nuestro sueño poder rehusar y conectar compo...
Diseño
• En diseños monolíticos, es común que existan
diversos equipos acorde a cada capa definida. Vista,
lógica de negoci...
µ services es sobre el
ownership del producto
Toolkits
Dropwizard
• Muy maduro, Yammer lo usa.
• Basado en estándares como JAX-RS con Jersey
• Jackson para JSON
• Muy amistoso p...
Ratpack
Ratpack
• Súper simple toolkit para crear webapps, como
APIs
• Construido sobre Apache Netty. !Mira mamá, sin
AppServer¡
Spring Boot
• Usa la base de Spring Framework
• Soporte para todas las tecnologías de Pivotal
• Se ejecuta sobre Apache To...
Despliegue
The AppServer is DEAD
DevOps
• ¿Recuerdan que el tema de microservices es
sobre ownership?
• También en despliegue, no solo se trata de
entregar...
API management
• Ciertos requerimientos no funcionales no deben ser
implementados en los microservices.
• Existen diversas...
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 o...
Y como dice el @chochosmx:
!
“No hagan WebServices por convivir”
Preguntas
!
domingo.suarez@gmail.com
!
http://twitter.com/domix
Créditos de las fotos
• https://www.flickr.com/photos/kenmainr/9099640785
• https://www.flickr.com/photos/katsrcool/12311382...
SGCE 2014 micro services
SGCE 2014 micro services
SGCE 2014 micro services
SGCE 2014 micro services
SGCE 2014 micro services
Upcoming SlideShare
Loading in...5
×

SGCE 2014 micro services

919

Published on

Material de la charla impartida en SGCE 2014 sobre micro services

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
919
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
23
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

SGCE 2014 micro services

  1. 1. µ services Domingo Suarez Torres @domix
  2. 2. $ whoami
  3. 3. $ whoami • Parte del inmobiliario de Software Gurú
  4. 4. $ whoami • JVM Developer • Chief Architect @ Grupo Expansión
  5. 5. Agenda • SOA • REST • micro services
  6. 6. Service Oriented Architecture
  7. 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. 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. 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. 10. Alternativas al típico SOA • Soluciones in-house usando frameworks típicos • OpenSource runtimes & tools
  11. 11. ¿Necesitamos SOA?
  12. 12. ¿Que tipo de organización eres?
  13. 13. REST • Todo lo que puedo decirles sobre REST probablemente sea una mentira (refraseando a un amigo @tomaslin)
  14. 14. RESTafarians dicen:
  15. 15. REST • JSON sobre HTTP • ¿Hypermedia? • Hypermedia APIs
  16. 16. designinghypermediaapis.com
  17. 17. Developer Experience • En el SXSW de 2014 Jeremiah Lee hablo de ‘Developer Experience’ DX http://developerexperience.org
  18. 18. http://dx.jeremiahlee.com
  19. 19. Diseño de APIs REST simples
  20. 20. http://dx.jeremiahlee.com
  21. 21. Micro services
  22. 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. 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. 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. 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. 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. 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. 28. µ services es sobre el ownership del producto
  29. 29. Toolkits
  30. 30. 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¡
  31. 31. Ratpack
  32. 32. Ratpack • Súper simple toolkit para crear webapps, como APIs • Construido sobre Apache Netty. !Mira mamá, sin AppServer¡
  33. 33. 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¡
  34. 34. Despliegue
  35. 35. The AppServer is DEAD
  36. 36. 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.
  37. 37. 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
  38. 38. 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.
  39. 39. Y como dice el @chochosmx: ! “No hagan WebServices por convivir”
  40. 40. Preguntas ! domingo.suarez@gmail.com ! http://twitter.com/domix
  41. 41. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×