webinar arquitectura de microservicios

Centro de Alta Capacitación en Tecnologías de la Información E-mail: [email protected] Web: http://www.cac-ti.com

Webinar “Arquitectura de Microservicios”


Expositor: Domingo Suárez (México)

Ingeniero de software por 17 años, trabajando principalmente en el

ecosistema JVM para diferentes sectores como Financiero, Medios de

comunicación, eCommerce y consultoría.

He sido expositor en congresos como SOALatam (Perú), Spring IO

(Madrid),Grails eXchange (Londres), BarcelonaJUG, Mexico City JVM Group.

Actualmente soy CTO en una compañía de Inteligencia Artificial

desarrollando tecnología con Deep Learning y sistemas distribuidos.

@domix


Acerca de Nosotros

Empresa líder de capacitación en las principales y más

reconocidas tecnologías, metodologías y marcos de

referencia de TI, tales como SOA, BPM, Cloud, Arquitectura

Empresarial TOGAF, Hadoop-Big Data de Cloudera,

Certificaciones ISO: ISO 27001, ISO 31000, ISO 22301, ISO

27005, entre otros. Proveemos entrenamiento en toda la

región.


Te invitamos a participar en nuestro próximo curso on-line en vivo

Microservices Workshop

Inicio 30 de mayo. Informes: [email protected]


Agenda

• SOA • REST • Microservices • Arquitectura • Frameworks • Herramientas

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

http://dx.jeremiahlee.com

Diseño de APIs REST simples

Micro services


Microservices

• 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 o mensajería (JMS, AMQP, etc).

• Despliegue independiente. • Pueden o no contener todos los recursos que

necesitan. Es decir usan otros servicios para funcionar.


Microservices

• Pueden estar escritos en diferentes lenguajes y ejecutarse en diversos runtimes.

• Pueden usar diferentes mecanismos de almacenaje (storage). Relacionales o no-relacionales.

• Es común que los datos no estén centralizados.


Microservices

• 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 Microservices

• La idea es construir componentes, siempre ha sido nuestro sueño poder rehusar y conectar componentes existentes.

• Hemos logrado esto parcialmente usando bibliotecas 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.

Arquitectura

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@Grab('org.slf4j:slf4j-simple:1.7.16') @Grab('io.ratpack:ratpack-groovy:1.2.0') import static ratpack.groovy.Groovy.ratpack

ratpack { handlers { get(":name") { render "Hello $pathTokens.name!" } get { render "Hello World!" } } }


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


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


Cosas a observar

• Complejidad de un sistema distribuido • Hacer testing es mas complejo • Transacciones distribuidas. Difícil

implementar • Deployment • Consumo de recursos


Sistemas distribuidos (Falacias)

• La red es confiable. • La latencia es cero. • Ancho de banda es infinita. • La red es segura. • Topología no cambia. • Hay un administrador. • El costo del transporte es cero. • La red es homogénea.

HerramientasFacilitando el computo distribuido

https://github.com/Netflix/hystrix

Spring CloudIntegra un conjunto de herramientas para sistemas

distribuidos, a pesar del nombre no solo sirve para el cloud


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.


Te invitamos a participar en nuestro próximo curso on-line en vivo

Microservices Workshop

Inicio 30 de mayo. Informes: [email protected]


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

https://www.flickr.com/photos/dvids/9523755479

webinar arquitectura de microservicios

Technology