SGCE 2014 micro services
-
Upload
domingo-suarez-torres -
Category
Technology
-
view
790 -
download
0
description
Transcript of SGCE 2014 micro services
µ 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
!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