Microservicios Webinar CAC-TI

Centro de Alta Capacitación en Tecnologías de la Información E-mail: informes@cac-ti.com 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: informes@cac-ti.com

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

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-*. Inﬁerno 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

¿Que tipo de organización
eres?

REST
• Todo lo que puedo decirles sobre REST
probablemente sea una mentira (refraseando a
un amigo @tomaslin)

REST
• JSON sobre HTTP
• ¿Hypermedia?
• Hypermedia APIs

Developer Experience
• En el SXSW de 2014 Jeremiah Lee hablo de
‘Developer Experience’ DX
http://developerexperience.org

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.

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¡

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.

Herramientas
Facilitando el computo distribuido

https://github.com/Netﬂix/hystrix

Spring Cloud
Integra 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.

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

Microservicios Webinar CAC-TI

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Microservicios Webinar CAC-TI

Ähnlich wie Microservicios Webinar CAC-TI (20)

Mehr von Domingo Suarez Torres

Mehr von Domingo Suarez Torres (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (15)

Microservicios Webinar CAC-TI