En esta charla explico tanto los problemas que se presentan asi como el patron y/o mecanismo para resolverlos dentro del contexto de microservicios.
Presentada por Miguel Enriquez en SG Virtual Conference 2020
Mecanismos y patrones para acelerar adopción en arquitecturas de microservicios
1. Mecanismos y patrones para acelerar
adopción en arquitecturas de
microservicios
Miguel Enriquez
@eldermael
Unidos compartiendo y aprendiendo
#SGVirtual
2. Plataformas Tecnológicas
Una plataforma tecnológica es el conjunto de
tecnologías que funcionan como el contexto en el
que las aplicaciones de una compañía corren.
El entorno de ejecución de tus microservicios:
● Proveedor de nube
● Soluciones PaaS
● Entornos de ejecución
Y funcionalidades transversales (cross-cutting
concerns):
● Autenticacion y Autorizacion
● Seguimiento y Registro
● Auditoria
3. Patrones de Microservicios
Manejo de Datos
● Base de datos por servicio
● Sagas
● Composicion de APIs
● CQRS
● ...
Despliegue
● Servicio por VM/Contenedor
● Serverless
● Plataforma de despliegue
● ...
Source: https://microservices.io/
Funcionalidad transversal:
● Chasis de microservicios
● Configuracion externalizada
4. Entregando Microservicios: Aceleradores
Patrones y mecanismos que ayudan a
reducir la fricción y acelerar adopción
de la plataforma tecnológica
● Crear microservicios
● Desplegar en la plataforma
● Mantener servicios actualizados
● Acceder a las características de
la plataforma
5. Aceleradores: Mecanismos y Patrones
Iniciadores de proyectos
● Plantillas de proyectos
● Generadores de proyectos
Herramientas de Flujos de Entrega
● Integraciones con sistemas de construcción
automatizada
● Bibliotecas compartidas para Pipelines
● Interfaces de línea de comandos para flujos de trabajo
● Imagenes compartidas para construcción de servicios
Microlibs
Herramientas para Refactorización Distribuida
7. Iniciadores de Proyectos
Para crear nuevos microservicios rápido, es necesario tener plantillas
conceptuales como arquitectura de referencia. Estas plantillas son un ejemplo de
cómo se estructuraría un microservicio que corra en la plataforma tecnológica.
● Crear microservicios con una arquitectura establecida
● Tener arquitectura de referencia hecha a medida para la plataforma
● Desarrollar características de la plataforma y la arquitectura
8. Plantillas de Microservicio
Son proyectos que sirven como un plano esquemático de un microservicio listo
para ser liberado a producción dentro de la plataforma.
Suele haber una relación entre las plantillas y los tipos de servicios:
● Servicios atómicos
● Servicios de composición de APIs
● Microfrontends
● Orquestadores de Sagas
Implementando todos ellos las funcionalidades transversales.
9. Generadores de Microservicios
El siguiente paso después de tener
plantillas es crear nuevos
microservicios automatizadamente con
unos cuantos parámetros:+
● Clonar una plantilla
● Renombrar el proyecto
● Generar nuevos manifiestos para
despliegue
● Aprovisionar infraestructura
● ...
10. Beneficios de usar Plantillas y Generadores
● El desarrollo de nuevos productos y la innovación se vuelve más fácil y
menos costoso
● La necesidad de reinventar funcionalidad transversal se vuelve menor o es
eliminada
● Acceso a una arquitectura de referencia probada dentro de la plataforma
digital
● Se puede llegar a eliminar la iteración cero en un nuevo proyecto
● Se permite experimentar con un costo reducido
12. Herramientas para Flujos de Entrega
Las líneas de ensamblaje de integración y
entrega continua (CI/CD Pipelines) son
aceptadas hoy en día como el verdadero patrón
para liberar software. Pero…
● Con docenas de microservicios, ¿Se
requieren docenas de líneas de
ensamblaje?
● ¿Son las líneas de ensamblaje software
también?
● ¿Que se utiliza para imponer políticas en
toda la plataforma?
13. Integraciones con Sistemas de Construcción Automatizada
Integrar el sistema de construcción
automatizada con la plataforma permite aplicar
políticas en todos los microservicios a la vez.
● Estandarizar la creación de artefactos y
los tipos de artefactos
● Recolección de métricas
● Imponer tareas comunes
○ Pruebas adicionales
○ Manejo de dependencias
○ Aplicar políticas de seguridad dentro de la
plataforma
14. Pipelines en Microservicios
La creación de microservicios implica que haya
tantas líneas de ensamblaje como
microservicios pero, ¿Qué pasa realmente?
● En realidad solo hay unas cuantas líneas
de ensamblaje, para cada tipo de servicio
● El codigo para construcción, despliegue y
liberacion suele estar duplicado en todos
los microservicios
● El software usado para entregar los
microservicios también debe ser probado
y las bibliotecas compartidas permiten
recuperar capacidad de pruebas
15. Bibliotecas Compartidas para Pipelines y Despliegue a Producción
Las bibliotecas compartidas de líneas de
ensamblaje permiten reusar código para liberar
microservicios
● Proveen un “camino pavimentado hacia
produccion”
● Plantillas para cada tipo de microservicio
dentro de la plataforma que se pueden
reusar
● Requieren flexibilidad para acomodar
servicios que probablemente no necesitan
todos los pasos o etapas
16. Desventajas de las Bibliotecas Compartidas para Pipelines
Mientras que la estandarización del proceso de
entrega continua en microservicios trae
beneficios, también tiene desventajas:
● Pérdida de capacidad de pruebas en
modo local
● Dependencia excesiva en el servidor de
CI/CD
● Aumento de complejidad y liberación de
nuevas versiones del flujo
● Modelos muy lineales
17. Definición de Flujos en Comandos para Consola
Para evitar el acoplamiento con el Servidor de
Integración Continua y poder ejecutar las etapas
del pipeline localmente, se pueden crear
comandos para consola que ejecuten los flujos
necesarios para desplegar microservicios.
El uso del paradigma de “Convención sobre
Configuración” ayuda a tener CLIs que trabajen
con los flujos estándar de la plataforma para
acelerar la adopción.
18. Beneficios de Utilidades de Línea de Comandos
● Probar flujos fuera del servidor de CI/CD
● El ciclo de vida de la aplicación es independiente de la plataforma
y se puede usar localmente por desarrolladores
● Se consolidan las herramientas para construcción de
microservicios
● Flujos probados para construir y desplegar microservicios se
hacen disponibles para todos los desarrolladores
19. Proliferación de Imágenes con Herramientas de Construcción
La proliferación de herramientas para construir
microservicios viene con un alto costo:
● Múltiples imágenes para una sola
herramienta
● Múltiples imágenes de una herramienta
con versiones específicas
● Actualizar varias imágenes con la misma
herramienta implica mucha duplicación y
esfuerzo
● Fijar versiones es una especie de deuda
técnica
20. Imagenes Unicas para Construccion de Microservicios
● Único punto de actualización de
herramientas
● Un agente para construcción con menos
cambio de contexto entre etapas
● Menos problemas al versionar y/o
actualizar las herramientas para construir
los microservicios y las bibliotecas con las
que se usan las herramientas
22. Plataformas Tecnológicas y Funcionalidad Transversal (Cross-cutting
concerns)
Una regla de los microservicios es “compartir
nada”. Al mismo tiempo, una plataforma
tecnológica implementa varias de las
funcionalidades transversales de una
arquitectura de microservicios.
Si no se comparte código en lo absoluto entre
microservicios, los equipos tienden a reinventar
funcionalidades transversales.
Logging
Tracing
AuthZ/AuthN
Error Detection /
Reporting
Metrics
Collection
23. Microlibs - Compartir [poco] código entre Microservicios
Una microbiblioteca implementa las
funcionalidades transversales de la plataforma y
las concentra en un solo lugar.
● Esto provee a los equipos a cargo del
desarrollo de microservicios con una
solución a un problema común
● Consolida lo que potencialmente es deuda
técnica una vez que se requiere dar
mantenimiento a la implementación de
esa funcionalidad
Logging
Tracing
AuthZ/AuthN
Error Detection /
Reporting
Metrics
Collection
26. Drift causa que las Plataformas Tecnológicas caigan
La naturaleza orgánica del software es lo que causa la deuda técnica distribuida y
hace que los ingenieros de plataformas entren en modo mantenimiento.
Algunos sintomas:
● Docenas de líneas de ensamblaje diferentes
● Múltiples versiones de una biblioteca corriendo dentro de una plataforma
● Microservicios que no pasan su línea de ensamblaje al pasar el tiempo
27. ¿Porque se generan desvíos entre microservicios? ¿Que es Drift?
Es porque compartimos código y configuraciones
Delivery Drift: pasa cuando tus microservicios no pueden ser construidos y
liberados con la misma línea de ensamblaje (pipeline) después de un tiempo
Dependency Drift: es cuando se comparten diferentes versiones de la misma
biblioteca en varios microservicios
Configuration Drift: ocurre cuando compartes configuraciones entre muchos
microservicios
28. Refactorización Distribuida, Crear Convergencia
La refactorización es un problema
distribuido porque debemos refactorizar
a través de varios microservicios para
evitar tener rezagados.
Convergencia entre versiones,
configuraciones y codigo de entrega
para mantener una plataforma estable.
“If it works, don’t fix it” esta mal 😱😱😱
29. ¿Porque la Refactorización Distribuida?
El Desvio entre microservicios es la
raiza de todos los males
● Lleva a la “osificación”, esto es, los
servicios se estancan y no pueden
ser liberados con las nuevas
características de la plataforma
● El costo de mantenimiento sube
con el tiempo, se incrementa si no
se resuelve.
30. Herramientas para Refactorización Distribuida
Atomist provee un “API para el
software” que permite crear editores de
código basados en AST y
microgramaticas
Snyk trata de actualizar bibliotecas, se
enfoca en seguridad
Netflix skunkworks funciona como
parches para codigo, pero solo en Java