Retos en la arquitectura de Microservicios

Centro de Alta Capacitación en Tecnologías de la Información E-mail: informes@cac-ti.com Web: http://www.cac-ti.com
Kubernetes Workshop

Ingeniero de software por 20 años, trabajando principalmente en el ecosistema JVM para
diferentes sectores como Financiero, Medios de comunicación, eCommerce, Salud y
consultoría.
He sido expositor en congresos como SOALatam (Perú), Spring IO(Madrid),Grails eXchange
(Londres), BarcelonaJUG, Mexico City JVM Group.
He sido Gerente de Desarrollo en la Bolsa Mexicana de Valores, CTO en clickOnero y Chief
Architect en Grupo Expansión. A lo largo de mi carrera he entrenado a más de 1,000
desarrolladores de software.
Actualmente me desempeño como CTO en Mentoris Group e Instructor en CAC-TI.
Domingo Suárez Torres
dsuarez@mentorisg.com
@domix

Nosotros
Empresa líder de formación en las principales y más
reconocidas tecnologías, metodologías y marcos de
referencia de TI, tales como SOA, Microservicios,
Contenedores, Kubernetes, BPM, Cloud, TOGAF,
ArchiMate, Arquitectura de Negocios, DevOps, Cobit,
Hadoop & Big Data, ISO 27001, ISO 31000, ISO 22301,
ISO 27005, entre otros.
Conócenos más en www.cac-ti.com

Introducción a Microservicios
• Componente de responsabilidad bien limitada. Define un contexto bien
delimitado. Tanto en funcionalidad como en datos.
• Define una interfaz bien definida.
– Síncrona (REST o algún otro RPC)
– Asíncrona (Mensajería)
• Autónomo
– Contiene todas las capas necesarias para trabajar.
– Persistencia. Es dueño de su modelo de datos, no lo comparte.
– Despliegue
• Arquitectura de microservicios implica sistemas distribuidos.
• Sin puntos únicos de falla.

Microservicios Monolitos

Promesas de Microservicios
• Rapidez/Agilidad
• Flexibilidad
• Efectividad
• Eficiencia
• Robustez
• Mejora continua

No son bala de plata
• Si bien hay numerosas implementaciones exitosas
• También existen muy malas experiencias
• No hay lineamientos exactos ni metodología a seguir para la implementación.
• Microservicios es un patrón de arquitectura, que define restricciones de
diseño.
• Es una arquitectura evolutiva. Seguirá moldeándose y replanteando sus
principios.

Tipos de retos
• Negocio
– Expectativas
– Gobierno
• Técnico
– Diseño/Arquitectura
– Implementación
• Operativos
– Infraestructura
– Operaciones

Negocio – Ley de Conway
• Las organizaciones que diseñan sistemas ... están obligadas a producir
diseños que sean copias de las estructuras de comunicación de estas
organizaciones.
• Melvin Conway
• https://en.wikipedia.org/wiki/Conway%27s_law

Retos negocio
• Replantear los procesos internos.
• Transformar la cultura organizacional
• Adoptar tecnología alternativa.
– Open Source ha dejado de ser un modelo “oscuro”. Es estratégico el Open
Source para la evolución de infraestructura.
• Modelar los procesos de negocio ahora en productos en lugar de proyectos.
– Los productos son más pequeños comparados con los proyectos.
– Ver la empresa como un ente multi-proceso, en donde no existen
funcionalidades centralizadas, si no distribuidas para fines de optimización y
rapidez.
• Necesario un marco de gobierno. Evitar funcionalidades duplicadas, protección de
modelo de datos para evitar acoplamientos de información.

Retos técnicos

Complejidad arquitectónica
• Si bien los Microservicios serán “pequeños”, esto facilita el mantenimiento,
evolución, etc.
• El modularizar la funcionalidad en decenas o centenas de Microservicios hará
que la arquitectura global sea mucho mas compleja.
• El alcance del microservicio debe obedecer a un contexto de funcionalidad
bien definido que permita lograr un balance con la robustez del sistema
completo.

Complejidad arquitectónica

Consistencia de datos
• Cada microservicio debe tener su propio modelo de datos (Base de datos).
• No se debe compartir este modelo de forma directa, solo a través de un API
(contrato).
• No hay base de datos compartida.
– En la vida real solo muy pocas implementaciones lo siguen.
• Se introducen las transacciones distribuidas.
• Necesitas una maquina de estados para resolver esto. Además de
implementar servicios de compensación.
• El patrón SAGA resuelve este problema.
– https://microservices.io/patterns/data/saga.html

Falacias del cómputo distribuido
1. La red es fiable.
2. La latencia es cero.
3. El ancho de banda es infinito.
4. La red es segura.
5. La topología no cambia.
6. Hay un solo administrador.
7. El costo de transporte es cero.
8. La red es homogénea.
https://es.wikipedia.org/wiki/Falacias_del_c%C3%B3mputo_distribuido

Fragilidad de la red
• Al tener interfaces entre los servicios y comunicación entre ellos, la red se
convierte en el único punto de falla.
• Se pueden tener replicas de los Microservicios para alta disponibilidad.
• Se debe diseñar para fallar desde el inicio.
• Diseñar usando los principios de las aplicaciones Cloud Native o los 12
factores puede ayudar mucho.
– https://thenewstack.io/10-key-attributes-of-cloud-native-applications/
– https://12factor.net/

Retos operativos

Aprovisionamiento
• Con multiples Microservicios es necesario aprovisionar más infraestructura.
• Mas trabajo para el equipo de operaciones.
• Con Microservicios, crece las necesidades de infraestructura. Es mas
costoso.
• Para enfrentar este reto hay que automatizar el aprovisionamiento.
• Usar Código como Infraestructura
– Ansible
– Terraform
• Los operadores deben adquirir o mejorar sus habilidades de codificación.

Monitoreo
• Ahora existen más componentes, es vital monitorear el sistema para tomar
decisiones preventivas, como escalar lo existente o aprovisionar más
infraestructura.
• Es importante conocer como están interactuando en producción los
componentes.
• El monitoreo no solo debe obtener métricas de utilización, debe ayudar a
automatizar procesos. No debería ser necesario estar revisando una bandeja
de email o una pantalla para tomar acciones.
• El dimensionamiento de capacidad puede mejorar.
• Usar herramientas como Prometheus, Graphana, OpenTracing, puede ayudar
a esto.

La practica de DevOps
• Operar infraestructuras de forma tradicional ha funcionado por muchos años, pero
requiere se que apliquen mas principios y practicas de ingeniería de software a la
operación.
• Además de transformar los procesos para cambiar de operación a producción de
sistemas de operación.
• La practica de DevOps es desafiante, debido a que se ha enfocado a implementar
pipelines de CI/CD y a aprovisionamiento. Pero es solo unas secciones de todo el
proceso completo.
• DevOps es alto a alto nivel. No hay procesos definidos de forma concreta.
• SRE (Site Reliability Engineering) Es una implementación concreta muy completa
del flujo de operaciones de un site. No compite con DevOps, usa los principios e
implementa practicas completas.
• http://google.com/sre

Muchas gracias!!!

Retos en la arquitectura de Microservicios

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Retos en la arquitectura de Microservicios

Similaire à Retos en la arquitectura de Microservicios (20)

Plus de Domingo Suarez Torres

Plus de Domingo Suarez Torres (20)

Dernier

Dernier (12)

Retos en la arquitectura de Microservicios