Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mecanismos y patrones para acelerar adopción en arquitecturas de microservicios

218 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Mecanismos y patrones para acelerar adopción en arquitecturas de microservicios

  1. 1. Mecanismos y patrones para acelerar adopción en arquitecturas de microservicios Miguel Enriquez @eldermael Unidos compartiendo y aprendiendo #SGVirtual
  2. 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. 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. 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. 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
  6. 6. Iniciadores de Proyectos
  7. 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. 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. 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. 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
  11. 11. Herramientas para Flujos de Entrega
  12. 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. 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. 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. 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. 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. 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. 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. 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. 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
  21. 21. Microlibs
  22. 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. 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
  24. 24. Refactorización Distribuida
  25. 25. Arquitectura de Microservicios Tiene un problema en común: Desvio (Drift)
  26. 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. 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. 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. 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. 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
  31. 31. Muchas Gracias!
  32. 32. Redes Sociales: Twitter: @eldermael Blogging https://medium.com/@eldermael Podcast: Pirate Dev Radio https://anchor.fm/pirate-dev-radio https://www.youtube.com/channel/UCIQ_yengMK59I2b sL3443sg Libro: https://github.com/ElderMael/patternsfordeliveringmicroservices

×