Microservices: Next Gen Architectures. José Luis Martín Pérez Managing Director Accenture

Transcripción

1

2 Microservices: Next Gen Architectures José Luis Martín Pérez Managing Director Accenture

3 Qué es una aplicación monolítica? Una aplicación en la que toda la lógica se ejecuta sobre un único servidor de aplicaciones. Esto aplica tanto a cargas front como a cargas backend on-line y batch.

4 Qué problemática han generado estas arquitecturas con el tiempo? Len4tud Complejidad Las aplicaciones se convierten en algo demasiado complicado para que un desarrollador lo entienda. Se empiezan a construir casos de uso en capas comunes de orquestación y mensajería (efecto cebolla). Los equipos se dividen en capas técnicas: UI, application, middleware, database, etc. Fragilidad ante fallos Un error enseguida hace caer la aplicación que descansa en una infraestructura de middleware muy estable para soportarlo. Resilencia aplicativa es mínima. LenBtud Complejidad Fragilidad Falta de especialización Pruebas poco eficientes Sin dueño Falta de especialización Cada parte de la aplicación tiene necesidades diferentes de CPU, memoria, almacenamiento más rápido, red, etc y si la aplicación es monolítica no puedo especializar recursos. Los problemas no 4enen dueño El código es víctima de la tragedia de las rutinas comunes donde todo el mundo culpa a código que no es suyo Pruebas poco eficientes Cada cambio requiere un ciclo completos de prueba y es difícil utilizar los conceptos de integración continua, casi imposible delivery completamente automatizado.

5 Cómo se define un microservicio? [ ] the microservice architectural style is an approach to developing a single applica4on as a suite of small services, each running in its own process and communica4ng with lightweight mechanisms, omen an HTTP resource API. These services are built around business capabili4es and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be wriaen in different programming languages and use different data storage technologies. (Mar%n Fowler)

6 Un microservicio es una funcionalidad aislada No es un concepto técnico si no FUNCIONAL

7 Cómo pueden ayudar los microservicios? Aplicaciones monolíticas Despliegues por rutinas / tablas Una base de datos para todos Comunicación entre procesos Organizado por capas técnicas Separación desarrollo y operación Sesiones en el servidor Lo hacemos todo en Java Es complicado de evolucionar\probar Uso intensivo Procesamiento Batch Servicios desacoplados por funcionalidad Despliegue por servicios independientes Elegir el mejor tipo de almacenamiento para el caso de uso Comunicación ligera entre servicios Organizado por capacidades de negocio Desarrollo con responsabilidades de operación y vice-versa Instancias sin estado, almacenamiento compartido Puedo elegir el lenguaje más adecuado Cada servicio se prueba y evoluciona por separado Reducción batch, incremento online en base a eventos

8 Qué retos plantean los microservicios? Organiza4vos Arquitectura Operación Organización en capas tecnológicas con microservicios se requiren equipos focalizados en el producto y con skills en todas las capas Los programadores necesitan mayor experbse Los desarrolladores no quieren dar soporte a producción Los Microservicios conforman un servicio altamente distribuido y escalable que es necesario gesbonar En las aplicaciones monolíbcas sólo te preocupas de un bloque de código (eso sí, a veces inabordable) Microservicios te fuerzan a moverte a computación distribuida CAP Theorem Elegir 2 Hay que gesbonar consistencia información vía eventos o réplica de datos TesBng, logging, monitorización, seguridad, versionado se ven afectados por un sistema altamente distribuido El uso de diferentes sistemas de almacenamiento requiere de procedimientos de operación específicos Es necesario que cada equipo de desarrollo mantenga sus microservicios de forma independiente

9 Cómo planteamos una arquitectura de ejecución? UN MICROSERVICIO ESTÁ COMPUESTOPOR DOS CAPAS PRINCIPALES: Aplicación è Atendiendo a la metodología DDD esta capa conbene varios componentes: EnBdades de dominio correspondientes a la funcionalidad implementada (p.e. enbdades de acceso a datos, eventos funcionales ) Lógica de negocio (p.e. reglas de comportamiento, constraints como gesbón de excepciones ). Este componente también se puede ver como una orquestación de las enbdades de dominio. Framework è Se trata de la arquitectura interna al microservicio, con un conjunto de ublidades y adaptadores, que deben cumplir dos condiciones: Alta mantenibilidad: Modelo de arquitectura evolucionaria Baja deuda técnica ADICIONALMENTE HAY DOS CAPAS MÁS EN LA PLATAFORMA: PaaS è ConsBtuye el entorno sobre el que se despliegan y ejecutan los microservicios, adicionalmente proporciona servicios comunes a los microservicios, organizados por dominios (metodología DDD) Otros Sistemas è Alojados fuera del PaaS, comprenden desde entornos de operación al sistema legacy con el que se convive, junto con los frontales actuales

10 Cómo planteamos una arquitectura DevOps?

11 Lecciones aprendidas Puntos Fuertes El sistema proporciona un modelo de escalabilidad horizontal apoyado en el PaaS, esto exige que la arquitectura genere normas para los desarrolladores, que deben aplicarse de forma automabzada Automa4zación extrema No hay manos en la validación de calidad, reglas de desarrollo, seguridad, despliegues UBlizar un modelo reducido de TDD fomenta la calidad en el somware Los entornos previos pueden desplegarse en un entorno de PaaS publico, los contenedores y la arquitectura permiten ese modelo de trabajo Al ublizar contenedores Docker, mejor desplegar sobre hardware Vsico los contenedores proporcionan la capa de virtualización y se obbene mayor rendimiento Puntos de atención Lo importante no es el tamaño del microservicio, la plataforma evoluciona separando o agregando piezas, lo importante es la funcionalidad El despliegue frecuente a entorno de desarrollo es críbco No caer en la trampa de subir solo cuando se esté listo Ojo a la transaccionalidad el paradigma proporciona transaccionalidad dentro de un microservicio Cuidado con los patrones de codificación: Sesión HTTP, dependencias entre servicios... Otros patrones son muy complejos, como CQRS El rendimiento de la plataforma se consigue cuidando el rendimiento de cada uno de los componentes Ojo a las invocaciones cruzadas entre microservicios: cuidado con el número de llamadas y con la latencia La arquitectura técnica debería ser ligera, pero cuidado, hay frameworks que necesitan mucha memoria solo para el arranque Dedicar Bempo al modelo opera4vo se puede arrancar y acelerar el desarrollo con arquebpos, pero merece la pena un enfoque API First

12 MUCHAS GRACIAS José Luis Martín Pérez Managing Director Accenture