DISEÑO DE SISTEMAS ORIENTADOS A CLOUD COMPUTING - 2011 CONSTRUCCIÓN DE SISTEMAS II
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
DISEÑO DE SISTEMAS
ORIENTADOS A
CLOUD COMPUTING
ING. VIVIANA LEDESMA
ING. ANALÍA MARÍN
DEPARTAMENTO DE INGENIERÍA E INVESTIGACIONES
TECNOLÓGICAS
CONSTRUCCIÓN DE SISTEMAS II
2011
Diseño de Sistemas Orientados a Cloud Computing - 2011
CONTENIDO PÁG.
1. ¿QUÉ ES “CLOUD COMPUTING”? .................................................................................................. 3
1.1 SERVICIOS OFRECIDOS DESDE CLOUD COMPUTING .............................................................. 4
1.2 TIPOS DE NUBE ..................................................................................................................... 6
1.3 VENTAJAS Y DESVENTAJAS DE CLOUD COMPUTING .............................................................. 7
2. SOFTWARE COMO SERVICIO ......................................................................................................... 8
2.1 CARACTERÍSTICAS DE LAS APLICACIONES SAAS ................................................................... 9
2.2 SAAS Y LA INGENIERÍA DE SOFTWARE ................................................................................ 10
2.3 IMPACTO EN EL PROCESO DE DESARROLLO DE SOFTWARE .................................................. 11
3. DISEÑO ORIENTADO AL SOFTWARE COMO SERVICIO ................................................................ 13
3.1 INVESTIGACIÓN Y EVALUACIÓN DE TECNOLOGÍAS .............................................................. 13
3.2 DISEÑO DE ARQUITECTURA ................................................................................................ 13
3.3 DISEÑO DE DATOS ............................................................................................................... 15
3.4 INGENIERÍA DE PROCESOS DE NEGOCIO .............................................................................. 19
3.5 DISEÑO DE PRUEBAS ........................................................................................................... 19
4. SOA EN LA NUBE ........................................................................................................................ 20
4.1 POR QUÉ PENSAR EN SOA .................................................................................................. 21
4.2 ARQUITECTURA ORIENTADA A SERVICIOS .......................................................................... 22
4.3 ENTRERPRISE SERVICE BUS (ESB) ..................................................................................... 23
4.4 LA INFRAESTRUCTURA TECNOLÓGICA DE UNA SOA............................................................ 25
4.5 SOA VS CLOUD COMPUTING .............................................................................................. 26
REFERENCIAS ..................................................................................................................................... 27
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 2
Diseño de Sistemas Orientados a Cloud Computing - 2011
1. ¿QUÉ ES “CLOUD COMPUTING”?
Cloud Computing es un paradigma de computación emergente donde los datos y servicios
residen en centros de datos muy escalables que pueden ser accedidos desde cualquier
dispositivo conectado a Internet.
Cloud Computing se está convirtiendo en una plataforma escalable de prestación de servicios
en el ámbito de los Servicios de Informática. Se trata de recursos IT compartidos en demanda,
creados y eliminados eficientemente y de modo escalable facturados en base a su uso.
Los fundamentos técnicos de Cloud Computing incluyen arquitectura orientada a servicios y
virtualizaciones de hardware y software. El objetivo es compartir los recursos entre los
consumidores, socios y proveedores de servicios cloud.
Existe una gran diferencia entre la computación tradicional y cloud computing ya que se trata
de dos modelos de manejo de la información empresarial muy distintas.
Computación Tradicional Cloud Computing
Se requiere la compra e instalación de activos, Se compra servicios tanto relacionados a
como equipos, servidores, sistemas etc. infraestructura como a software.
necesitando tanto un espacio físico, una
instalación adecuada y trabajo de administración
de los mismos.
Compra de software especializado con políticas de Pago por uso.
licencias por equipo.
Acceso a través de la red corporativa interna. Se accede a través de cualquier dispositivo que
tenga acceso a internet.
Para un único tenant1, estática, en general no Escalabilidad, elasticidad, dinámica, multi-tenant.
compartido.
1
Comúnmente se usa el término tenant para referirse tanto a los clientes como proveedores que usan la plataforma para
consumir o proveer las aplicaciones como1 servicio.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 3
Diseño de Sistemas Orientados a Cloud Computing - 2011
1.1 SERVICIOS OFRECIDOS DESDE CLOUD COMPUTING
A continuación, se intenta explicar gráficamente, de una manera gráfica y sencilla los
distintos niveles de servicio que se ofrecen desde “Cloud Computing”.
Ilustración 1
Servicios para Usuarios
Servicios basados en la web Software as a Service
Finales
Componentes App as a Service
Plataforma as a Service Servicios dirigidos a
organizaciones de IT
Infraestructura as a Service
Servicios tradicionales de Data
Infraestructura física as a Service Center
Figura 1. Niveles de Servicios ofrecidos por la nube
Para los niveles inferiores se han estandarizado tecnologías Web y protocolos para el acceso y
uso de la nube, mientras que en los niveles superiores, se añade mayor grado de abstracción,
cada proveedor realiza aplicaciones más específicas.
Tal como muestra la Figura 1 la oferta para usuarios finales está dividida en dos segmentos, a
nivel técnico, ambos segmentos son muy similares, ya que ambos tipos de servicio se
desarrollan y entregan de la misma forma. Sin embargo, lo que difiere es el modelo de negocio
y por eso se los clasifica como dos mercados diferentes:
• Servicios basados en la Web. Este segmento está dirigido especialmente a los
individuos, se trata de servicios en la nube como las redes sociales (por ejemplo,
Facebook o LinkedIn) y software colaborativo (como los de video conferencias,
administración de documentos, seminarios web, etc.). Estos servicios están cambiando
la forma en que las personas tanto en forma individual como también dentro de las
empresas, acceden, entregan y entienden la información.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 4Diseño de Sistemas Orientados a Cloud Computing - 2011
• Software as a Service (SaaS). Es un modelo de distribución de software dirigido
a usuarios empresariales. Su modelo de negocio está basado en un esquema de renta o
pago por uso, donde una empresa provee el mantenimiento, soporte y operación que
usará el cliente durante el tiempo que haya contratado el servicio. El cliente usará el
sistema alojado por esa empresa, la cual mantendrá la información del cliente en sus
sistemas y proveerá los recursos necesarios para explotar esa información.
Todos estos productos tienen en común la característica de estar diseñados para
procesos de negocio específicos que los clientes pueden modificar. Entre este tipo de
servicios encontramos productos para la gestión: de clientes, de proveedores, de
recursos humanos, financiera, por nombrar solo los más comunes. (Ejemplos:
Salesforce, Basecamp).
Por otra parte, la oferta de Cloud Computing para organizaciones de IT está dirigida a atender
las necesidades de las personas y organizaciones que desean desarrollar y entregar sus propias
aplicaciones bajo un esquema de computación en la nube. Es así que podemos distinguir los
siguientes tres segmentos de mercado dirigidos a organizaciones de IT:
• Componentes aplicativos como servicio. Componentes accesibles como
servicio web que los desarrolladores utilizan para ensamblar o complementar sus
propias aplicaciones web. Existen distintos tipos de aplicaciones, por ejemplo,
aplicaciones de Redes Sociales, servicios de copia de seguridad, servicios de mapeo
tales como Google Maps y Yahoo! Maps. Un ejemplo dirigido al segmento empresarial
es el de Avalara, que provee componentes para el cálculo de impuestos que los
desarrolladores pueden integrar dentro de sus aplicaciones web empresariales.
• Plataforma como servicio (PaaS). No todas las aplicaciones en la nube podrán
ser ensambladas como “mashups” a partir de componentes existentes. En muchos
casos se requiere desarrollar y, como toda aplicación, se necesita un entorno sobre el
cual ejecutarse. PaaS es el resultado de la aplicación al desarrollo de Software del
modelo SaaS. El modelo PaaS abarca el ciclo completo para desarrollar e implantar
aplicaciones desde Internet, incluye todas las facilidades para analizar, desarrollar,
testear, documentar y poner en marcha aplicaciones todo en un sólo proceso, además,
da servicio de integración de bases de datos, seguridad, escalabilidad, almacenaje,
copias de seguridad, control de versiones y facilidad para colaborar en la comunidad.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 5Diseño de Sistemas Orientados a Cloud Computing - 2011
Como ejemplo de plataformas que integran todo el ciclo de vida se pueden mencionar
Google App Engine y Microsoft Azufre.
Si bien las características anteriores suelen ser comunes a la mayoría de las PaaS,
existen algunas que apuntan a necesidades específicas: algunas incluyen en el core un
paquete de software de negocio, un buen ejemplo es Salesforce.com y su plataforma
Force.com. Otras, en lugar de proveer un ambiente para el ciclo de vida completo, se
enfocan en proveer extensiones a infraestructura y plataformas cloud con
funcionalidades básicas (como Amazon Simple DB o Google Big Table).
• Infraestructura virtual como servicio (IaaS). También conocido como
“hardware como servicio” (HaaS), supone una evolución del hosting web y de los
servidores virtuales privados, este segmento se refiere a la oferta de servicios de
procesamiento, almacenamiento, capacidad de red y otros recursos computacionales
como servicios estandarizados en la red (por ejemplo EC2 – Elastic Compute Cloud, S3
– Simple Storage Service).
Servidores, sistemas de almacenamiento, conexiones, routers y otros sistemas se
concentran (por ej. a través de tecnología de virtualización) para manejar tipos
específicos de carga de trabajo (desde procesamientos en batch hasta aumento de
servidor/almacenamiento durante las cargas pico).
1.2 TIPOS DE NUBE
En la computación en la nube existen tres tipos diferentes de “nubes”: las nubes públicas,
nubes privadas y nubes híbridas. Cada una de ellas tiene su fin y ofrecen diversas
características dependiendo de qué tipo de servicio o datos se estará manejando, es posible
definir una variable común, la seguridad, la gestión del hardware y las aplicaciones que se
requieren.
• Nube privada: agrupa los servicios y la infraestructura en una red privada, ofrece un
mayor nivel de seguridad y control, pero requiere que la compañía compre y mantenga
todo el software y la infraestructura. Una nube privada es ideal cuando para la empresa
la seguridad y el control es fundamental; cuando la empresa es suficientemente grande
y el negocio requiere estrictas medidas de seguridad.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 6Diseño de Sistemas Orientados a Cloud Computing - 2011
• Nube pública: es aquella en la que los servicios e infraestructura son provistos por
sitios a través de Internet. Ofrece un mayor nivel de eficiencia en los recursos
compartidos y reduce los gastos, aunque una de sus debilidades es el alto grado de
vulnerabilidad. Es perfecta para trabajar con SaaS y si se necesita capacidad de
escalamiento.
• Nube híbrida: ofrece varias opciones tanto de nubes privadas como públicas, una
desventaja son las múltiples plataformas de seguridad así como asegurarse que todos
los aspectos del negocio se podrán comunicar entre sí. Esta nube es excelente cuando se
hace uso de SaaS pero a la vez se tienen problemas con la seguridad. También cuando
se hace uso de una nube pública para interactuar con el cliente y una privada para los
datos sensibles.
1.3 VENTAJAS Y DESVENTAJAS DE CLOUD COMPUTING
Las principales ventajas de Cloud Computing son:
Acceso a la información y los servicios desde cualquier lugar.
Disponibilidad del servicio y/o aplicación web 24h/7dias/365dias.
Accesibilidad mediante diferentes tecnologías compatibles, tales como: móviles,
portátiles, blackberrys, netbooks, etc.
Servicios gratuitos y de pago según las necesidades del usuario.
Capacidad de procesamiento y almacenamiento sin instalar máquinas localmente.
La virtualización da la ventaja de permitir escalabilidad (fácilmente puedes escalar
o desescalar los sistemas a nivel de infraestructura según las necesidades en cada
momento) y bajo costo del hardware (es más barato que el hardware tradicional).
Como desventajas se puede mencionar las siguientes:
La centralización de las aplicaciones y el almacenamiento de los datos origina una
interdependencia de los proveedores de servicios.
La disponibilidad de las aplicaciones está ligada a la disponibilidad de acceso a
internet.
Los datos "sensibles" del negocio no residen en las instalaciones de las empresas
por lo que podría generar un contexto de alta vulnerabilidad para la sustracción o
robo de información.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 7Diseño de Sistemas Orientados a Cloud Computing - 2011
La sostenibilidad del proveedor tiene que estar garantizada. Fusiones, quiebras,
cualquier cambio en su negocio podría dejar ‘indefenso’ al cliente y, por ello, se
debe establecer un compromiso de continuidad a largo plazo en la relación en los
propios términos del contrato.
2. SOFTWARE COMO SERVICIO
Actualmente el Software como Servicio, SaaS (Software as a Service) es el área mas madura
de cloud computing. Se trata de un modelo que distribuye aplicaciones a través de Internet.
Los usuarios de las aplicaciones de software SaaS no pagan licencias de instalación sino una
renta mensual por el uso.
El concepto de "software as a service", SAAS, se basa en que los datos y programas se
almacenan en un ambiente seguro centralizado, que es de fácil acceso y sencilla
administración. Cada usuario en la red tiene su propio perfil, accesible desde un directorio
común, sin estar atado a una computadora especifica. Los usuarios almacenan sus datos en un
repositorio central y no en maquinas locales. Las aplicaciones y servicios son manejadas desde
ese directorio común, con accesos predefinidos de acuerdo a los roles de los usuarios, en su
grupo correspondiente.
En este modelo el vendedor del software proporciona una versión de la misma en un servidor
en la Web. Los clientes acceden a la aplicación desde un Sitio Web, pagado por uso, por
proyecto o por suscripción. Se elimina de esta manera la necesidad de invertir altas sumas en
la compra de licencias de software. También elimina los costos y riesgos de instalar, dar
soporte y mantenimiento de hardware en computadoras de la empresa y de mantener personal
necesario. Además, el acceso del usuario y el rendimiento de las aplicaciones pueden mejorarse
dramáticamente con los sistemas basados en la Web disponibles 24 horas diarias, 7 días a la
semana.
Las ventajas de uso inmediato, pago por uso, actualizaciones inmediatas, recuperación
instantánea de fallas y no tener que preocuparse del mantenimiento han capturado de
inmediato al mercado, razón por la cual se puede afirmar que el SaaS es sin duda el futuro de
la industria del software.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 8Diseño de Sistemas Orientados a Cloud Computing - 2011
2.1 CARACTERÍSTICAS DE LAS APLICACIONES SAAS
¿Qué características debe tener una aplicación SaaS para que sea comercialmente viable?
Debería cubrir al menos las siguientes necesidades:
Es necesario que la aplicación sea lo suficientemente genérica como para que una
gran cantidad de clientes potenciales se interesen en el servicio: algunos ejemplos
de estos tipos de aplicaciones son: contables, para gestión de proyectos, de testing,
para marketing en Internet, CRM, etc.
Es necesario que sean fáciles de usar: si la aplicación no es amigable y fácil de usar
el cliente simplemente cancela la suscripción.
Debe ser modular y orientada a servicios: si la arquitectura no es orientada a
servicios hará difícil el introducir cambios y por otra parte dificultará que la
aplicación pueda operar junto a otras aplicaciones SaaS de terceros.
La aplicación debe incluir medición y control del uso real de cada cliente.
La aplicación debe tener un servicio de facturación integrado.
Debe asegurar la separación y seguridad de los datos y configuración especial de
cada cliente.
Debe permitir que los clientes puedan configurar sus procesos de negocio: por
ejemplo, una compañía podría querer agregar un proceso para que un gerente
apruebe un precio antes de hacer la oferta a un cliente, una herramienta integrada
de configuración puede permitir que esto se haga sin necesidad de programación.
Las aplicaciones SaaS necesitan constantemente liberar versiones con nuevas
características y capacidades: este proceso no debería impactar en el uso de los
clientes que deberían continuar con su operatoria normal sin interrupción.
Debe proteger la integridad de los datos del cliente: incluye proveer técnicas para la
migración de datos ya sea para almacenarlo en una base privada o de terceros.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 9Diseño de Sistemas Orientados a Cloud Computing - 2011
2.2 SAAS Y LA INGENIERÍA DE SOFTWARE
Por el lado de la Ingeniería de Software, las aplicaciones SaaS presentan diferencias con
relación a las aplicaciones empaquetadas (la captura de requerimientos, la instalación, el
mantenimiento, por mencionar solo algunos ejemplos, son diferentes), por lo cual, se requiere
un enfoque alterado de Ingeniería de Software para este tipo de aplicaciones.
Una pregunta importante es cómo el enfoque SaaS afecta a los proveedores de software y su
incentivo a invertir en el desarrollo de productos. Transformar un producto empaquetado a un
modelo SaaS no es una simple cuestión de reescribir código. Estas compañías necesitan
examinar sus modelos de ingeniería y comercialización para adaptarse a este nuevo enfoque de
negocio y de desarrollo.
Figura 2. Ciclo de Vida de aplicaciones SaaS
La figura anterior describe que las actividades de cada etapa del ciclo de vida son diferentes a
las de un producto tradicional. Una de las causas principales de estas diferencias, es que las
aplicaciones SaaS están acopladas a una plataforma y en cada etapa esta plataforma juega un
rol importante en el ciclo de vida SaaS.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 10Diseño de Sistemas Orientados a Cloud Computing - 2011
2.3 IMPACTO EN EL PROCESO DE DESARROLLO DE SOFTWARE
Se debe tener en consideración el efecto en el proceso de desarrollo de software del enfoque de
aplicaciones como servicios. A continuación se realiza un breve análisis del impacto en cada
etapa o actividad de dicho proceso:
En el enfoque tradicional, los requerimientos consisten en definir una
Requerimientos serie de funciones que satisfagan las necesidades de un cliente. En el
caso de las aplicaciones SaaS, los desarrollos son meramente basados
en un modelo de negocio. Eso es, una aplicación SaaS debe cumplir
con los requerimientos de un mercado. Debido a que las aplicaciones
serán consumidas por un gran número de subscriptores (empresas
clientes) y cada uno puede tener potencialmente un número grande de
usuarios, entonces se introducen al proceso más requerimientos no
funcionales, como por ejemplo: soporte para alta concurrencia,
almacenamiento escalable, virtualización/ clustering entre otros. Es
necesario definir un plan de requerimientos de negocio que luego se
transformarán en requerimientos funcionales.
La etapa de análisis debe ser realizada también desde la perspectiva de
negocio. Esto es debido a que cada aplicación tratará de satisfacer las
Análisis necesidades de un amplio número de clientes. La definición de los
procesos de negocio que soportará cada aplicación es un paso
importante en este tipo de aplicaciones, ya que debe permitir la
personalización y definición de procesos similares para cada cliente.
Cada proceso con sus actividades, roles y reglas de ejecución debiera
ser documentado.
En esta etapa tendría lugar la identificación de los casos de uso,
basados en modelos de procesos, bien podrían estar alineados a SOA.
Frecuentemente los casos de uso resultantes son análogos a servicios,
por lo tanto, la especificación de los mismos sería el primer paso de la
especificación de servicios.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 11Diseño de Sistemas Orientados a Cloud Computing - 2011
El diseño es una de las etapas que mayor impacto ha recibido con esta
Diseño nueva concepción de software. Con los diseños tradicionales casi es
imposible pensar en múltiples clientes usando la misma instancia de
una aplicación, así también en requerimientos de escalabilidad,
personalización para cada cliente , etc. La siguiente sección trata más
en profundidad las cuestiones implicadas en el diseño de una
aplicación SaaS.
Además de las tareas comunes involucradas en la implementación,
Implementación dentro del desarrollo SaaS es necesario considerar a la plataforma que
soporta las aplicaciones.
Una vez que se desarrollan los de servicios de negocio, se codifican las
interfaces principales de la aplicación, así como sus implementaciones,
el siguiente paso importante es la integración con los servicios de la
plataforma, es decir desarrollar el código para consumir los servicios
que la aplicación necesita para operar. Estos servicios consumidos
pueden ser de seguridad, logging, métricas, etc.
Las siguientes tareas serán desarrollar la lógica de negocio, las
interfaces de usuario y el desarrollo para la integración con otros
sistemas. Es necesario asegurar que toda la implementación de
tecnología funciona correctamente.
Como para toda aplicación se deben ejecutar todo tipo de pruebas, la
Pruebas principal diferencia entre las metodologías tradicionales y la propuesta
para SaaS radica en las pruebas de integración, rendimiento y métricas
de uso. (Se consideran más detalles sobre pruebas en la Sección 3).
Como se puede observar, el desarrollo de SaaS requiere de consideraciones de diversos
factores que no presentan los métodos actuales de desarrollo de software. Las diferencias entre
desarrollar software como servicio o como producto empaquetado son evidentes y estas
diferencias cambian la manera en que se desarrollan dichas aplicaciones.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 12Diseño de Sistemas Orientados a Cloud Computing - 2011
3. DISEÑO ORIENTADO AL SOFTWARE COMO SERVICIO
El diseño de Software juega un papel importante en el desarrollo de software, permite al
ingeniero de software producir varios modelos del sistema o producto de que se va a construir,
dichos modelos forman una especie de plan de la solución de la aplicación.
Las actividades de diseño cubren todo tipo de decisiones, pero especialmente las relacionadas
con "cómo va a ser el software", cuáles serán sus módulos, qué tecnología utilizará, cómo se
interrelacionan los datos que va a utilizar. También forma parte del diseño el decidir qué
componentes conformarán el sistema: cuál es la función de cada uno de ellos y cómo se
comunica con los demás. A continuación se hace un breve análisis de las cuestiones
implicadas, cuando se trata de diseñar un software como servicio, principalmente lo
relacionado a las siguientes actividades:
Investigación y evaluación de tecnologías
Diseño de arquitectura
Diseño de Datos
Ingeniería de procesos de negocio
Diseño de Casos de Prueba
3.1 INVESTIGACIÓN Y EVALUACIÓN DE TECNOLOGÍAS
Es importante en esta etapa hacer investigación sobre las tecnologías que soporten las
necesidades identificadas. Un artefacto entregable puede ser un documento de investigación
acerca de plataformas PaaS, proveedores existentes, frameworks, componentes Web 2.0, etc.
3.2 DISEÑO DE ARQUITECTURA
Existen tres aspectos de arquitectura importantes que necesitan ser considerados: multi-
tenancy, es decir, hostear a varios clientes en una única instancia de la aplicación,
maximizando por ende el uso de recursos compartidos, escalabilidad y personalización
sin olvidarnos de los tradicionales (confiabilidad, rendimiento y todos los aspectos de
seguridad). Estos tres puntos de arquitectura son el núcleo de las guías de arquitectura que
estamos creando; reconocemos que los otros aspectos mencionados antes son escenciales pero
siguen siendo tratados igual que en cualquier sistema de alta disponibilidad.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 13Diseño de Sistemas Orientados a Cloud Computing - 2011
La Figura 3 muestra una arquitectura de alto nivel de una aplicación en la nube, incluyendo las
capas de plataforma e infraestructura provistas por Cloud Computing. En el nivel más alto se
encuentran las aplicaciones SaaS proporcionadas por los proveedores. La plataforma PaaS
expone componentes de soporte para estas aplicaciones (tales como seguridad, cuentas, login,
etc.), así también otros servicios como meta-datos y administración de clientes y proveedores.
La Infraestructura de software y hardware también es proporcionada por la Cloud. Sobre esta
arquitectura, las aplicaciones SaaS se desarrollan, despliegan y entregan a un número
considerable de clientes.
Clientes
Proveedores
Servicios para Consumidores
SaaS
Componentes Aplicativos
Componentes de Soporte
PaaS
Servicios de Administración
Metadatos de Tenants
Infraestructura Software
IaaS
Infraestructura de Hardware
Figura 3. Arquitectura de alto nivel de una aplicación en la nube
Por otra parte, en lo que a la arquitectura de las aplicaciones SaaS se refiere, debe tener los
atributos de diseño, que se detallan en la siguiente tabla:
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 14Diseño de Sistemas Orientados a Cloud Computing - 2011
La arquitectura soporta múltiples clientes y
Multi-tenancy
proveedores.
Existe una versión de cada aplicación y es
Versión Simple
compartida para todos los clientes.
En el mejor de los casos, cada tenant tiene su
propio dominio de información, pero
Separación Lógica de Datos almacenados en una misma base de datos.
(Actualmente se usan otras alternativas, que se
detallan mas adelante en Diseño de Datos)
Es un punto de entrada a las aplicaciones de
Contenedor de Dominio
un proveedor.
Las aplicaciones SaaS deben comunicarse
Integración de Aplicaciones
entre sí, pero mantenerse independientes.
La plataforma proporciona componentes
compartidos para las aplicaciones: seguridad y
autenticación, manejo de cuentas de usuario,
Componentes de Soporte
login, control de uso y métricas, soporte para
diferentes modelos de subscripción, entre
otros componentes importantes.
Los servicios y la estructura detrás de la nube deben estar basados en un enfoque de
arquitectura modular, basada en componentes, la cual permite la flexibilidad y reutilización.
Una arquitectura orientada a servicios (SOA) permite exponer funcionalidad empaquetada
como servicios interoperables que permiten la integración, por lo cual, agrega un ingrediente
importante al modelo que está relacionado con la integración y la interoperabilidad con
aplicaciones de terceras partes o propias. Adoptar SOA puede ser una ventaja competitiva para
el proveedor porque habilita escenarios de integración, mashups y automatización.
3.3 DISEÑO DE DATOS
Las aplicaciones como servicio tienen una característica que hace que el modelo sea
especialmente eficiente, el multitenancy. Esta es la propiedad que permite ofrecer la misma
aplicación a muchos usuarios y así distribuir el coste de la infraestructura y del mantenimiento
entre todos Técnicamente no se trata solo de ofrecer la misma aplicación, sino de realizar una
aplicación que permita con una sola instancia de la aplicación y una sola base de datos, dar
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 15Diseño de Sistemas Orientados a Cloud Computing - 2011
servicio a todos tus clientes. Desde el punto del diseño de datos se debe elegir entre las
opciones de tener una base de datos aislada, compartir la base de datos pero no las estructuras
de datos, o bien, compartir todo sin olvidar que el resultado debe ser escalable a nivel de
estructura de datos, esquemas de replicación, mantenimientos de referencias al cambiar
estructuras de datos, etc.
Existen actualmente tres distintas implementaciones multitenancy, que cumplen la condición
de dar soporte a múltiples clientes. Se parte de la base que existe una aplicación con su parte
de código y su parte de datos, donde la misma ejecución o instancia del código va a dar servicio
a todos los usuarios, a continuación se puede ver cuáles son las tres formas en que se puede
diseñar la base de datos con sus ventajas y desventajas:
Una base de datos por cada empresa o usuario: Es decir una misma instancia de la
aplicación para dar servicio a todos los usuarios pero una base de datos por cada
cliente. Esta es la opción que está más lejos del modelo SaaS y más cerca al modelo
ASP. Las tablas no necesitan ningún atributo para diferenciar si los datos pertenecen a
un cliente o a otro, pero si es necesario tener una estructura de datos que determine
qué base de datos corresponde a cada cliente.
Figura 5. Una base de datos por cliente
Ventajas:
• Un Motor de BBDD dedicado para cada usuario, por tanto no te afectan los datos y
accesos de otros clientes.
• Posibilidad de tener una máquina dedicada para los usuarios.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 16Diseño de Sistemas Orientados a Cloud Computing - 2011
Desventajas:
Desde el punto de vista del proveedor
• Más recursos humanos. Se dificulta el mantenimiento ya que cualquier modificación en
el modelo de datos (tablas) hay que replicarla en todas las bases de datos.
• Más recursos hardware. A partir de un cierto número de clientes se necesitarán más
máquinas para albergar las bases de datos.
Desde el punto de vista del cliente
• Más expuestos a errores. La replicación masiva da lugar a errores y puede afectar a los
datos de la aplicación.
• Precio alto. Requiere más recursos, más mantenimiento, lo cual incidirá en el precio.
Una base de datos con N conjunto de tablas: Es decir una misma instancia de la aplicación
para dar servicio a todos los usuarios y una sola base de datos con tantos conjuntos de
tablas como clientes existan. Esta opción se acerca más al modelo SaaS aunque sigue
siendo difícil su mantenimiento. Las tablas tampoco necesitan un atributo para diferenciar
si los datos pertenecen a un cliente a otro, y de igual forma necesitan una estructura de
datos que determine qué conjunto de tablas (esquema) pertenece a cada cliente.
Figura 6. Una base de datos con N conjuntos de tablas
Ventajas
• Menos inversión hardware que la opción anterior.
• Menos mantenimiento del hardware.
• Precio menor que la opción anterior
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 17Diseño de Sistemas Orientados a Cloud Computing - 2011
Desventajas
Desde el punto de vista del proveedor
• Más recursos humanos. Se dificulta el mantenimiento ya que cualquier modificación en
el modelo de datos (tablas) hay que replicarla en todos los conjuntos de tablas.
• En caso de fallo del motor de la base de datos no es posible dar servicio a ningún
cliente.
Desde el punto de vista del cliente
• Debido a que se comparten los mismos recursos hardware y el mismo motor de base de
datos, existe la probabilidad de pérdida de rendimiento.
• Mayor exposición a errores. La replicación masiva da lugar a errores y puede afectar a
los datos de la aplicación.
• Precio alto. Mas recursos humanos, requiere más gasto y esto incidirá en el precio.
Una base de datos con ÚNICO conjunto de tablas: Es decir una misma instancia de
aplicación y una sola base de datos con un único conjunto de tablas para dar servicio a
todos los usuarios. Esta opción es la que más se ajusta al modelo SaaS y el mayor
problema que presenta es la complejidad de la aplicación y la estructura de datos. Las
tablas necesitarán un atributo para diferenciar a que cliente pertenecen los datos.
Figura 7. Una base de datos con un único conjunto de tablas
Ventajas
• Menos recursos hardware que las opciones anteriores.
• Facilita el mantenimiento, evita la probabilidad de error por las actualizaciones de la
estructura de datos.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 18Diseño de Sistemas Orientados a Cloud Computing - 2011
• Al ser más rápido el mantenimiento, es posible tener la aplicación disponible más
tiempo.
• Menor precio que opciones anteriores.
Desventajas
Desde el punto de vista del proveedor
• Aplicación más compleja porque debe determinar el acceso a los datos correctos de
cada cliente.
• En caso de fallo del motor de base de datos no es posible dar servicio a ningún cliente.
Desde el punto de vista del cliente
• Probabilidad de pérdida de rendimiento, ya que todos los usuarios comparten los
mismos recursos hardware y el mismo motor de base de datos para todos los usuarios.
• La complejidad de la aplicación puede dar lugar a errores.
En cualquiera de las tres opciones hay que tener sumo cuidado para definir los datos,
esquemas o base de datos correcta y asegurar la confidencialidad de los mismos, es decir, que
el cliente solo pueda ver sus datos y no los de otros clientes. Por otra parte se debe tener en
cuenta que una vez elegida una opción, todo el diseño y desarrollo de la aplicación está
condicionado por la misma. Pasar después de una opción a otra requiere casi empezar desde
cero.
3.4 INGENIERÍA DE PROCESOS DE NEGOCIO
Debe permitir personalizar la aplicación a medida de distintos clientes, pero utilizando la
misma solución. La personalización no puede ser hecha mediante código personalizado sino
que necesita ser hecha mediante configuración específica de cada cliente. Contar con un
entorno rico de metadatos y de un servicio de metadatos en la arquitectura es importante.
Idealmente se trataría de compartir infraestructura (servidor IIS, servidor de Base de datos) y
utilizar metadatos para habilitar la personalización y configuración que exige una solución
multi-tenants y multi-marca.
3.5 DISEÑO DE PRUEBAS
Si bien se deben diseñar todos los tipos de prueba como para las aplicaciones tradicionales, se
debe hacer enfoque principal en los siguientes tipos de pruebas:
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 19Diseño de Sistemas Orientados a Cloud Computing - 2011
• Pruebas de integración. Pruebas importantes en cuanto a la integración con la
plataforma, con otros módulos de la aplicación y con otras aplicaciones.
• Pruebas de rendimiento. Cada aplicación tiene sus propios requerimientos de
rendimiento, en este caso, las aplicaciones SaaS tienen una fuerte dependencia en el
número de usuarios y sus especificaciones.
• Pruebas de medición de tenants. La aplicación no debiera implementar código para
logging o medición de uso. Estos componentes son responsabilidad de la plataforma
misma. El objetivo de estas pruebas es asegurar que el uso y debug de cada aplicación
es correctamente registrado y para cada tenant (cliente y/o proveedor).
• Aprobación Técnica. Consiste en correr todas las pruebas sistemáticamente y
asegurarse que la aplicación es correctamente desplegada a producción. En el caso de
actualizaciones y arreglos de defectos, la plataforma debe proporcionar mecanismos de
recuperación cuando existan fallas y se pueda regresar a versiones anteriores.
4. SOA EN LA NUBE
Como se ha visto Cloud Computing tiene características fundamentales que deben cumplir,
entre otras: elasticidad, servicios de auto aprovisionamiento (self services provisioning) e
interfaces basadas en estándares.
Por otra parte, en la nube conviven diferentes aplicaciones que deben colaborar entre sí para
obtener su mayor potencial, en la mayoría de los casos dichas aplicaciones se desarrollaron en
forma independiente aplicando diversos estándares y diferentes arquitecturas, por lo cual la
integración de las mismas suele ser una tarea compleja.
Siendo que la nube esta mas orientada al deployment y no al desarrollo, aun no hay
estándares precisos sobre cómo modelar aplicaciones en ella, los ingenieros en informática
deben diseñar aplicaciones con las bondades que brinda la nube: “servicios”, “módulos”,
“reutilización”.
Estos beneficios se pueden obtener diseñando aplicaciones de negocio en la cual la
funcionalidad aplicativa se provee a través de componentes funcionales denominados
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 20Diseño de Sistemas Orientados a Cloud Computing - 2011 servicios, acá entra en la escena de la nube, el diseño de SOA o Arquitectura Orientada a Servicios. 4.1 POR QUÉ PENSAR EN SOA? Los sistemas de información han recorrido durante su historia un camino que lleva desde los primitivos sistemas monolíticos, pasando por sistemas cliente/servidor, hasta llegar a la Arquitecturas Orientada a Servicios (SOA), en la que la funcionalidad de las aplicaciones se implementa bajo la forma de componentes reutilizables, que se invocan a través de interfaces estándar. Estos componentes –llamados servicios– pueden combinarse para crear otros servicios más complejos. Una de las principales necesidades que enfrentan hoy las empresas es la de integrar sus procesos en forma “transversal” a través de las diferentes aplicaciones, y ésta es precisamente una necesidad a la cual las arquitecturas IT anteriores casi nunca pudieron dar una respuesta completamente satisfactoria. Tradicionalmente la integración de los procesos se llevó a cabo, en algunos casos manualmente, obligando a los usuarios a conectarse a diferentes aplicaciones, o a llevar papeles de un sector de la empresa a otro, con las consiguientes inexactitudes e ineficiencias; en otros casos la lógica de integración de los procesos estaba embebida dentro del código de las aplicaciones, lo que torna complicado poder modificar ágilmente los procesos, o crear procesos nuevos reutilizando los componentes existentes. En el mundo de los negocios de hoy, las empresas necesitan tener una gran flexibilidad para poder adaptarse ágilmente a lo que un entorno muy exigente les demanda. Una empresa tendrá esa flexibilidad sólo si sus procesos de negocio están integrados de punta a punta. Por otra parte, las empresas que logren esto cubrirán mejor las demandas de sus clientes, ganarán competitividad e incrementarán en definitiva sus beneficios. El problema de las arquitecturas tradicionales reside en que, en ellas, las aplicaciones no están diseñadas para ser integradas. En esas arquitecturas las aplicaciones se diseñan generalmente como “silos verticales”, cada una de ellas pensada para un propósito específico y un alcance limitado. En muchos casos se trata de aplicaciones construidas o adquiridas en diferentes momentos históricos, por diferentes equipos de gente y en forma independiente, de modo que es natural que su integración resulte dificultosa, dicho estado resulta totalmente indeseable ya que la infraestructura tecnológica no debería inhibir sino, por el contrario, facilitar la integración de las aplicaciones y de los procesos de negocio, permitiendo además que dichos Construcción de Sistemas II Ing. V. Ledesma / Ing. A. Marín Página 21
Diseño de Sistemas Orientados a Cloud Computing - 2011 procesos reutilicen las aplicaciones existentes e incorporen también a las nuevas aplicaciones que se desarrollen en el futuro, incluso sobre diferentes plataformas. Hoy en día existe un amplio consenso en que la mejor solución para las necesidades actuales de las empresas es la Arquitectura Orientada a Servicios, ya que permite justamente crear una infraestructura tecnológica capaz de brindar la agilidad que los negocios necesitan en el mundo de hoy. Para entender como se relacionan la Cloud con SOA, es necesario entender varios conceptos de la Arquitectura Orientada a Servicios (SOA) 4.2 ARQUITECTURA ORIENTADA A SERVICIOS SOA es una manera de diseñar y construir aplicaciones de negocio en la cual la funcionalidad aplicativa se provee a través de componentes funcionales denominados servicios. Cada servicio representa una función de negocios de la empresa tal como: “obtener la información de un cliente”, “dar de baja una línea telefónica”, “dar de alta un nuevo empleado”, etc. Los servicios se comunican unos con otros a través de interfaces bien definidas, estándar, e independientes de la plataforma de hardware, sistema operativo, o lenguaje de programación en el que el servicio esté implementado. Esto permite crear aplicaciones compuestas (composite applications) simplemente combinando o ensamblando servicios más básicos. Los servicios, entonces, se comunican mediante interfaces estándares, y no ligadas a ninguna implementación particular. Dicho en otras palabras, se comportan como cajas negras, en las que están expuestas las interfaces (es decir: la forma de invocarlos y los resultados que producen), pero no la implementación interna. Esta característica se conoce como acoplamiento débil entre servicios. El beneficio del acoplamiento débil consiste en la mayor independencia entre los servicios; las modificaciones hechas en un servicio no impactan en los demás. Esto a su vez brinda mayor agilidad para implementar cambios y permite ahorrar costos de desarrollo y mantenimiento de los sistemas. El acoplamiento fuerte por el contrario, implica que los diferentes componentes de una aplicación estén íntimamente relacionados en funcionalidad y forma, lo cual los hace muy vulnerables a los cambios evolutivos, ya que cualquier modificación a uno de sus componentes termina afectando a los demás. La necesidad de contar con sistemas con poco acoplamiento surge de la necesidad ya mencionada de dotar a las aplicaciones de mayor agilidad, lo cual se basa a su vez en la necesidad del negocio de adaptarse rápidamente a su ambiente cambiante. Podría decirse que, en última instancia, el propósito de SOA es desvincular las aplicaciones de las Construcción de Sistemas II Ing. V. Ledesma / Ing. A. Marín Página 22
Diseño de Sistemas Orientados a Cloud Computing - 2011
implementaciones de los componentes que dichas aplicaciones utilizan. A esto se lo llama
“separación de las incumbencias” (“separation of concerns”). La gran ventaja de esta
separación es que permite cambiar la implementación de los componentes sin afectar a las
aplicaciones y, viceversa, modificar las aplicaciones reutilizando los mismos componentes. Es
evidente que este modelo puede darle a los negocios la flexibilidad que los sistemas
tradicionales no podían brindar.
4.3 ENTRERPRISE SERVICE BUS (ESB)
En SOA los diferentes servicios habitualmente no interactúan en forma directa unos con otros
sino que lo hacen utilizando de un Enterprise Service Bus (ESB). El ESB es un patrón
(pattern) de diseño, que representa una buena práctica de arquitectura, y que recomienda no
interconectar los servicios directamente –punta a punta– sino, por el contrario, utilizar un bus
de interconexión, que habitualmente se implementa con un middleware*1 específicamente
diseñado para tal fin.
La recomendación de no interconectar los servicios punta a punta tiene como objeto evitar una
situación tal como la que muestra la siguiente figura, que es el mapa de las interfaces entre
aplicativos tomado de un caso real (una empresa de productos electrónicos de consumo
masivo):
Depository
Vendor Setup Banks
Vendor Process Serve rs Customer Perceived
Budget Maintenance Universal Account
(I maging) NEW S oundscan VAN In-Stock
Analysis Tool Mesa Data Shows Reconcilliatio n
Printer S20-Sales
Mainte nance Polling I13- Auto Hand Scan
Custo mer Re plenishment Apps
Insertions Printer PO Order
Reports Sales
Calendar Orders Corrections
Due Dates Print Costing Ware house
General Invoice Ap p Management
Stores & Mrkts Broadcast Maintenance
Filter Interface PO
Smart Plus
Smart Plus Millennuim 3.0
Launcher Sales Posting
Cell
Tally Sheet Phones Return to
Mille nnium D01 Post Load Ve ndor Credit App
Billing
Equifax
Stock Options
Employee Solution
Resource Change Notice Software Satellite
A04 - Cust Syste m -Promo
Scheduling Refund Chks
1
DFK Ana lysis
On-line New
Hire Entry
AAS Price
Resumix P01- Marketing
Employee Support
Masterfile Bus Systems
P09 - P17
Cobra Cyb. ABC - ISP
CTS Co website Cycle Physical Tracking
Home Inventory
ACH Deliverie s
V04-Sign
Prodig y Syste m CTO
Banks - ACH and Pos to POS -
Pay Transfers
Host to AS400
Plan Administrators Communication
(401K, PCS, Life) Spec Source Stock
SKU Tracking Status Price
Counts T esting Supplie r
Intercept Sales Compliance
Employee T ax Scanning La yaways
Purchase
Spe c
Source PO
Scorecard Receiving SKU
Mkt Performance
Reactions
Poll ing Price Management Coop
Bonus/HR SKU Selection
Syste m Inv entory Info T ool
DRK
ABBX Customer Repair I35 Early Warning Planning
Tracking Syste m
Re bate SKU Rep
Transfer
SKU Purchase
Store Information Orde r Ad Expense
Monitor
PowerSuite General
Le dger
Store
Score card
Tex A Sign
Syste m
N. Count Corrections Store Budge t
Reporting
Media
Tx Merchandise
Writer Ana lysis BMP - Bus
Workspace performance Mngt
EDI
Coordinat or
Mngr Ap proval
Batch Forcastin g AIMS Journal Entry Tool Kit
Ad Me asureme nt AP
Cellular I NVENTORY CONTROL AP PS - PC INV ENTORY CO NTROL APPS - PC ACCTS REC APPS - PC
AIMS Rollover OTHER APPS - PC
Ad Reporting House
Launcher Charge s
Op. Recon
PSP File
Capital
Projects Connect 3 Cre dit
SS
In-Home
Data Warehouse Repair Connect 3 Connect 3
PDF T ransfe Reports Cash Receipts/Credit
Fixed
Warranty Assets Misc Accou nting/Finance Ap ps - PC/NT
Billing
Figura 7. Una base de datos con un único conjunto de tablas
Repair Cash Ov er/
Syste m
Short
Figura 8. Mapa de interfaces entre aplicativos
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 23Diseño de Sistemas Orientados a Cloud Computing - 2011
Un ESB provee una infraestructura de conectividad para los diferentes servicios a través de la
cual fluye la información que permite que aquellos interactúen, de modo que la arquitectura de
integración de los servicios pasa a convertirse en algo como esto:
Travel Check Check Credit Book Flight
Reservation Traveler Service Service
Process Service
Enterprise Service Bus
Hotel Flight Book Hotel Book Car
Availability Availability Service Service
Service Service
Figura 9.Arquitectura
Arquitectura de integración de servicios usando ESB
Un ESB no se limita a interconectar los diferentes servicios sino que provee además una
mediación inteligente entre lo servicios. El concepto de mediación incluye:
• El ruteo de cada requerimiento al componente o a los componentes correspondientes,
en base al contenido del requerimiento (content
(content-based routing). En algunos casos un
servicio se resolverá con único componente, pero puede haber otros casos en los que el
ESB deba invocar a una secuencia de componentes (Ej: transacciones en un
mainframe, o en SAP) para cumplir con un servicio determinado.
• El reformateo de los datos para adaptarlos a los diferentes servicios participantes; por
ejemplo, de archivo plano a XML.
• El cambio de protocolo de transporte (por ejemplo, de JMS a HTTP).
El ESB implementa entonces la lógica de integración de los servicios, no la lógica de negocios
que está íntegramente implementada en los componentes. Se puede decir también que el ESB
es el lugar dondee los servicios se “publican”. Cada vez que una aplicación o un proceso
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 24Diseño de Sistemas Orientados a Cloud Computing - 2011
necesiten invocar un servicio se lo va a “pedir” al ESB y éste se va a encargar de mediar entre
quien requirió el servicio y quien lo puede brindar realmente.
4.4 LA INFRAESTRUCTURA TECNOLÓGICA DE UNA SOA
Los procesos de negocio en el contexto de una SOA se ejecutan bajo el control de un motor o
servidor de procesos, pero existen además diversos componentes de software que facilitan la
creación de nuevos servicios, la integración de los procesos con servicios nuevos o ya existentes
y la interacción de los servicios y procesos con las personas.
Estos componentes pueden clasificarse del siguiente modo:
• Infraestructura de conectividad de servicios, que se implementa, como ya se ha dicho,
mediante un Enterprise Service Bus (ESB).
• Servicios propiamente dichos, que pueden ser brindados por:
– Nuevos componentes aplicativos, diseñados específicamente para SOA y desarrollados
por ejemplo en JEE (Java Enterprise Edition) o en .NET, entre otras posibilidades.
– Aplicativos preexistentes, también conocidos como “legacy”, que pueden integrarse a
SOA a través de adaptadores o conectores, o modificando el código mismo de los
programas que las componen.
– Servicios provistos por terceros. En las comunicaciones entre empresas se ha utilizado
históricamente una gran variedad de protocolos (EDI, RosettaNet, FTP, Web Services,
etc). Para asilar a los aplicativos y procesos de la complejidad de manejar todos esos
diferentes protocolos, y para manejar desde un lugar único cosas tales como la
seguridad y la calidad del servicio, es conveniente contar con un gateway, que provea
una interface de servicios a los aplicativos y procesos de la empresa y que se ocupe de
manejar la comunicación con los diferentes proveedores de servicios externos.
• Elementos que permitan componer servicios, que incluyen:
– Servidor de procesos: ya mencionado anteriormente.
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 25Diseño de Sistemas Orientados a Cloud Computing - 2011
– Portales web: los portales web permiten crear aplicaciones compuestas integrando
servicios en el navegador web (“integration on the glass”). Los portales permiten
además presentar de manera personalizada para cada tipo de usuario toda la
información que cada usuario necesita para llevar a cabo sus tareas, incluyendo la lista
de items de trabajo del motor de procesos. Los portales son por esta razón un elemento
esencial para dotar a los procesos de negocio, en particular a aquellos en los que existen
tareas humanas, de una gran eficiencia ya que cada persona dispondrá de la
información necesaria en forma integrada y consolidada en un único lugar.
– Integración de la información: conocida también como Federación de Datos, que
permite acceder a múltiples fuentes diferentes de datos como si se tratase de una base
de datos única y coherente, presentando además los resultados en la forma de servicios.
4.5 SOA VS CLOUD COMPUTING
Llegado este punto, se han explicado los conceptos generales de Cloud y de la arquitectura
orientada a servicios (SOA), ¿es posible concluir que se trata de lo mismo? De ninguna
manera, Cloud Computing, es un nuevo modelo de prestación de servicios y tecnología, la
misma esta orientado al deployment, es decir donde se van a ejecutar las aplicaciones, en
cambio SOA es una forma de diseñar para conseguir la flexibilidad que hoy necesitan las
organizaciones, lo lleva a cabo mediante la implementación de servicios que actúan como cajas
negras, encapsulando la funcionalidad.
No cabe duda que Cloud Computing y SOA son dos conceptos totalmente independientes y que
podrían no estar relacionados: “SOA puede existir sin estar en la Cloud” y “Cloud Computing
funciona sin SOA”, pero al unir ambos conceptos podemos obtener mayores beneficios, como
la reutilización y bajo acoplamiento, que son fundamentales para SOA y son parte
fundamental para la elasticidad y escalabilidad de servicios en la nube.
En otras palabras, se podría decir que Cloud Computing y SOA son simbióticos porque SOA es
un “habilitador” de Cloud Computing, pero a su vez Cloud Computing (en un nivel idóneo de
abstracción) es un proveedor de servicios acorde con SOA. Por ello, la relación es simbiótica en
cuanto a que SOA y Cloud Computing (“diferentes especies”) se “asocian” para que ambas
saquen provecho gracias a esa asociación
Construcción de Sistemas II
Ing. V. Ledesma / Ing. A. Marín Página 26También puede leer
