SGCE 2014 micro services
Upcoming SlideShare
Loading in...5
×
 

SGCE 2014 micro services

on

  • 579 views

Material de la charla impartida en SGCE 2014 sobre micro services

Material de la charla impartida en SGCE 2014 sobre micro services

Statistics

Views

Total Views
579
Views on SlideShare
531
Embed Views
48

Actions

Likes
4
Downloads
13
Comments
0

4 Embeds 48

https://twitter.com 40
http://lanyrd.com 6
http://www.linkedin.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

SGCE 2014 micro services SGCE 2014 micro services Presentation Transcript

  • µ 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 services que proveen lógica de negocio y datos • UI que sirven de agregadores y aplican presentaciones.
  • 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)
  • 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
  • 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 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.
  • µ 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.
  • µ 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.
  • 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.
  • 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.
  • 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.
  • µ 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 para DevOps, usa Metrics para monitorear salud de los servicios. • Incluye Jetty y no necesita un AppServer para ejecutarse. !Mira mamá, sin AppServer¡
  • 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 Tomcat empotrado • !Mira mamá, sin AppServer¡
  • 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 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.
  • 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
  • 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.
  • 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/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