Víctor Cornejo Espinoza. Solution Architect.

Tamaño: px

Comenzar la demostración a partir de la página:

Download "Víctor Cornejo Espinoza. Solution Architect. vcornejo@redhat.com"

Alicia Alcaraz Sevilla
hace 8 años
Vistas:

1 MICROSERVICES ARCHITECTURE Víctor Cornejo Espinoza Solution Architect

2 AGENDA Arquitectura Monolítica Escalabilidad en 3 dimensiones Desafíos de hoy Arquitectura Microservicios JBoss & Microservices Palabras finales

3 Introducción

5 APLICACIONES MONOLÍTICAS

6 THE "OPEN RESTAURANT" Cocinero Barman Mesero Personal de aseo Cajero Administrador En un restaurant, la escalabilidad se realiza por funciones que requieran crecimiento que que sean cuellos de botella, no por la plana completa de personal En caso de ausencia de alguno de los empleados solo se reemplaza por uno similar y de ninguna forma la plana completa.

7 ARQUITECTURA MONOLÍTICA Una aplicación diseñada bajo una arquitectura monolítica está compuesta por diversos componentes incluyendo frontend, el cual implementa la interfaz de usuario junto con componentes de servicio los que pueden manejar diversas funciones como mantenimiento de clientes, stock, etc. Estos servicios pueden compartir un modelo de entidades como Producto, Cliente, Orden. Aunque tienen una logida de diseño modular, la aplicación es desplegada de forma monolítica. Por ejemplo si el desarrollo es Java puede consistir de un único WAR o EAR desplegado en un Application Server. EAR Web pages Services Data Services

8 ARQUITECTURA MONOLÍTICA Escalabilidad: Para escalar es necesario duplicar la instalación de la aplicación monolítica Mantenimiento: El mantenimiento de un componente puede impactar al resto de los componentes y generalmente se bloquean las aplicaciones para desarrollos paralelos. Estabilidad: Al sufrir alguna falla tal como memory leaks dentro de alguno de sus componentes, la estabilidad completa de la aplicación se ve involucrada. Desarrollo: La productividad se ve mermada debido al bloqueo de componentes y desarrollos demasiado extensos junto con las etapas de pruebas que practicamente pueden ser full test.creando con esto ciclos de desarrollo mas largos.

9 DESAFÍOS MEJORAR LA PRODUCTIVIDAD DE LOS EQUIPOS DE DESARROLLO LOGRAR UN ENTORNO DE EJEUCIÓN ESTABLE ANTE CAMBIOS CONSEGUIR LA FLEXIBILIDAD NECESARIA PARA LOGRAR ESCALAR CUANDO SEA REQUERIDO. PERMITIR CAMBIOS RÁPIDOS DE BAJO IMPACTO CUANDO SEA NECESARIO.

10 ESCALABILIDAD EN 3 DIMENSIONES

11 3 AXIS SCALING X: Duplicación o clonación Y: Descomposición funcional Z: Partición o federación de datos

12 X-SCALING Load Balancer Application CrearCliente Facturar EmisiónPagos Application CrearCliente Facturar EmisiónPagos Application CrearCliente Facturar EmisiónPagos Duplicación completa de la aplicación tantas veces como sea necesaria.

13 Y-SCALING + X-SCALING Application CrearCliente Load Balancer Application CrearCliente Conseguir una separación de la aplicación por funcionalidades las cuales pueden ser duplicadas de manera independiente Application EmisiónPagos Application Facturar Application Facturar Application Facturar

14 X+Y+Z SCALING Load Balancer Application CrearCliente Application EmisiónPagos Application CrearCliente Application EmisiónPagos Particionado de fuentes de datos, agrupadas entregando una independencia en el tiempo de ejecución a los microservicios o funciones de negocio definidas. Application Facturar Application Facturar Cliente Pagos Facturación

15 MICROSERVICES

16 MICROSERVICES ARCHITECTURE Definición: Es un enfoque para desarrollar una Aplicación como un conjunto coordinado de pequeños servicios, cada uno corre dentro de su propio processo y se comunican entre sí mediante un mecanismo liviano, usualmente http rest. Adrian Cockcrof t de Netflix, define una Arquitectura de Microservicios, como una Arquitectura Orientada a Servicios compuesta de elementos bajamente acoplados los cuales están delimitados por contextos.

17 MICROSERVICIO Tamaño pequeño Independiente Escalable Poliglota Infraestuctura de Automatización

18 DESCOMPOSICIÓN Arquitectura Monolítica Modular Descomposición en micro servicios

19 CARACTERÍSTICAS Cada Servicio tiene su propio contexto Cada Servicio puede ser escalado independientemente Cada servicio es cuenta con una "única responsabilidad" Cada servicio puede ser mantenido de manera independiente del resto permitiendo varios mantenimientos o cambios en paralelo

20 MACRO/MICRO/NANO Como particionar un sistema en microservicios? Verbo o caso de uso: Shipping, login, store, sell Conceptos o entidades: Stock, product, Inventory Single Responsability Principle: Idealmente cada servicio debe tener solo un pequeño set de responsabilidades, SRP define la responsabilidad de una clase como una razon para cambiarla y esta clase sólo debe tener una razon para cambiar. Ejemplo: ls -l /home/user/docs tail -n +2 sed 's/\s\s*/ /g' cut -d ' ' -f 3 sort uniq -c

21 MICROSERVICES ARCHITECTURE Escalabilidad: Los servicios pueden ser escalados individualmente sin necesidad de realizar duplicaciones completas de la aplicación. Mantenimiento: El mantenimiento de un servicio sugiere un único motivo el cual no bloquea solicitudes de cambio o proyectos que pueden ir en paralelo. Estabilidad: Al sufrir alguna falla tal como memory leaks dentro de alguno de sus servicios, la estabilidad de la aplicación no se ve necesariamente afectada ya que el servicio tiene un contexto y proceso independiente de los otros componentes. Desarrollo: La productividad se ve mejorada ya que los microservicios se corresponden a una necesidad concreta del negocio y son tan específicos que dificilmente un proyecto diferente requerirá realizar modificaciones sobre el mismo, permitiendo trabajar diversos equipos sobre los mismos sistemas.

22 MICROSERVICES ARCHITECTURE BENEFICIOS Cada servicio es desplegado independientemente, fácil para desplegar nuevas versiones Múltiples equipos pueden trabajar paralelamente en una gran aplicación. Su aislamiento proteje el resto de los componentes de la aplicación. Elimina los ciclos de desarrollo demasiado largos. Habilita a la organización a una adopción de DevOps DESAFÍOS Los desarrolladores deben enfrentar: Implementar un caso de uso sin transacciones distribuidas puede ser complejo. Implementar casos de uso que requieren multiples servicios requiere una coordinación especial Sin procesos de automatización la administración puede resultar en tareas adicionales con respecto a arquitecturas tradicionales. Incremento en consumo de Memoria

23 MICROSERVICES EXAMPLE: OPEN BANK PORTAL autenticacion saldo movimientos autenticacion2 logout simulacred simuladap actualizadire cartolahist actualiza giroatm autorizaatm Servicios comúnes dentro de un banco, los cuales tiene diferentes tipos de cargas

24 PLATAFORMAS PARA MICRO SERVICIOS

26 RED HAT JBOSS FUSE ES UNA FLEXIBLE Y LIGERA PLATAFORMA DE INTEGRACIÓN CON UN COMPLETO SET DE HERRAMIENTAS QUE DAN EL SOPORTE DE CONECTIVIDAD, MENSAJERÍA, CONTENDORES ADMINISTRACIÓN Y MONITOREO. Componentes Principales Apache Camel Apache ActiveMQ Apache CXF Apache Karaf 2.3 Fuse Fabric 1.0.0

27 FABRIC8 Plataforma de integración y administración de contenedores Administración de despliegues complejos Prvisionamiento y despliegue Creación de contenedores en diversos entornos (Local Remote Cloud ) Actualización y parchado Soporte de despliegues hibridos Onpremise, on cloud, o ambos Endpoints pueden ser reubicados Endpoints pueden ser balanceados Endpoints pueden ser elásticos Endpoints pueden tener HA Distributed Configuration La configuración puede ser accesada atravez de múltiples dominios El repositorio y registro cuenta con HA Distributed Management Fácil escalabilidad de servicios Monitoreo y control de recursos

28 DEPLOYMENT & SCALING Gateway Gateway Registry Profiles Fabric administra los contenedores y el catálogo de perfiles que pueden ser utilizados. Los contenedores son instanciados apar tir de un perfil, los cuales equivalen a un microservicio. Los contenedores que compar ten perfiles son autobalanceados para sus servicios web

29 FABRIC8 CONTAINERS Containers : Fuse,ActiveMQ Java Container: Simple Java Application Process Container: General sin dockers, Cassandra, HDFS, Tomcat, etc, Spring Boot Container: Java + Spring Kubernetes: Utilizar kubernets para administrar contenedores Docker: SO Container SSH Containers: Remotos via ssh from scratch OpenShift: Paas Container Cloud Containers: Amazon / Rackspace

30 ADMINISTRACIÓN

32 OPENSHIFT ENTERPRISE 3 Soporte para dockers Orquestación con Kubernates xpaas

35 IT EVOLUCIONANDO PARA COMPLIR LAS DEMANDAS DEL NEGOCIO

37 PALABRAS FINALES Las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones. Melvyn Conway, 1967 El enfoque de división de microservicios es diferente,los servicios se organizan en torno a la capacidades de negocio. Estos servicios tienen una aplicación amplia sobre el stack de software, incluyendo la interfaz de usuario, el almacenamiento persistente, e integraciones externas. En consecuencia, los equipos deben tener capacidades cruzadas, incluyendo diversas habilidades para el desarrollo: la experiencia del usuario, base de datos y gestión de proyectos.

Documentos relacionados

Bechtle Solutions Servicios Profesionales

Soluciones Tecnología Bechtle Solutions Servicios Profesionales Fin del servicio de soporte técnico de Windows Server 2003 No hacer nada puede ser un riesgo BECHTLE Su especialista en informática Ahora