Microservicios y computacion

Vista previa del material en texto

Tema 7.
Micro-Arquitecturas y computación 
en la nube
Miguel A. Laguna
Objetivos
 Conocer las características de los microservicios y la 
relación con la nube.
 Conocer los conceptos básicos del método DDD 
(Domain Driven Design)
 Conocer las características de SAAS (Software as a 
service)
Desarrollo del tema
 Microservicios
 Domain Driven Design
 Cloud Computing y SaaS, “Software as 
a service”
Bibliografía
 Eric Evans, “Domain-Driven Design: Tackling Complexity in the 
Heart of Software”. Addison Wesley, 2003.
 InfoQ, “Domain Driven Design Quickly” 
 C. Carneiro, T. Schmelmer. “Microservices From Day One”, 
Apress, 2016
 T. Hunter, “Advanced Microservices”, Apress, 2017
7.1 Microservicios
Monolitos (JEE/SOA) y 
Microservicios
Monolitos y Microservicios
 Con un Monolito cualquier cambio requiere una re-
compilación y despliegue de toda la aplicación.
 Con Microservicios, sin embargo, sólo es necesario 
volver a implementar y desplegar el servicio 
modificado.
 Problema:Transacciones complejas
 Cuando los componentes son servicios con comunicaciones 
remotas, la refactorización (reorganizar código entre 
servicios) es mucho más difícil que con proyectos únicos e 
interfaces locales (.ear, .jar)
Características de una 
Arquitectura de Microservicios
 Componentization vía Servicios
 “una unidad de software que es reemplazable y actualizable de 
forma independiente ”
 Organizada en función de las capacidades del negocio
Características de una 
Arquitectura de Microservicios
 Productos y no Proyectos
 "you build, you run it“
 La Inteligencia debe residir en los componentes, no 
en los conectores
 Componentes: Bases de datos, colas de mensajes, clases 
 Conectores: Servidores Web, contenedores JEE, 
navegadores, servidores proxy
 Por lo tanto, No ESB: protocolos REST, no BPEL/WS-
Choreography
Características de una 
Arquitectura de Microservicios
 Gobierno descentralizado
 Herramientas, contratos entre los servicios
 Automatización de la infraestructura
 Tests y despliegue automáticos
Características de una 
Arquitectura de Microservicios
 Gestión de datos descentralizada
 El modelo conceptual del mundo puede ser diferente… 
varias DBs->Persistencia poliglota
Características de una 
Arquitectura de Microservicios
 Diseñada para fallos
 Pruebas automatizadas en producción
 La monitorización es vital para detectar rápidamente malos 
comportamientos emergentes
 Llamadas síncronas consideradas “dañinas” (harmful)
 Diseño evolutivo
 La propiedad clave de un componente es la noción de 
sustitución independiente y capacidad de actualización
 Cambiar componentes por servicios da la oportunidad para 
planificar las entregas de forma más granular.
7.2 DDD:
Domain Driven Design
• (Método de Diseño recomendado para el 
desarrollo de Microservicios)
Domain Driven Design
 Concepto de Ubiquitous Language, desde requisitos a 
implementación (conceptos del dominio)
 Basado en capas
 Pero el dominio tiene en cuenta clases de diseño (no solo las 
entidades originales)
Patrones de diseño DDD:
Patrones básicos
Equivalencias
 Entities: clases del dominio (con identidad)
 Cliente, Factura, …
 Value Objects: clases anónimas (DTOs)
 Fechas, direcciones, …
 Deben ser inmutables!
 Services: objetos de diseño que no encajan como una 
operación de una clase del dominio aunque se refieren 
a ellas
 Un informe, estadística, … 
 (capa de aplicación más que capa de dominio)
 Conjuntos de operaciones sin estado
Ciclo de vida de los objetos
 Aggregates: los objetos componentes solo son 
accedidos a través del compuesto 
- nombre : string
- id : int
Cliente
- email : string
- telefTrabajo : int
- telefono : int
Contacto
1
- ciudad : string
- calle : string
Direccion0..1
Ciclo de vida de los objetos
 Factories: los objetos complejos (por ejemplo, 
agregados) deben ser creados mediante factorías en 
lugar de un simple constructor 
 Proceso atómico que garantice todos los invariantes
 Patrones de Gamma bien conocidos
 Repositories: los objetos son recuperados de una 
base de datos en lugar de creados nuevos
 Mantiene referencias a objetos en memoria o los recupera 
de la BD si es necesario
 Operaciones CRUD, aplicar patrones DAO, active record, etc.
Patrones DDD:
Integridad del modelo
Bounded Context/Context Map
 Se divide la aplicación en varios modelos (con su 
contexto ligado) independientes: 
 El mapa de contexto muestra la relación entre varios 
modelos 
Shared Kernel
Customer-Supplier
 En Shared Kernel se crea un 
tercer modelo, que debería 
ser estable y consensuado
 Gestión básica de empleados, 
común con aplicaciones de 
vacaciones, de gastos y dietas
 En Customer-Supplier, un 
modelo depende del otro 
 Ejemplo: Tienda On-Line y un 
subsistema de informes de 
ventas hechos a partir de la 
misma BD
Supplier
Customer
Anticorruption Layer
 Patrón adaptador, permite utilizar aplicaciones 
legadas
Transacciones
 La solución fácil: las transacciones atómicas están 
limitadas a cada microservicio (y su “bounded context”)
 (siempre se puede rediseñar dos servicios como uno…)
Transacciones: alternativa
 Utilizar una arquitectura dirigida por eventos que se 
van archivando en una BD y permiten reconstruir el 
estado
 Las instantáneas mejoran el rendimiento
Consultas: CRSQ
 Patrón Command Query Responsibility Segregation
Cómo refactorizar el código de un 
monolito en microservicios
 En una aplicación monolítica Java EE (WAR o EAR), 
toda la funcionalidad se empaqueta en una sola 
unidad de despligue (.ear). 
 Un aplicación de ventas on line tendrá usuario, catálogo y 
pedido, todos los recursos en la misma unidad.
Microservicios
Los pasos
 La aplicación anterior se descompone en componentes 
 User, Order y Catalog como archivos WAR independientes, con 
sus páginas web, sus clases y su configuración
 Se mantiene Java EE para cada componente
 Pero los componentes se comunican mediante una API REST
 Cada archivo tiene su propia base de datos 
 Esto permite que cada microservicio evolucione y use cualquier 
tipo de datos (relacional, NoSQL, archivo plano, en memoria)
 [Cada servicio se registra]
 (Se utiliza un registro como Netflix Eureka para poder escalar la 
aplicación y usar múltiples copias)
Los pasos…
Patrón (Dumb) Proxy 
 La interacción del cliente se define en otra aplicación que 
utiliza los servicios y los compone. 
 Debe ser un proxy donde se invocan las páginas de interfaz de 
usuario de los diferentes componentes para mostrar la interfaz. 
 La apariencia común se puede lograr mediante recursos 
estándar CSS o JavaScript
Otros Patrones
 Servicios Encadenados (chained) o en árbol (branch). 
Uno es síncrono, el otro permite paralelismo
Otros Patrones
 Mensajes asíncronos (async). 
Despliegue en Contenedores: 
Docker
Contenedores: Docker
 Se parten de imágenes básicas que contienen una ya 
plataforma básica tipo PAAS (Java + Tomcat, JEE+ GlassFish
por ej.) 
 Los contenedores requieren muchos menos recursos que las 
máquinas virtuales, fáciles de implementar y arrancan rápido. 
 Permite ejecutar más servicios en la misma unidad de hardware, lo 
que reduce los costes
 Pero supone menos aislamiento que las VM
 El objetivo principal de una imagen es que el entorno 
(dependencias) sea el mismo siempre. 
 Se puede desarrollar en una máquina e implantarlo en otra con el 
mismo entorno garantizado.
 Una imagen de Docker empaqueta un servicio (o microservicio) 
y permite desplegarlo de manera fiable y reproducible
Hola Mundo en Docker
 Las imágenes se definen en un archive Dockerfile qu
contiene una lista de commandos:
FROM fedora:latest
CMD echo “Hello world”
 Se genera la imagen Docker nuevaImagen y se 
ejecuta
docker run nuevaImagen
 Las imágenes están registradas en Docker Hub (SaaS 
público)
 https://hub.docker.com/explore/
Situaciones de uso
 Multiplataforma. La arquitectura de la aplicación se basa en 
microservicios.
 Cada microservicio tiene su propia BD autónoma
 Los contenedores arrancan rápidamente y tienen una huella 
pequeña para lograr más contenedores por unidad de 
hardware para reducir sus costes
Comunicación entre 
microservicios
 Evitar llamadas síncronas
Despliegue del servicio: 
DevOps
 Con herramientas se puede automatizar todas las fases
7.3 Cloud Computing y SaaS
SaaS: Software as a Service
Cloud Computing y SaaS
 Cloud Computing consiste en usar un software y/o 
hardware remoto que un proveedor (incluyendo la 
misma empresa internamente) administra y ofrece 
como servicio
 SaaS es una de las posibilidades de Cloud Computing 
Cloud Computing
 Un paso natural para la industria de TI:
 del sector secundario de la economía (fabricación) 
 al sector terciario de la economía (servicios) 
 Explotación de las economías de escala
 Modelos:
 Nube pública o privada
 economía de escala vs aspectos legales
 Nivel de servicios:
 IaaS : Infrastructure as a Service (Hardware)
 PaaS: Platform as a Service (Hardware + Software básico)
 SaaS: Software as a Service (Aplicaciones completas)
Economías de escala
Clusters: ordenadores simples conectados en red
 Más escalable que los servidores convencionales 
 Mucho más barato que los servidores convencionales 
 20 veces más barato que los servidores grandes 
equivalentes
 Y normalmente se utiliza un 10% de la capacidad
 1000 ordenadores * 1 hora= 1 ordenador * 1000 horas
 Fiabilidad a través de redundancia
 Pocos operadores para miles de servidores 
 Selección cuidadosa de HW/SW idénticos
 Monitores de máquinas virtuales (simplifican la operación)
Infrastructure as a Service
 Hardware virtualizado formando una red
 Máquinas, memoria, CPU, discos 
 Networking, Balanceadores de carga, acceso a 
Internet 
 Ejemplo IaaS: Amazon EC2 (o ETSII/INFOR)
 Se controla el SW y se paga por el HW que se 
necesita cuando se necesita (ventas de navidad)
 Ventajas para el medio ambiente
 Reduce el consumo de energía, tanto para alimentación 
como para refrigeración.
Platform as a Service
 Añade a IaaS:
 Gestores de Bases de datos o plataformas de desarrollo
 Ya están instalados 
 Desventaja: menos flexibilidad 
 Ejemplos: Google App Engine, Microsoft Azure, 
Heroku (o ETSII/INFOR, Linux+JEE+Netbeans)
 Compiladores/Interpretes, Frameworks de desarrollo y 
Gestores de bases de datos preinstalados
Software as a Service
 Software alojado en un host remoto y accedido a 
través de Internet (navegador)
 El precio es pago por uso
 La infraestructura local es mínima.
 Siempre se tiene el software actualizado.
 Para empresas
 Software de gestión que se paga mensualmente: Salesforce, 
MS Office
 Para el cliente particular
 Juegos on-line, Facebook, Google Apps, etc. se paga con 
publicidad.
Software as a Service
 La virtualización ha facilitado el crecimiento del SaaS.
 Las pequeñas empresas de desarrollo lo tienen más fácil 
gracias a sistemas como Amazon EC2, Google (App Engine), 
o Microsoft (Azure .NET, SQL)
 La modularidad del SaaS hace que sea también un 
modelo de servicios. 
 SOA/ROA (SOAP/REST) es la arquitectura en la que se 
apoya SaaS
 Ejemplos
 Software horizontal de comunicación: e-mail.
 Software vertical con acceso web o móvil: ventas
SaaS: Características
 La aplicación está centralizada en la sede del proveedor, en vez 
de en las sedes de los clientes.
 Tanto el acceso como la administración de la aplicación se 
realiza a través de la red.
 La distribución sigue el modelo uno a muchos. Una instancia 
con múltiples usuarios.
 Simple: Los recursos de los clientes están segregados físicamente.
 De grano fino: Los recursos de un cliente sólo están segregados a 
nivel de software.
 Escalabilidad es transparente
 La aplicación se puede integrar con otras, permitiendo al cliente 
definir sus propios procesos (mashup).
Ejemplos de aplicación:
 Software de comunicación: gmail
 Software con acceso web o móvil: ventas on line
 Software donde la demanda oscile significativamente 
o se va a usar por un corto espacio de tiempo.
 Software donde se tenga previsto contratar soporte.
 El coste de una licencia tradicional más un contrato de 
soporte sale más caro que un contrato SaaS.
 ¿Cuándo no usar SaaS?
 Aplicaciones donde el tiempo de respuesta sea crítico.
 Aplicaciones donde la legalidad vigente no permita que los 
datos esté alojados externamente.
Ventajas (para el cliente)
 Cualquier aplicación, por compleja que sea, puede alojarse en la 
nube. 
 Se puede acceder a la aplicación desde cualquier parte del mundo.
 Externaliza/Simplifica la adquisición y mantenimiento de la 
infraestructura.
 Se reducen gastos relacionados con el sistema informático.
 El software es siempre el mismo en todas las sedes y 
departamentos de la empresa.
 Las actualizaciones de software aparecen al instante. 
 Cuando las necesidades cambian, puede adquirirse nuevo software 
en minutos
 Los datos son consistentes en toda la empresa.
 Los datos están guardados con seguridad, cifrados y con copias de 
respaldo.
Inconvenientes/Riesgos
 Depende del buen funcionamiento de internet (causas externas 
pueden interrumpir el servicio) y de la solvencia del proveedor.
 Las acciones ilegales de unos usuarios puede provocar que 
se bloquee el servicio a todos (Megaupload).
 Un proveedor puede ser comprado por otra empresa.
 El usuario no tiene acceso directo a sus contenidos
 Si los datos no están cifrados pueden ser consultados por terceros 
(por error o malintencionadamente).
 ¿Sigue siendo el usuario el propietario de los datos?
 Si se deja de pagar, se deja de tener acceso a los datos!!
 El usuario no puede adaptar el programa más allá de lo que el 
propio programa ofrezca.
 Migrar a otra plataforma o usar varias es difícil.
Punto de vista del proveedor
 Aunque al principio el beneficio es menor, el flujo de ingresos es 
continuo y el volumen de clientes es mayor
 Arquitectura efectiva debido a la virtualización.
 Combate la piratería de software.
Pero:
 Un modelo de software con licencia no es fácil de transformar 
en un modelo de suscripción.
 No todas las aplicaciones son adecuadas para SaaS:
 Esquemas de datos y operaciones complejas con requisitos que 
varíen mucho entre clientes.
 Aplicaciones que puedan requerir mucho esfuerzo para una 
clientela potencial reducida.
Modelo Mixto:
Software + Servicios
 Software local complementado con servicios en la nube
 Mejor experiencia del usuario
 La usabilidad de una aplicación en un navegador no está al nivel 
de un software local. 
 Combinar un cliente local con la información obtenida de 
internet combina lo mejor de ambos mundos.
 Trabajo fuera de línea
 No tener que trabajar siempre conectado da mucha flexibilidad 
(problema de sincronización).
 Privacidad y Flexibilidad
 Se puede mantener los datos más sensibles localmente
7.3.1
Desarrollo para SaaS
 Requisitos
 Arquitecturas SaaS
 Principios de diseño
Requisitos
 Ser lo suficientemente genérica. 
 Ser fácil de usar y proporcionar mejoras sin impacto 
para el cliente
 Ser accedida a través de la web
 Garantizar la seguridad, integridad de los datos y su 
independencia entre clientes
 Ser gestionada de manera centralizada.
 Ser modular y escalable (orientada a servicios)
 Incluir monitorización y medición de uso.
 La facturación debe estar integrada.
Arquitecturas SaaS
 El desarrollo de aplicaciones SaaS no es distinto del 
desarrollo de aplicaciones tradicionales web.
 Hay que tener en cuenta ciertos aspectos 
relacionados con la nube:
 Fácil configuración para cada cliente
 “Multitenancy”
 Escalabilidad
 Cuatro niveles de madurez
Arquitectura Ad-Hoc
 No incorpora ninguno de los atributos.
 Cada cliente tiene una versión personalizada del 
software (¿líneas de productos?).
 La instancia de la aplicaciónse ejecuta en un servidor 
para dicho cliente.
 La migración de una aplicación a este tipo de servicio 
es el que requiere menos esfuerzo a priori, pero no a 
largo plazo.
Arquitectura Configurable
 Una base de código común y metadatos de 
configuración.
 Permite crear varias instancias para varios clientes.
 (No multitenancy)
 El proveedor puede satisfacer las necesidades de 
varios clientes mediante distintas configuraciones.
 Varios clientes pueden usar instancias independientes 
de la misma aplicación.
 El tener una base de código común facilita el 
mantenimiento.
Arquitectura multitenancy
 Se añade multitenancy al nivel anterior.
 Una única instancia de la aplicación puede dar 
servicio a todos los clientes.
 Permite un uso más eficiente de los recursos sin que 
el cliente aprecie diferencias.
Arquitectura escalable
 Se añade escalabilidad al nivel anterior
 Soporta de forma balanceada un conjunto de 
instancias idénticas de una aplicación ejecutándose 
sobre un número variable de servidores.
 Incrementando o decrementando dinámicamente la 
capacidad del sistema permite satisfacer la demanda 
de cada instante
Arquitectura escalable
 Escalabilidad horizontal
 La tendencia actual es hacia el uso de más núcleos en lugar 
de núcleos más rápidos.
 El diseño de algoritmos paralelizables saca ventaja de ello.
 Redundancia
 Aumenta la confianza en la nube y mejora el servicio.
 Si un servidor cae, otros pueden reemplazarlo.
 Cada cliente accede a los datos más cercanos.
 Tolerancia a fallos
 Un entorno cloud puede llegar a ser caótico e incontrolado, 
y los datos pueden no estar sincronizados.
Frameworks para SaaS
 Clásicos (Java): Oracle Sun/Microsoft/IBM/Spring
 Ruby on Rails, Django/Python, Zend/PHP, 
 Rails utiliza Ruby - por ejemplo, Twitter 
 Ruby es un lenguaje de scripting: orientado a objetos y 
funcional 
 Crear una aplicación nueva supone crear toda la 
infraestructura MVC. Añadir una tabla y una vista es 
suficiente para ver la aplicación en marcha.