SGCE 2014 micro services

  • 663 views
Uploaded on

Material de la charla impartida en SGCE 2014 sobre micro services

Material de la charla impartida en SGCE 2014 sobre micro services

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
663
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
15
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 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. Ratpack
  • 32. Ratpack • Súper simple toolkit para crear webapps, como APIs • Construido sobre Apache Netty. !Mira mamá, sin AppServer¡
  • 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. Despliegue
  • 35. The AppServer is DEAD
  • 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. 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. 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. Y como dice el @chochosmx: ! “No hagan WebServices por convivir”
  • 40. Preguntas ! domingo.suarez@gmail.com ! http://twitter.com/domix
  • 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