µ 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