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
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.
31. 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¡
36. Ratpack
• Súper simple toolkit para crear webapps, como
APIs
• Construido sobre Apache Netty. !Mira mamá, sin
AppServer¡
37.
38. 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¡
41. 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.
42. 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
43. 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.
44. Y como dice el @chochosmx:
!
“No hagan WebServices por convivir”