Cloud Computing Fundamentos, Diseño y Arquitectura

Cloud Computing: Fundamentos, diseo y arquitectura aplicados a un caso de estudio
1

Mster Oficial en Tecnologas de la Informacin y
Sistemas Informticos
Curso Acadmico 20102011
T!SIS "I# $! MAST!%
Cloud Com&uting' fundamentos( dise)o y
ar*uitectura a&licados a un caso de estudio
Autor' +os Manuel Ar,alo #a,arro
Tutor' Marcos -&e. San.
2 Jos Manuel Arvalo Navarro
Para Almudena,
mi mujer y mi mejor amiga.
Gracias por ayudarme a
levantarme en los fracasos
y poner mis pies en la tierra en los xitos

NDICE DE ILUSTRACIONES ............................................................................................................................. 4
LISTA DE TABLAS ............................................................................................................................................ 4
RESUMEN ...................................................................................................................................................... 6

1 MOTIVACIN .............................................................................................................................................. 7
1.1 PRESENTACIN DEL PROBLEMA .............................................................................................................................. 8
1.2 OBJETIVOS ..................................................................................................................................................... 9
1.3 METODOLOGA .............................................................................................................................................. 10
1.4 ESTRUCTURA DE LA MEMORIA ............................................................................................................................. 11
2. CONCEPTOS PREVIOS .............................................................................................................................. 13
2.1 INDEPENDENT SERVICE VENDOR (ISV) .................................................................................................................. 14
2.2 SERVICE ORIENTED ARCITECTURE (SOA) .............................................................................................................. 14
2.3 SERVICE LEVEL AGREEMENT (SLA) ...................................................................................................................... 18
3. PRINCIPIOS Y ARQUITECTURA CLOUD ....................................................................................................... 21
3.1 ARQUITECTURA DE REFERENCIA EN CLOUD COMPUTING ........................................................................ 22
3.1.1 Infraestructura como servicio (IaaS) ................................................................................................ 23
3.1.2 Plataforma como servicio (PaaS) ..................................................................................................... 24
3.1.3 Virtualizacin .................................................................................................................................. 26
3.1.4 Software como servicio (SaaS) ......................................................................................................... 27
3.2 TIPOS DE CLOUD ............................................................................................................................................ 31
3.2.1 lou! "#$lica ................................................................................................................................... 32
3.2.2 lou! "riva!a ................................................................................................................................... 32
3.2.3 lou! %&$ri!a .................................................................................................................................... 33
3.3 IMPLEMENTACIONES ........................................................................................................................................ 34
3.2.1 'mazon (e$ Services ('(S) ........................................................................................................... 34
3.2.1.1 'mazon )lastic om"ute lou! ()2) ........................................................................................... 3*
3.2.1.2 'mazon Sim"le Stora+e Service (S3) ............................................................................................ 37
3.2.2 ,icrosoft (in!ows 'zure ............................................................................................................... 3-
3.4 CLOUD COMPUTING ! SOA .............................................................................................................................. 40
4.1 ASPECTOS CLAVES EN LA ELECCIN DE IAAS "RENTE A SISTEMAS TRADICIONALES ..................................................................... 44
4.2 ASPECTOS CLAVES EN LA ELECCIN DE PAAS "RENTE A SISTEMAS TRADICIONALES .................................................................... 4#
4.3 ASPECTOS CLAVES EN LA ELECCIN DE SAAS "RENTE A SISTEMAS TRADICIONALES ..................................................................... 49
4.4 OTROS $AAS% EL CASO DEL VIRTUAL DES&TOP IN"RASTRUCTURE (VDI) ............................................................................ '1
4.' RIESGOS EN CLOUD COMPUTING ......................................................................................................................... '4
5 INTEGRACIN DE UN CASO DE ESTUDIO EN LA NUBE ................................................................................. 56
'.1 SISTEMA DE IN"ORMACIN INICIAL% GESIMED ............................................................................................................ '(
'.2 POSICIONAMIENTO DE GESIMED EN LA NUBE ............................................................................................................ '8
'.3 POSICIONAR GESIMED EN UN MODELO SAAS ............................................................................................................ '9
'.4 INTEGRACIN SOBRE IAAS ................................................................................................................................. #'
'.' AR)UITECTURA GLOBAL DEL SISTEMA E IMPLICACIONES DE LA INTEGRACIN ........................................................................... (1
6 CONCLUSIONES Y TRABAOS FUTUROS ...................................................................................................... 75
#.1 CONCLUSIONES .............................................................................................................................................. (#
#.2 TRABAJOS "UTUROS ......................................................................................................................................... ((
REFERENCIAS ............................................................................................................................................... 7!
! Jos Manuel Arvalo Navarro
/ndice de Ilustraciones
ILUSTRACIN 1 MODELO DE METODOLOGA TOP"DO#N.......................................................................11
ILUSTRACIN 2 SERVICE ORIENTED ARC$ITECTURE %12&...............................................................................1!
ILUSTRACIN 3 ACUERDO DE NIVEL DE SERVICIO.........................................................................................1'
ILUSTRACIN 4 MODELOS EN CLOUD COMPUTING......................................................................................23
ILUSTRACIN 5 ACCESO GLOBAL EN CLOUD COMPUTING %3&........................................................................2!
ILUSTRACIN 6 MODELOS DEFINIDOS POR FUNCIONALIDAD %3&..................................................................3(
ILUSTRACIN 7 MODELOS DE MADURE) EN SAAS %5&...................................................................................31
ILUSTRACIN ! ESQUEMA CLOUD COMPUTING...........................................................................................34
ILUSTRACIN ' LOGOTIPO AMA)ON #EB SERVICES %'&...............................................................................34
ILUSTRACIN 1( PLATAFORMA #INDO#S A)URE %14&...............................................3'
ILUSTRACIN 11 SERVICIOS EN #INDO#S A)URE %17&.................................................................................4(
ILUSTRACIN 12 SINERGIAS ENTRE SOA Y CLOUD COMPUTING........................................42
ILUSTRACIN 13 ARQUITECTURA DE GESIMED %12&......................................................................................57
ILUSTRACIN 14 MODELO DE NEGOCIO EN FORMULARIO #EB....................................................................63
ILUSTRACIN 15 MAS$UP GESIMEDSAAS EN MAR*ETPLACE........................................................................64
ILUSTRACIN 16 CICLO DE VIDA AMA)ON MAC$INE IMAGE %'&...................................................................66
ILUSTRACIN 17 ARQUITECTURA INTEGRACIN IAAS..................................................................................7(
ILUSTRACIN 1! ARQUITECTURA FINAL INTEGRACIN MAR*ETPLACE.........................................................73
-ISTA $! TA0-AS
TABLA 1 EEMPLOS CADAS DE SERVICIO......................................................................................................55
TABLA 2 POSICIONAMIENTO DE GESIMEDSAAS EN LA NUBE.........................................................................5!
TABLA 3 PRECIOS GESIMEDSAAS..................................................................................................................62
TABLA 4 PROCESO DE ADOPCIN SAAS........................................................................................................65
TABLA 5 INSTANCIAS EST+NDAR EN AMA)ON #EB SERVICES %'&...............................................................67
TABLA 6 PRECIOS ALMACENAMIENTO EN S3 %'&...........................................................................................6!
TABLA 7 COSTE DEL CASO DE ESTUDIO.........................................................................................................71
TABLA ! AN+LISIS DE COSTES CLOUD COMPUTING FRENTE SOLUCIN IN"$OUSE.........................................73

"
# Jos Manuel Arvalo Navarro
%esumen
$ste proyecto %in de master plantea la integraci&n y el despliegue de un sistema de
in%ormaci&n en una in%raestructura y plata%orma Cloud Computing' (e )a reali*ado un estudio de
este nuevo modelo de servicios, estudiando sus aspectos te&ricos y %undamentales, anali*ando las
implementaciones con las que a d+a de )oy podemos encontrar en el mercado para poder a%rontar
nuestros retos pro%esionales' ,e-eremos tener en cuenta los riesgos que de-eremos asumir en la
adopci&n del modelo, aportando soluciones para mitigarlos de la %orma m.s e%iciente posi-le'
/ero tam-in se anali*ar.n todas las venta0as y se tendr.n en cuenta cuando se desarrolle el caso
de estudio'
$l alcance del proyecto es reali*ar un detallado an.lisis so-re el paradigma Cloud
Computing mediante un pro%undo estudio, y una posterior validaci&n mediante la
implementaci&n de un caso de estudio detalladamente de%inido' (e detallar.n y 0usti%icar.n todas
las decisiones tomadas, as+ como los costes ocasionados de la integraci&n %rente a los costes que
supondr+a una soluci&n interna' (e detallar.n los -ene%icios introducidos y los o-st.culos
encontrados a lo largo del caso de estudio' (e anali*ar. que impacto )a tenido partir de un
sistema de in%ormaci&n orientado a servicios'
Con la reali*aci&n del proyecto se )a demostrado que se puede contar con nuevas
alternativas tecnol&gicas y nuevos modelos con los que poder o%recer servicios a nuestros
clientes llev.ndonos a %ormular preguntas tales como:
12u es y que no es Cloud Computing3
1Cloud Computing es realmente lo que necesito3
12u necesito para adoptar Cloud Computing3
12u riesgos tiene Cloud Computing3
12u impacto tiene (4A en el Cloud Computing3
5
Captulo 1:
Introduccin
1 Moti,acin
1.1 Presentacin del problema
7a realidad pro%esional en nuestro d+a a d+a en el .m-ito de la tecnolog+as de la
in%ormaci&n actualmente a la )ora de a%rontar un proyecto, -ien sea en organi*aciones o en el
.rea de investigaci&n, est. -asada en un modelo en el cu.l un cliente 8interno o e9terno: pide
soluciones al departamento ;<, 8=me )ace %alta determinado entorno para poner una aplicaci&n en
producci&n>, =necesito determinado entorno porque vamos a-rir una o%icina en una determinada
geogra%+a>, >el negocio se va a trans%ormar y necesito una plata%orma que lo soporte>:' $s un
escenario en el cu.l )ay que poner la soluci&n encima de la mesa, generalmente a medida, con
orientaci&n al cliente, la cual %inalmente se desarrolla despus del pla*o estimado 8en el me0or de
los casos:'
Cuando tenemos a pro%esionales 8cliente e9terno o interno: pidiendo una soluci&n a otros
pro%esionales 8departamento ;<: lo que se genera es una espera, ya que implica una %ase de
captura de requisitos, an.lisis y diseo de la soluci&n, por supuesto ese tiempo genera unos
costes solo por el simple )ec)o de que estamos empleando unos recursos tanto )umanos como
tecnol&gicos 8tra-a0adores, servidores, m&dems'''etc': tra-a0ando en unas tareas en el intervalo
que duran esas %ases' 7a pregunta que ca-e )acerse es: 1qu alternativas a este modelo tengo3
?na de las alternativas que en los @ltimos aos )a %lorecido al amparo de la orientaci&n a
servicios como paradigma tanto a nivel de negocio como a nivel tecnol&gico es el paradigma de
Cloud Computing' $ste paradigma propugna ser capa* de aprovisionarse con recursos ;<, de
manera directa, instant.nea en el tiempo 8en tiempo real: y con unos costes en la gesti&n que
sean casi planos' $ste proyecto se centra en la reali*aci&n de un estudio del Cloud Computing
como alternativa via-le, o-0etiva y real a los actuales modelos de servicios' Viable, porque Cloud
Computing est. a nuestro alcanceA objetiva, porque en%rentaremos Cloud Computing a otros
modelos desde el punto de vista del negocio y econ&micoA y %inalmente, real, porque se
e9perimentar. so-re un caso de estudio concreto' No se pretende 0usti%icar la me0or soluci&n o el
me0or modelo sino o%recer y adoptar el modelo Cloud Computing -a0o las premisas que lo )acen
realmente @til para poder )acer m.s sencillo nuestro d+a a d+a de negocio, es decir, anali*ar
cu.les son nuestras necesidades de negocio y en -ase a lo que nos o%rece Cloud Computing
decidir si es la me0or soluci&n y el me0or modelo para nuestro proyecto'
B
1.2 Objetivos
$l o-0etivo principal de este proyecto %in de master es estudiar en profundidad el
paradigma de Cloud Computing mediante la aplicacin a un caso de estudio real, tomando
como partida un sistema de in%ormaci&n -asado en servicios'
7a idea su-yacente a la consecuci&n de este o-0etivo es poder demostrar c&mo la
adopci&n de Cloud Computing como modelo de servicios representa una alternativa v.lida -a0o
ciertas circunstancias' /ara conseguir el o-0etivo anterior se )an de%inido los siguientes o-0etivos
parciales:
a) Realizar un estudio detallado del paradigma de Cloud Computing. /ara ello
se reali*ar.n las siguientes su-tareas:
a' $s necesario un an.lisis de los principios del paradigma de Cloud Computing
poniendo un n%asis especial en los aspectos arquitect&nicos y de negocio' $l
resultado de esta tarea ser. la especi%icaci&n de lo que se conoce como
arquitectura de re%erencia de Cloud Computing'
-' (eguidamente ser. necesario estudiar las consecuencias de adoptar este
paradigma, sus -ene%icios y riesgos asociados'
b) Aplicar los resultados obtenidos del estudio anterior a un caso de estudio
particular.. $n este caso ser. necesario completar las siguientes etapas:
a' An.lisis del caso de estudio: Cesimed' /ara poder aplicar un nuevo modelo
como es el de Cloud Computing es primordial conocer los detalles del caso de
estudio so-re el que se aplicar.n sus principios'
-' /osicionar Cesimed en un modelo (aa(: Con la intenci&n de e9pandir las
oportunidades de Cesimed es conveniente posicionarlo en un modelo de negocio
(aa(' (e implementar. una integraci&n real con una tienda de aplicaciones
8marDetplace:, mediante un previo diseo de la arquitectura'
c' <ntegrar Cesimed en una <n%raestructura como servicio: (e reali*ar. una
integraci&n real de un sistema de in%ormaci&n en una <aa(, diseando la
arquitectura como resultado de la integraci&n y se detallar.n los costes de uso de
1E Jos Manuel Arvalo Navarro
la in%raestructura compar.ndolos %rente al coste de una in%raestructura
tradicional'
1. !etodolog"a
(e )a considerado de%inir una metodolog+a de tra-a0o' /uesto que ya conocemos el
dominio del negocio 8proyecto %in de carrera:, nos )emos decantado por una apro9imaci&n algo
m.s cl.sica pero con una adaptaci&n particular a nuestras necesidades'
$n realidad m.s que metodolog+a, lo que )emos de%inido es una estrategia' $l proceso de
desarrollo de proyectos est. demasiado encorsetado a una estrategia bottom-up, tanto desde el
punto de vista del desarrollo de los proyectos tecnol&gicos como desde el punto de vista de la
inversi&n, esta apro9imaci&n aunque es v.lida, correcta, necesaria, consiste en evolucionar y
me0orar lo que tengo y lo que soy, es decir, tengo una realidad tecnolgica # lo $ue $uiero es
evolucionar% adoptar mejores pr&cticas, el pro-lema de todo eso es el tiempo que lleva, ya que
o-tener un sistema maduro, go-ernado y gestionado, implica tiempo, es%uer*o, dinero y, en
ocasiones un servicio no puede esperar tanto, ya que conseguir lo mencionado anteriormente es
un largo camino a recorrer' /or ello, se cree conveniente anali*ar para un nuevo servicio, que
modelo es el que mayor valor le va aportar a ese proceso de negocio, a esa realidad, a esa carga
de tra-a0o'
,ic)o de otro modo, al mismo tiempo que evolucionamos y me0oramos lo que somos,
anali*ar cu.les son mis retos, mis realidades de negocio y ver en cada carga de tra-a0o cu.l es el
modelo de servicio es el que me0or aplica' 'Para esta carga de trabajo aplica Cloud
Computing(% entonces vamos a ver con $ue ar$uitectura # con $u) infraestructura, pero ya
tengo muy claro que Cloud computing aplica, y que sus caracter+sticas est.n alineadas con
nuestro modelo de negocio, que el automatismo que quiero implementar es via-le, que voy a
o-tener un retorno de la inversi&n, y a partir de ese punto ya )a-laremos de tecnolog+a'
$stas conclusiones nos )an llevado a adoptar una estrategia -asada en FottomG?p y ;opG
,oHn com-inadas, es decir )emos evolucionado y me0orado nuestro sistema de partida, pero a la
ve* )emos anali*ado que modelo es el que m.s valor le aporta y lo )emos atacado directamente'
11

Ilustracin 1 Modelo de metodolog+a topGdoHn
$sta metodolog+a est. muy orientada al caso pr.ctico de este proyecto' Cada uno de estos
)itos se )a llevado a ca-o, aunque no ello no ser+a posi-le si no )iciramos un estudio previo y
en pro%undidad del paradigma de Cloud Computing.
$n primer lugar )emos detectado las necesidades de nuestro sistema y )emos de%inido un
posicionamiento claro de lo que queremos o-tener de Cloud Computing' /osteriormente )emos
de%inido las cargas de tra-a0o que van tener lugar en este proyecto, en este caso la carga de
tra-a0o es Cesimed' A continuaci&n se )an seleccionado los modelos en -ase a nuestro
posicionamiento y )emos estudiado que proveedores nos o%recen soluciones a nuestras
necesidades' ?na ve* que sa-emos el punto de partida y a donde queremos llegar, detectamos los
gaps' /osteriormente se )a intentado )acer un c.lculo de costes y retorno de la inversi&n de
nuestro nuevo sistema' /or @ltimo se )a esta-lecido una )o0a de ruta, que en nuestro caso de
estudio )a signi%icado el d+a a d+a de tra-a0o en este proyecto'
1.* +structura de la memoria
$ste /royecto Fin de Master se estructura en " cap+tulos, cuyo contenido es el siguiente:
$l presente captulo presenta el pro-lema y la motivaci&n que se va a a-ordar
con la reali*aci&n de este /royecto Fin de Master, los o-0etivos que se esperan cumplir y la
estrategia y metodolog+a de tra-a0o seguida'
$l segundo captulo e9plica los conceptos previos necesarios para la correcta
compresi&n de las tecnolog+as utili*adas, tanto los est.ndares empleados, como las nuevas
tecnolog+as introducidas'
$n el tercer captulo se descri-en los %undamentos en los que se -asa el modelo
Cloud Computing, tanto desde el punto de vista te&rico como desde el punto de vista
tecnol&gico' (e detalla la arquitectura de re%erencia y se reali*a una an.lisis de dos de los
proveedores de Cloud m.s importantes en el mercado actualmente, por @ltimo en este
cap+tulo se estudia la relaci&n entre (4A y Cloud Computing'
$n el cuarto captulo se e9plican los aspectos %undamentales para sa-er tomar
decisiones a la )ora de elegir este nuevo modelo de servicios, los -ene%icios %rente a sistemas
tradicionales y como a-ordar los riesgos aadidos'
$n el quinto captulo se aplican los conceptos vistos anteriormente a un caso de
estudio concreto y real, se 0usti%icaran los -ene%icios introducidos en nuestro nuevo sistema,
los o-st.culos encontrados, as+ como la arquitectura resultante de )a-er adoptado Cloud
Computing'
$n el sexto captulo se anali*an las conclusiones o-tenidas en el proyecto y los
tra-a0os %uturos propuestos'
/or @ltimo se incluye una bibliografa donde se enumeran las %uentes de
in%ormaci&n empleadas para el desarrollo y documentaci&n del presente proyecto'
1
Captulo 2:
Conceptos previos
21 Conce&tos &re,ios
1! Jos Manuel Arvalo Navarro
/ara una completa comprensi&n del tra-a0o reali*ado en este proyecto de %in de master es
necesario conocer previamente algunas de las caracter+sticas de las tecnolog+as y apro9imaciones
utili*adas en el proyecto'
2.1 ,ndependent -ervice .endor /,-.)
?n <(I es un trmino empleado para )acer re%erencia a empresas especiali*adas en
comerciali*ar con so%tHare de distintos segmentos, es decir, )ay <(IJs para so%tHare sanitario,
seguridad, o%im.tica etc' Normalmente un <(I %a-rica y distri-uye so%tHare que %unciona en
varios sistemas operativos, aportando as+ mayor valor a su cliente K5L' $l motivo de introducir
este concepto en este cap+tulo, es que, anteriormente a estas entidades sencillamente las ve+amos
en %orma de comercial intentando vendernos un producto, es decir una ca0a con un n@mero
determinado de licencias a un coste determinado'
$stas entidades est.n plante.ndose actualmente una nueva estrategia de negocio y son
pie*a clave en el modelo de negocio (o%tHare as a (ervice 8(aa(: y aunque vigilan que este
modelo les proporcione un verdadero retorno de la inversi&n 8M4<:, parece ser la tendencia
actual, los <(IJs con%ormar.n y aportar.n valor a los ecosistemas (aa(, algunas de las
caracter+sticas que -uscan est.n alineadas con (aa('
7os proveedores de software independientes 8<(I: pueden crear e implantar
r.pidamente aplicaciones (aa( en alguna plata%orma 8li-re o propietaria:, que sea capa* de
o%recer una @nica plata%orma integrada tanto para implantaciones in situ como -asadas en la
=nu-e>'K5L
7a idea es que los <(I tam-in pueden ofrecer licencias para aa de manera
mensual aprovec!ando el modelo de licencias' $l modelo de licencia permite a los <(I escalar
sus inversiones en so%tHare con%orme cre*ca su negocio'
2.2 -ervice Oriented Arc0itecture /-OA)
Arquitectura 4rientada a (ervicios 8(4A:, es un marco conceptual para integrar procesos
1"
de negocios soportados en tecnolog+a segura a travs de componentes desarrollados -a0o
est.ndares internacionales que pueden ser reGutili*ados y com-inados para adaptarse a los
cam-ios de prioridad del negocio' -OA es una ar$uitectura desacoplada de componentes de
soft1are $ue proveen funciones espec"ficas /proveedor) # $ue pueden ser invocadas por otros
componentes /consumidor) independientemente de la plataforma en $ue se encuentren ambos'
Kseg@n re%' 1EL
G 7os -ene%icios que puede o-tener una organi*aci&n que adopte (4A son:
G Facilidad para evolucionar a modelos de negocios -asados en terceri*aci&n'
G Facilidad para a-ordar modelos de negocios -asados en cola-oraci&n con otros
entes 8socios, proveedores:'
G /oder para reempla*ar elementos de la capa aplicativa (4A sin disrupci&n en el
proceso de negocio'
G Facilidad para la integraci&n de tecnolog+as dis+miles'
G $n (4A los proyectos son transversales a-arcan distintas .reas, y distintas
aplicaciones, siguiendo el %lu0o transversal de los procesos de negocio de las
compa+as'
$n (4A las soluciones se comparten, y se construyen para que los pr&9imos proyectos se
vean -ene%iciados aplicando una serie de principios que se descri-en a continuaci&n'
a: 74( ($MI<C<4( (4N M$?(AF7$(
"# anima a que los servicios sean reusables, a pesar de que la reusa-ilidad sea
propiamente un requisito e9igi-le, aplicando est.ndares de diseo como los ya comentados
8NM7, N(,, O(,7 etc': convierten a los servicios en potencialmente reusa-les y la
oportunidad de adaptarse c&modamente a los cam-ios %uturos o cam-ios en los requisitos con
menos es%uer*o' /ero se entiende reusa-ilidad tam-in en el sentido =entreGaplicaciones> es decir
entre entornos )eterogneos, por ello podemos decir que va m.s all. del concepto de
reusa-ilidad que dicta la orientaci&n a o-0etos' 7os mensa0es pueden incluir metaGdatos en la
ca-ecera, para ayudar a los servicios a ser m.s genricos y por lo tanto m.s reusa-les'
1# Jos Manuel Arvalo Navarro
-: 74( ($MI<C<4( C4M/AM;$N ?N C4N;MA;4 F4MMA7
$l contrato de un servicio consiste en:
G $ndpoint del servicio
G 4peraciones del servicio
G $ntrada y salida de las operaciones de cada servicios
G Meglas caracter+sticas de cada servicios y sus operaciones
G $stos contratos se de%inen mediante est.ndares tales como, N(, y O(,7'
c: 74( ($MI<C<4( ;<$N$N FAJ4 AC4/7AM<$N;4
Nadie puede predecir como un entorno <; puede evolucionar, como las aplicaciones
crecer.n, se integrar.n o ser.n reempla*adas, los servicios son capaces de soportar estos cam-ios
de-ido a que el estar desacoplados es una condici&n para que un servicio tenga conocimiento de
otro servicio, aunque la l&gica su-yacente, esto se alcan*a a travs del uso de contratos de
servicio que permiten interactuar -a0o unos cierto par.metros K1EL'
d:' 74( ($MI<C<4( AF(;MA$N 7A 7PC<CA (?FQAC$N;$
$ste principio es el que permite a los servicios a actuar como ca0as negras,
ocultando los detalles al resto del mundo' $l alcance de la l&gica representada por un servicio
est. in%luenciado signi%icativamente por el diseo de sus operaciones y su posici&n en un proceso
concreto' No )ay l+mite de cuanta l&gica puede representar un servicio, este mismo podr+a estar
diseo para reali*ar una tarea simple u una tarea m.s comple0a o puede ser la puerta de entrada
para una soluci&n autom.tica entera' 7a granularidad de las operaciones est. +ntimamente
relacionada con la naturale*a de la %uncionalidad que e9pone el servicio K1EL'
e:' 74( ($MI<C<4( ($ /?$,$N C4M/4N$M
?n servicio puede representar cualquier rango de l&gica de cualquier tipo de
%uente, incluyendo otros servicios, la principal ra*&n para implementar este principio es para
asegurar que los servicios son diseos para que participen como miem-ros e%ectivos en la
15
composici&n de otro servicio 8si ello %uera requerido:' ?na e9tensi&n de este concepto en (4A,
es el concepto de 4rquestaci&n, cuando un servicio es controlado por otro servicio padre que
compone a los participantes del proceso, aunque so-re este concepto )a-laremos m.s adelante
K12L'
%:' 74( ($MI<C<4( (4N A?;PN4M4(
7a autonom+a requiere que el rango de l&gica e9puesta por un servicio e9ista dentro de
una %rontera e9plicita, esto permite al servicio autoGgo-ernarse, ya que elimina dependencias con
otros servicios, esto no quiere decir que el servicio tenga total permiso y e9clusividad so-re la
l&gica que encapsula, si no que est. garanti*ado que en tiempo de e0ecuci&n, el servicio toma el
control de la l&gica que encapsula K12L'
$9isten dos niveles de autonom+a en los servicios:
Autonom"a a nivel de servicio. 7a %rontera del servicio es distinta para cada uno, pero el
servicio podr+a compartir la l&gica que su-yace y a-strae, por e0emplo, un servicio que encapsula
el sistema legado como pueda ser los main%rame de los -ancos, o tam-in llamados servicios
Hrapper, puede que tenga que compartir la l&gica con otros clientes del sistema que encapsula'
Autonom"a Pura. 7a l&gica encapsulada es de total control del servicio, suele ser
)a-itual cuando esta l&gica es creada de cero para dar soporte a las operaciones del servicio'
g:' 74( ($MI<C<4( N4 ;<$N$N $(;A,4
7os servicios de-en minimi*ar la cantidad de in%ormaci&n que ellos gestionan y la
duraci&n que la mantienen, este principio asegura la reusa-ilidad ya que los servicios ser.n m.s
generales y promueve la escala-ilidad, cuanto mayor estado se mantenga, mayor es el
procesamiento que se de-e reali*ar tal y como muestra la ilustraci&n 2'

Ilustracin $ (ervice 4riented Arc)itecture K12L
2. -ervice 2evel Agreement /-2A)
?n acuerdo de nivel de servicio o -ervice 2evel Agreement, tam-in conocido por las
siglas #% o &#, es un contrato escrito entre un proveedor de servicio y su cliente con o-0eto
de %i0ar el nivel acordado para la calidad de dic)o servicio K1L' $l (7A es una )erramienta que
ayuda a am-as partes a llegar a un consenso en trminos del nivel de calidad del servicio, en
aspectos tales como tiempo de respuesta, disponi-ilidad )oraria, documentaci&n disponi-le,
personal asignado al servicio, etc' 3&sicamente el -2A define la relacin entre ambas partes4
proveedor # cliente. ?n (7A identi%ica y de%ine las necesidades del cliente a la ve* que controla
sus e9pectativas de servicio en relaci&n a la capacidad del proveedor, proporciona un marco de
entendimiento, simpli%ica asuntos complicados, reduce las .reas de con%licto y %avorece el
di.logo ante la disputa'
5ambi)n constitu#e un punto de referencia para el mejoramiento continuo, ya que el
poder medir adecuadamente los niveles de servicio es el primer paso para me0orarlos y de esa
%orma aumentar los +ndices de calidad'
?n (7A se negocia entre dos partes donde una de ellas es el cliente y la otra un
proveedor de servicios' $stos acuerdos pueden estar vinculados legalmente, o ser un contrato
in%ormal 8relaciones interGdepartamentales:' 7os contratos entre los proveedores de servicios y
una tercera parte son )a-itualmente y de %orma incorrecta, llamadas tam-in (7A, aunque el
nivel de servicio ya )a sido de%inido por el cliente inicial y por lo tanto el acuerdo entre terceras
partes no es m.s que un contrato K1L'
1B
Ilustracin ' Acuerdo de nivel de servicio'
2os A6- definen un punto de entendimiento com7n sobre servicios% prioridades%
responsabilidades # garant"as' Cada .rea de servicio de-e tener un (7A de%inido, que
comprenda los niveles de disponi-ilidad, servicio, rendimiento u otros atri-utos del servicio,
como la %acturaci&n' $l nivel del servicio tam-in puede ser especi%icado como objetivo y
mnimo, de %orma que los usuarios puedan sa-er que esperar 8m+nimo:, mientras se o%rece un
o-0etivo que muestra el nivel de rendimiento' $n algunos contratos pueden %igurar
penali*aciones en caso de incumplimiento de los (7A' $s importante remarcar que los acuerdos
)acen re%erencia a los servicios que reci-e el usuario, pero no como el proveedor o%rece ese
servicio'
7os (7A se )an utili*ado desde %inales de los aos 6E por parte de operadores de
telecomunicaciones como parte de sus contratos con clientes empresariales' $sta pr.ctica se )a
e9tendido )asta tal punto que actualmente es )a-itual que un usuario %irme un contrato con un
proveedor de servicios que incluya una serie de (7A para pr.cticamente todos los mercados'
7os departamentos de grandes corporaciones )an adoptado tam-in el sistema de
acuerdos de nivel de servicio respecto a los clientes internos, departamentos de la misma
organi*aci&n ya que mediante este sistema se logra me0orar la calidad del servicio'
2os -2A est&n% por su naturaleza% basados en los resultados del servicio recibido por el
usuario como elemento del acuerdo' 7as organi*aciones tam-in pueden de%inir y especi%icar el
sistema por el que el servicio de-e ser cumplido mediante una especi%icaci&n 8especi%icaci&n del
nivel de servicio:' $ste tipo de acuerdo reci-e el nom-re de input SA, aunque este tipo de
acuerdo )a quedado o-soleto ya que las organi*aciones permiten a los proveedores seleccionar el
mtodo de cumplimiento de los acuerdos'
7os acuerdos de nivel de servicio pueden contener un alto n@mero de par.metros con sus
correspondientes o-0etivos de nivel de servicio' ?n caso )a-itual es un service des!' 7os
par.metros designados )a-itualmente para estos casos incluyen K2L:
#(# 8Abandonment "ate Agreetment o ratio de a-andono:: /orcenta0e de llamadas
a-andonadas mientras espera-an reci-ir atenci&n tele%&nica'
## 8Average Speed to Ans#er o tiempo medio de atenci&n:: ;iempo medio
normalmente medido en segundos, utili*ado para que el service des! responda la
llamada'
)* 8$ime Service %actor o %actor del tiempo de servicio:: /orcenta0e de llamadas
respondidas en un pla*o de tiempo determinado, por e0emplo 6ER en 2E segundos'
*+, 8%irst &all "esolution o resoluci&n en la primera llamada:: /orcenta0e de
llamadas reci-idas que pudieron ser resultas sin necesidad de una segunda llamada'
)#) 8$urn Around $ime o tiempo de respuesta:: ;iempo utili*ado para completar
una tarea determinada'
7os acuerdos de disponi-ilidad son otro tipo de par.metro muy )a-itual utili*ado en los
servicios como servidores dedicados' Algunos acuerdos )a-ituales incluyen un porcenta0e,
tiempo de operaci&n de la red, tiempos de mantenimiento, etc'
21
Captulo 3:
Principios y arquitectura Cloud
21 3rinci&ios y ar*uitectura Cloud
.1 Ar$uitectura de referencia en Cloud Computing
Cloud Computing es un nuevo modelo de prestaci&n de servicios, no es una nueva
tecnolog+a per se, este nuevo modelo est. claramente orientado a la escalabilidad, es decir, poder
atender una demanda muy %uerte en la prestaci&n de un servicio, pero de manera mu# directa%
inmediata en el tiempo% con un impacto en la gestin # en el coste $ue es casi plano% esta
orientacin a la escalabilidad lo $ue provocar& es $ue el usuario final perciba $ue todo
funciona% todo va r&pido% todo es f&cil # por lo tanto su e8periencia como usuario es muc0o
m&s gratificante'KL A pesar de que no es una nueva tecnolog+a, es conveniente e9plicar los
%undamentos tecnol&gicos que los proveedores de Cloud est.n tomando com@nmente' Como
principios tecnol&gicos es necesaria una %uerte capa de virtualizacin de in%raestructura
8servidores, almacenamiento, comunicaciones etc':' ?na capacidad mu# avanzada en cuanto a
aprovisionamiento de recursos <;, or$uestacin de esos recursos y una orientacin a servicios,
dir+a que "# es el alma de Cloud Computing y nos permitir. dar esa escala-ilidad tan agresiva,
por ello se implementar. tam-in una elasticidad, tanto en el modelo como en la in%raestructura'
/or @ltimo es muy importante destacar la necesidad de una estandarizacin de los servicios,
cuando m.s estandari*ada sea nuestra in%raestructura, m.s sencillo ser. todo K"L'
Como podis ver, no )ay nada nuevo, la @nica novedad es el nivel de e9igencia que le
pediremos a ese entorno de computaci&n'
$ste cap+tulo descri-e algunos de los di%erentes modelos de Cloud Computing
categori*ados como un con0unto de modelos de servicios' 4tro modo de verlo ser+a mediante
capas so-re las cuales podr+an desplegarse y construirse aplicaciones distri-uidas' $stas capas,
principalmente son, in%raestructura, plata%orma y so%tHare, con una gran capa de virtuali*aci&n y
protocolos de comunicaci&n'
2

Ilustracin - Modelos en Cloud Computing
3.1.1 I,-./012.3423./ 4565 10.78485 9I//S:
<n%raestructura como servicio podr+a de%inirse como un modelo de servicios de
computaci&n, estos servicios se podr+an utili*ar para resolver nuestras necesidades
computacionales sin l+mites de escala-ilidad de nuestros despliegues' (olo pagar+amos por lo que
usamos y solo cuando lo necesitemos'
,aa- es un modelo de servicio en el cu&l el 0ard1are est& virtualizado en la nube 9:;'
$n este particular modelo, el proveedor del servicio provisiona servidores, almacenamiento,
redes, y as+ sucesivamente' $sta manera de ver una in%raestructura pro%esional rompe con todos
los moldes, ya que podr+amos tener desde un pequeo negocio a una gran empresa en un corto
pla*o' 7a adopci&n de este tipo de servicios est. siendo empu0ada actualmente gracias a una
multitud de startups que )an comen*ado a emprender en estos tiempos de crisis y que no se
pueden permitir tener su propio datacenter o una in%raestructura 'n(ouse'
7os desarrolladores en este modelo encuentran una manera din.mica y %le9i-le de
tra-a0ar, ya que interact@an con la <aa( a travs de servidores virtuales, almacenamiento virtual,
generalmente se generan instancias de estas m.quinas virtuales a golpe de rat&n desde un portal,
normalmente He-, en ese primer momento lo que o-tienen es un =green field> dispuesto a ser
personali*ado para que la soluci&n sea completada, el acceso y la interaccin de la aplicacin
con la ,aa- suele ser a trav)s de -OA # contratos de servicios% puede ser mediante <-=2 o
mediante servicios R+-5. ?n e0emplo de una in%raestructura como servicio es Ama*on Oe-
(ervices, cuyos servicios incluyen, almacenamiento, in%raestructura de redes, m.quinas virtuales,
y tienen estos servicios replicados a lo largo del mundo 8<rlanda, (ingapur, $ste y 4este de
$$??: aunque se entrar. en detalle so-re este proveedor m.s adelante'
<aa( est. dirigido a cualquier empresa que desee delegar la implantaci&n de sus sistemas
so%tHare y aplicaciones en la in%raestructura )ardHare de un proveedor e9terno 8%en&meno
conocido tradicionalmente como )osting: o que requiera de servicios de almacenamiento
e9terno, copias de seguridad de sus datos, c.lculos comple0os que requieran so%tHare de elevadas
prestaciones, etc' $l proveedor les permitir. gestionar dic)os sistemas en un entorno virtuali*ado
K"L'
As+, los proveedores de servicios son los propietarios de las m&$uinas f"sicas, y las
o%recer.n como servicio a los usuarios a travs de entornos que les permitan gestionarlas, por
e0emplo una p.gina Oe- para el control de las m.quinas'
3.1.2 P;/2/-5.6/ 4565 10.78485 9P//S:
?na plata%orma como servicio 8/aa(: es un modelo de servicio que se sit@a por encima
de <aa( en cuanto a nivel de a-stracci&n de los recursos <;' +ste modelo propone un entorno
soft1are en el cu&l un desarrollador puede crear # customizar soluciones dentro de un
conte8to de 0erramientas de desarrollo $ue la plataforma proporciona 9;' 7a plata%orma
puede estar -asada en un lengua0e espec+%ico, varios o %rameHorDs de desarrollo'
+n un modelo Paa- los clientes pueden interactuar con el soft1are para introducir o
recuperar datos, reali*ar acciones etc', pero no tienen responsabilidad de mantener el 0ard1are,
el so%tHare o el desarrollo de las aplicaciones, solo se tiene responsa-ilidad de la interacci&n con
la plata%orma K!L' ,ic)o de otro modo, el proveedor es el responsa-le de todos los aspectos
operacionales' A menudo la plata%orma o%rece )erramientas de desarrollo y despliegue de
aplicaciones como por e0emplos OindoHs A*ure y su integraci&n a travs de Iisual (tudio, es
solo un e0emplo, la idea es que se puedan soportar est.ndares de desarrollo tales como, S;M7,
C((, NM7, Java(cript etc'
2"
7as plataformas como servicio vienen a suponer que el desarrollador de aplicaciones
He- se olvida de almacena0e de %ic)eros, de gesti&n de la -ase de datos, de -alanceo entre
m.quinas, de anc)o de -anda, de escala-ilidad, de picos de demanda, de esta-ilidad, de tocar una
m.quina servidor''' en de%initiva, la plata%orma so-re la que construyes tu aplicaci&n He- ya no
es cosa tuya, es del servicio que contratas y que pagas religiosamente'
Concentrarte en tu aplicacin # a0orrar costes% son las dos ventajas inmediatas de las
plataformas como servicio' No s&lo porque vendan almacenamiento y anc)o de -anda m.s
-arato que un pequeo proveedor, sino porque tam-in adquirir el conocimiento para montar
arquitecturas que escalen cuesta muc)o dinero 8o muc)os aos de es%uer*o, aunque el rol de
administrador de sistemas va a cambiar muc0o si se impone como tendencia)' /or supuesto
tienen sus peros, como comentamos en Ttu aplicaci&n so-re He- servicesT: depender de un
7nico proveedor 8algo con lo que tener muc)o cuidado, diseando la aplicaci&n para tener poco
acoplamiento y pro-.ndola tam-in siempre en un servidor de toda la vida: y comerte tam-in
sus ca+das, aunque se anto0a impro-a-le que por uno mismo se consiga la disponi-ilidad de
Ama*on o Coogle'
$l movimiento de estos dos gigantes de la He- 8en el mercado de las aplicaciones como
servicio tam-in est. (ales%orce con Force'com o Joyent: es una luc)a por el rol por el que
siempre )a apostado Microso%t con todas sus %uer*as4 ser la plataforma sobre la $ue otros
constru#en sus aplicaciones, tanto en el escritorio como en el lado del servidor'
/or ello, para sa-er si realmente estamos ante una autntica plata%orma como servicio se
de-en dar las siguientes caracter+sticas:
.n entorno de desarrollo basado en un navegador G si tienes que instalar algo en tu
computadora para desarrollar aplicaciones, entonces no es /aa('
/espliegue transparente !acia el entorno de e0ecucin G idealmente, el
desarrollador de-er+a poder desplegar su aplicaci&n /aa( con un solo clicD' (i )ay
que )a-lar con alguna persona para instalar la aplicaci&n, entonces no es /aa('
1erramientas de monitoreo 2 gestin G aunque las soluciones -asadas en nu-es son
muy convenientes en cuanto a costos, puede resultar complicado gestionarlas y
escalarlas sin -uenas )erramientas' (i )ay que construir o agregar una )erramienta de
monitoreo propia para poder escalar la aplicaci&n, entonces no es /aa('
*acturacin basada en el uso G lo que )i*o que /aa( %uera popular es que evita
pagar por adelantado' (i no puedes pagar con la tar0eta de crdito -as.ndote en el uso
que )aces de la plata%orma, entonces no es /aa('
3.1.3 V8.23/;8</48=,
Como se )a mencionado anteriormente, es muy importante disponer de una %uerte capa
de virtuali*aci&n en la in%raestructura para ser capaces de responder a la demanda con una
agresiva escala-ilidad' 7a idea de la virtuali*aci&n es poder crear servidores virtuales,
almacenamiento virtual, redes virtuales y qui*.s alg@n d+a aplicaciones virtuales, es decir un pool
de recursos' +sta abstraccin es clave en Cloud Computing #a $ue permite compartir # acceso
ubicuo 9*;' /ara crear sistemas de )ardHare virtual, en ocasiones se usan lo que se denomina
como )ipervisores,
?n 0ipervisor o monitor de m&$uina virtual 8virtual mac)ine monitor: es una
plata%orma que permite aplicar diversas tcnicas de control de virtuali*aci&n para utili*ar, al
mismo tiempo, di%erentes sistemas operativos 8sin modi%icar o modi%icados en el caso de
paravirtuali*aci&n: en una misma computadora' $s una e9tensi&n de un trmino anterior,
=supervisor>, que se aplica-a a Dernels de sistemas operativos KL'
7a virtuali*aci&n consiste en asignar un nom-re l&gico a un recurso %+sico, estos recursos
se gestionan %.cil y din.micamente ya que se reali*a un mapeo entre los recursos %+sicos y
l&gicos, estos mapeos pueden ser cam-iados din.micamente de una %orma muy e%iciente,
siempre a travs de las )erramientas y productos que nos o%recen los proveedores e9pertos como
IMOAM$' Algunas de las caracter+sticas de la virtuali*aci&n son:
Acceso: ?n cliente puede acceder a un servicio Cloud desde cualquier geogra%+a'
Aplicaci&n: ?n Cloud tiene m@ltiples instancias de la aplicaci&n y peticiones directas
a una de las instancias -asadas en condiciones'
C/?: (e pueden crear particiones dentro de los ordenadores como un con0unto de
m.quinas virtuales que se e0ecutan dentro de ese ordenador' Alternativamente se
puede introducir un -alanceador para repartir cargas'
25
Almacenamiento: A menudo se reali*a una replicaci&n para conseguir redundancia'
'.1.- oftware como servicio 3aa4
+l modelo de servicio m&s completo es a$u)l $ue ofrece el soft1are # el 0ard1are
como un servicio conjunto 9;, es decir, (aa( provee la in%raestructura, so%tHare, soluci&n y toda
la pila de aprovisionamiento como un servicio glo-al'
(o%tHare as a (ervice 8(aa(: se puede descri-ir como so%tHare que est. desplegado en un
servicio de )osting y puede ser accedido globalmente a travs de internet mediante navegador,
m&vil, ta-let, etc' Q donde todos los aspectos $ue no sean la propia interaccin con la
aplicacin son transparentes al usuario% $n el modelo (aa(, los usuarios pagan por el uso del
servicio mediante cuotas de suscripcin, v.lidas por un determinado per+odo de tiempo, como
en el caso de un alquiler, las caracter+sticas %undamentales de este modelo se pueden resumir en:
$l so%tHare est. disponi-le glo-almente a travs de internet y -a0o demanda'
$l modelo de su-scripci&n suele ser mediante licencias o -asado en uso y es %acturado
por mensualidades de %orma recurrente'
;odo lo relativo a operaciones es responsa-ilidad del proveedor
7as actuali*aciones, me0oras, evoluciones o parc)es en el aplicativo, de-e ser siempre
transparente al usuario y por supuesto no de-e )acer ning@n tipo de con%iguraci&n'
(aa( soporta m@ltiples usuarios generalmente con un modelo multiGtenant'

Ilustracin 5 Acceso glo-al en Cloud Computing KL
$ste modelo de servicios normalmente pretende llegar a pequeas y medianas empresas
8/QM$(: y a veces a usuarios individuales, de0ando para las grandes empresas un modelo
-asado en I,< 8Iirtual ,esDtop <n%raestructure: del que )a-laremos m.s adelante' $l acceso
suele ser a travs de un portal o de un CM( He-, que puede ser en a-ierto o -ien est. sucinto a
una su-scripci&n previa de otro servicio en la compa+a que o%rece (aa( 8A,(7, l+nea m&vil,
'etc':' ,ic)o portal puede ser muy variado, pero generalmente contiene las aplicaciones que )as
comprado previamente con un acceso mediante mas)ups' Q por otro lado un cat.logo de
aplicaciones que se o%recen, de a)+ en adelante el portal puede ser tan avan*ado como se quiera
pero siempre ser. el punto de acceso y uso a los servicios'
7os proveedores que desarrollan portales para )a-ilitar (aa( normalmente tienen tres
sistemas b&sicos que desarrollar' /or un lado un potente sistema de billing # facturacin, tanto
para soportar el comple0o modelo de su-scripci&n por uso, como los modelos de promociones,
generaci&n de reportes y -usiness inteligence' /or otro lado, el siguiente su-sistema clave, es el
de autenticacin% donde generalmente se implementa un sistema basado en single sign on que
se suele comunicar con los sistemas CMM de las compa+as para las que se )a-ilita el (aa( o
-ien con nuestro propio sistema de gesti&n de cliente si el portal (aa( es propiedad nuestra' /or
@ltimo es necesario un -uen sistema de integracin de ,-.>s% el valor al portal (aa( se lo dar.n
las aplicaciones que tengan, por ello cuanto m.s %le9i-le y din.mica sea nuestra A/< de
integraci&n de aplicaciones, m.s r.pido ser.n o%recidas a los clientes y por lo tanto nuestro
retorno de la inversi&n ser. mayor en menos tiempo'
2B
No se puede aca-ar este cap+tulo sin antes e9plicar algunos aspectos %undamentales de
cara al cliente que va a consumir los servicios (aa(' ,esde el punto del cliente que va a adquirir
los servicios de una aplicaci&n o%recida como servicio, e9isten una serie de requisitos m+nimos
necesarios que una (aa( de-e o%recer:
Rendimiento.? ?na (aa( de-e o%recer un rendimiento m+nimo y acepta-le para que
sea atractiva su adquisici&n' $l pro-lema aqu+ es de%inir m+nimo y acepta-le y aunque
es un concepto su-0etivo puede ser medi-le en tiempos de respuesta en el acceso a los
datos, de e0ecuci&n los procesos de negocio, de comunicaci&n a la propia aplicaci&n
8delay producido por el alo0amiento geogr.%ico de esta:, etc'
Acuerdo de 6ivel de -ervicio /en ingl)s -ervice 2evel Agreement) .? $l <(I de la
aplicaci&n (aa( de-e proveerte de varios niveles de servicio al que los cliente pueda
ad)erirse' Sa-r. clientes que necesiten su aplicaci&n disponi-le 6U" 8" d+as a la
semana, 6 ): y )a-r. que clientes que necesiten 2! N 5' $l <(I de-er. instalar en sus
sistemas los mecanismos necesarios para poder o%recer este tipo de acuerdos, esto es,
-acDup, cluster de alta disponi-ilidad de datos y aplicaci&n, etc'
Privacidad en las comunicaciones.? ,e-ido a la importancia de los datos que puedan
al-ergar las aplicaciones en necesario que la comunicaci&n que se reali*a a travs de
<nternet sea segura, esto es, la comunicaci&n de-e reali*arse a travs de )ttps u otra
%orma de comunicaci&n que asegure la privacidad de las comunicaciones'
Privacidad de los datos.? ,e igual %orma el <(I de-e asegurar que los datos estn
seguros y accesi-les @nica y e9clusivamente por el dueo del dato' $sto de-e ser
especialmente perseguido en la aplicaciones multitenant 8 nivel y ! de maduraci&n:'
!onitorizacin de la aplicacin.? $l cliente de-e sa-er de alguna %orma que es lo que
ocurre en su aplicaci&n, por e0emplo: quin accede, a qu procesos, a qu datos, etc'
$sto es o-ligado cuando el pago por el uso de la aplicaci&n se reali*a a travs de
conceptos como )oras de utili*aci&n de la aplicaci&n, consumo de espacio de disco, o
cualquier otra %orma que sea varia-le'
Acceso de a los datos.? $l resto de la aplicaciones de la organi*aci&n de-en acceder a
travs de A/<s o de Oe- (ervices , a los datos y l&gica de negocio que se utili*an y
genera por el uso de la (aa(, so-retodo, en clientes que tengan adoptado la
E Jos Manuel Arvalo Navarro
arquitectura (4A en su sistema de in%ormaci&n'
Cuando nos en%rentamos a elegir qu aplicaci&n (aa( queremos que cu-ra cierta
%uncionalidad para nuestra empresa o .rea %uncional, de-emos sa-er qu es lo que nos o%rece el
proveedor desde di%erentes puntos de vista' /or e0emplo, no es lo mismo que el so%tHare te lo
o%re*ca a un @nico cliente, o que lo comparta con otros clientes y tampoco es lo mismo que el
recurso que comparta sea el c&digo de la aplicaci&n que la -ase de datos donde lo almacenas'

Ilustracin 6 Modelos de%inidos por %uncionalidad KL
/ara decidir qu es lo que m.s nos interesa desde el punto de cliente, antes veremos qu
es lo que actualmente nos podemos encontrar en el mercado tomando como re%erencia lo que
Microso%t de%ini& y llam& el modelo de madure* de (aa( K!L:
%ivel 1 de 7adure8. $n este nivel, el cliente tiene su propia versi&n personali*ada de la
aplicaci&n alo0ada' Corre su propia instancia de la aplicaci&n en los servidores del
proveedor'
%ivel $ de 7adure8. $n este nivel, )ay un vendedor 8propietario: y un cliente
8arrendatario:' $l proveedor alo0a una instancia independiente para cada aplicaci&n de
cada cliente' $n este nivel todas las implementaciones son del mismo c&digo y el
proveedor conoce las necesidades de los clientes, proporcionando opciones detalladas de
con%iguraci&n que permiten al cliente cam-iar la %orma en la que la aplicaci&n se ve y se
comporta para sus usuarios' 7os cam-ios reali*ados por el arrendatario pueden permitir la
disponi-ilidad de diversas opciones de personali*aci&n para sus clientes'
%ivel ' de 7adure8. $n este nivel, el vendedor, en lugar de acoger una instancia
independiente de la solicitud de cada cliente, al-erga una sola instancia' 7as pol+ticas de
1
autori*aci&n y de seguridad garanti*an que los datos de cada cliente se mantienen
separados de la de otros clientes'
%ivel - de madure8. $n este nivel, el proveedor agrupa a varios clientes en una gran0a
con equili-rio de carga para instancias idnticas, donde los datos de cada cliente que se
mantienen separados' 7os metadatos con%igura-les proporcionan una e9periencia de
usuario @nica y un con0unto de caracter+sticas para cada cliente'
Como se puede ver a medida que aumenta el nivel de madure* se o-tiene un mayor
aprovec)amiento de las econom+as de escala provenientes de la reducci&n en cada nivel de los
recursos necesarios que componen la soluci&n y por tanto del menor mantenimiento'

Ilustracin 9 Modelos de madure* en (aa( K"L
.2 5ipos de Cloud
?na ve* que se )a valorado que Cloud Computing es un modelo de negocio con unas
caracter+sticas que dotar.n de mayor valor a nuestros servicios y que o-tendremos un retorno de
la inversi&n, )ay que estudiar qu tipo de Cloud vamos a adoptar, los tres tipos de Clouds se van
a de%inir en -ase a quin va a poder acceder a los servicios y quin va a gestionar la
in%raestructura' 7os tipos son: p@-lica, privada e )+-ridaA tam-in se mencionar. como la
tendencia actual propone %ederar las nu-es, comunicarlas entre s+ y conseguir potenciar m.s la
escala-ilidad de la in%raestructura'
'.$.1 +loud p:blica
$n las nu-es p@-licas, los servicios que se o%recen se encuentra en servidores e9ternos al
usuario, pudiendo tener acceso a las aplicaciones de %orma gratuita o de pago, aunque
normalmente es de pago y cualquier con una tar0eta de crdito v.lida puede acceder y consumir
r.pidamente el servicio, adecuado cuando a la empresa que o%rece el servicio no le importa
compartir recursos virtuali*ados en la nu-e y donde el despliegue de la aplicaci&n ser. de manera
provisional K"L'
7a ventaja m.s clara de las nu-es p@-licas es la capacidad de procesamiento #
almacenamiento sin instalar m&$uinas localmente, por lo que no tiene una inversi&n inicial o
gasto de mantenimiento en este sentido, si no que se paga por el uso' 7a carga operacional y la
seguridad de los datos 8-acDup, accesi-ilidad, etc': recae +ntegramente so-re el proveedor del
)ardHare y so%tHare, de-ido a ello, el riesgo por la adopci&n de una nueva tecnolog+a es -astante
-a0o' $l retorno de la inversi&n se )ace r.pido y m.s predeci-le con este tipo de nu-es'
Como inconvenientes se cuenta con el acceso de toda la informacin a terceras
empresas% # la dependencia de los servicios en l"nea /a trav)s de ,nternet)' ;am-in puede
resultar di%+cil integrar estos servicios con otros sistemas propietarios' $s muy importante a la
)ora de apostar por un servicio en la nu-e p@-lica, asegurarse de que se puede conseguir todos
los datos que se tengan en ella, gratuitamente y en el menor tiempo posi-le'
'.$.$ +loud privada
Actualmente e9iste una importante tendencia en grandes empresas a la implementaci&n,
dentro de su estructura y utili*ando la red privada de la propia organi*aci&n, de las llamadas
=nu-es privadas> K"L' $ste concepto, a priori m.s cercano al de despliegue tradicional de
aplicaciones que al de Cloud Computing =est.ndar>, )ace re%erencia a redes o centros de
procesamiento de datos propietarios que utili*an tecnolog+as caracter+sticas de Cloud Computing,
tales como la virtuali*aci&n' As+, parten de los principios del Cloud Computing tradicional y
o%recen los mismos servicios pero dentro en la propia estructura de la compa+a'
(e suelen dise@ar espec"ficamente para un usuario, proporcionando un control &ptimo

de la in%ormaci&n gestionada, de su seguridad y de la calidad de servicio o%recida'
Sa-itualmente, el usuario es tambi)n propietario de la in%raestructura de nu-e privada, y tiene
control total de las aplicaciones desplegadas en ella'
7os principales inconvenientes de este modelo son los anali*ados para el paradigma
tradicional, por e0emplo los relativos a la ampliacin de los sistemas in%orm.ticos' $sto o-liga a
adquirir nuevos sistemas antes de )acer uso de ellos, contrariamente a lo o%recido por las nu-es
p@-licas, donde ampliar los recursos se reduce a contratarlos con el proveedor de servicios'
Como venta0a de este tipo de nu-es, a di%erencia de las nu-es p@-licas, destaca la
locali*aci&n de los datos dentro de la propia empresa, lo que conlleva a una mayor seguridad de
estos'
'.$.' +loud !brida
+l modelo 0"brido combina los modelos anteriormente descritos% sobre nubes p7blicas
# privadas% de manera $ue se aprovec0a la ventaja de localizacin f"sica de la informacin
gestionada por las nubes privadas con la facilidad de ampliacin de recursos de las nubes
p7blicas 9:;' 7as principales cuestiones a vigilar en este modelo son la privacidad y la protecci&n
de datos, al igual que en la nu-e p@-lica'
7as nu-es )+-ridas consisten en com-inar las aplicaciones propias de la empresa con las
consumidas a travs de la nu-e p@-lica, entendindose tam-in como la incorporaci&n de
servicios de Cloud Computing a las aplicaciones privadas de la organi*aci&n' $sto permite a una
empresa mantener el control so-re las aplicaciones cr+ticas para su negocio y aprovec)ar al
mismo tiempo las posi-ilidades o%recidas por los servicios o%ertados por la nu-e en aquellas
.reas donde resulte m.s adecuado'
/arece que actualmente este tipo de nu-es est. teniendo -uena aceptaci&n en las
empresas, por lo que se est.n desarrollando so%tHare de gesti&n de nu-e que permita controlar la
nu-e privada e incorporar al mismo tiempo recursos y servicios de proveedores p@-licos de
Cloud Computing'
! Jos Manuel Arvalo Navarro

Ilustracin ; $squema Cloud Computing
. ,mplementaciones
A continuaci&n se descri-en algunos proveedores de servicios que est.n marcando la
tendencia del mercado en la actualidad' (e )a descrito el proveedor de re%erencia en <aa(
8Ama*on Oe- (ervices: y la re%erencia en servicios /aa( 8Microso%t OindoHs A*ure:'
'.$.1 #ma8on <eb ervices 3#<4
?no de los proveedores de <aa( m.s so-resalientes en el mercado es Amazon <eb
-ervices' $ste proveedor permite que sus usuarios creen una <magen de m.quina virtual de
Ama*on 8AM<:, esto es, una m.quina virtual con el sistema operativo OindoHs o 7inu9, en la
que el usuario instala sus aplicaciones, li-rer+as y datos que necesite'
I l ust raci n 9 Logotipo Amazon Web Services [9]
/osteriormente, Ama*on e0ecuta esa m.quina en sus sistemas, y le asigna caracter+sticas
%+sicas 8como la capacidad de procesamiento m.9ima disponi-le, la cantidad de memoria MAM
m.9ima a utili*ar, el espacio de almacenamiento m.9imo disponi-le, etc': de acuerdo al contrato
suscrito con el usuario' $l usuario accede a esa m.quina de manera remota de la misma %orma en
que acceder+a a un servidor %+sico tradicional'
"
Asimismo, el usuario puede indicar a Ama*on que ampl+e sus sistemas autom.ticamente
seg@n las condiciones que )ayan esta-lecido previamente, y puede monitori*ar o controlar en
todo momento el estado de su m.quina virtual'
$n cuanto a precios, el coste se factura por 0ora de utilizacin # tipo de recursos
asignados a cada m&$uina f"sica 8como la capacidad de procesamiento, la cantidad de memoria
MAM, la cantidad de espacio para el almacenamiento secundario, el sistema operativo utili*ado o
el so%tHare adicional necesitado:' /ara %acilitar el c.lculo apro9imado de la %actura mensual, el
propio Ama*on contiene una calculadora disponi-le en su Oe-'
7os servicios m.s destaca-les de Ama*on son: $C2 y (' A continuaci&n se e9plican las
caracter+sticas principales de cada uno de ellos'
.2.1.1 Amazon +lastic Compute Cloud /+C2)
Ama*on $lastic Compute Cloud 8Ama*on =+$: es un servicio He- que proporciona
capacidad in%orm.tica con tamao modi%ica-le en la nu-e' (e )a diseado con el %in de que la
in%orm.tica He- resulte m.s sencilla a los desarrolladores K#L'
7a sencilla inter%a* de servicios He- de Ama*on $C2 permite o-tener y con%igurar
capacidad con una %ricci&n m+nima' /roporciona un control completo so-re sus recursos
in%orm.ticos y permite e0ecutarse en el entorno in%orm.tico acreditado de Ama*on' Amazon
+C2 reduce el tiempo necesario para obtener e iniciar nuevas instancias de servidor a
cuestin de minutos% lo $ue permite escalar con rapidez su capacidad /aumentarla o reducirla)
cuando cambien los re$uisitos inform&ticos 9A;' Ama*on $C2 cam-ia las reglas econ&micas de
la in%orm.tica al permitirle pagar s&lo por la capacidad que realmente utilice' Ama*on $C2
proporciona a los desarrolladores las )erramientas necesarias para crear aplicaciones resistentes a
errores y para aislarse de los casos de error m.s comunes'
Ama*on $C2 presenta un autntico entorno in%orm.tico virtual, que permite utili*ar
inter%aces de servicio He- para iniciar instancias con distintos sistemas operativos, cargarlas con
# Jos Manuel Arvalo Navarro
su entorno de aplicaciones personali*adas, gestionar sus permisos de acceso a la red y e0ecutar su
imagen utili*ando los sistemas que desee' /ara utili*ar Ama*on $C2, s&lo tiene que:
(eleccionar una imagen de plantilla precon%igurada para pasar a estar activo de
inmediato' 4 -ien crear una AM< 8Ama*on Mac)ine <mage: que contenga sus aplicaciones,
-i-liotecas, datos y valores de con%iguraci&n asociados KBL'
Con%igurar la seguridad y el acceso a red en su instancia de Ama*on $C2' (eleccionar
los tipos de instancias y sistemas operativos que desee y, a continuaci&n, iniciar, %inali*ar y
supervisar tantas instancias de su AM< como sea necesario, a travs de las A/< de servicio He- o
la variedad de )erramientas de gesti&n proporcionadas'
7as caracter"sticas que nos -rinda Ama*on con este servicio son:
+l&stico B Ama*on $C2 permite aumentar o reducir la capacidad en cuesti&n de
minutos, sin esperar )oras ni d+as' /uede enviar una, cientos o incluso miles de
instancias del servidor simult.neamente' ,ado que todo est. controlado mediante las
A/< del servicio He-, su aplicaci&n podr. escalarse autom.ticamente seg@n sus
necesidades aumenten o se redu*can KBL'
Control total B ;endr. control total so-re sus instancias' ;iene acceso de usuario ra+*
a todas ellas, y puede interactuar con ellas como con cualquier otra m.quina' /uede
detener su instancia y mantener los datos en su partici&n de arranque, para reiniciar a
continuaci&n la misma instancia a travs de las A/< del servicio He-' 7as instancias
se pueden reiniciar de %orma remota mediante las A/< del servicio He-' Asimismo,
tiene acceso a la emisi&n de consola de sus instancias KBL'
Cle8ible B ;iene la opci&n de varios tipos de instancias, sistemas operativos y
paquetes de so%tHare' Ama*on $C2 permite seleccionar una con%iguraci&n de
memoria, C/?, almacenamiento de instancias y el tamao de la partici&n de arranque
&ptimo para su sistema operativo y su aplicaci&n' /or e0emplo, entre sus opciones de
sistemas operativos se incluyen varias distri-uciones de 7inu9, Microso%t OindoHs
(erver y 4pen(olaris KBL'
Con un diseo pensado para su uso con otros Ama*on Oe- (ervices V Ama*on $C2
tra-a0a con Ama*on (imple (torage (ervice 8Ama*on (:, Ama*on (imple,F y
5
Ama*on (imple 2ueue (ervice 8Ama*on (2(: para proporcionar una soluci&n
completa de computaci&n, procesamiento de consultas y almacenamiento en una gran
gama de aplicaciones'
CiableB Ama*on $C2 o%rece un entorno muy %ia-le en el que las instancias de
sustituci&n se pueden enviar con rapide* y anticipaci&n' $l servicio se e0ecuta en los
centros de datos y la in%raestructura de red acreditados de Ama*on' $l compromiso
del contrato a nivel de servicio de Ama*on $C2 es de una disponi-ilidad del BB,B"R
en cada Megi&n de Ama*on $C2 KBL'
-eguro B Ama*on $C2 o%rece diversos mecanismos para proteger los recursos
in%orm.ticos KBL'
Ama*on $C2 incluye inter%aces de servicio He- para con%igurar el corta%uegos que
controla el acceso de red a grupos de instancias, y el acceso entre estos'
Al iniciar recursos de Ama*on $C2 en Ama*on Iirtual /rivate Cloud 8Ama*on I/C:,
puede aislar sus instancias in%orm.ticas especi%icando el rango de </ que desea utili*ar, as+ como
conectarse a su in%raestructura de <; e9istente mediante la red ci%rada </sec I/N est.ndar del
sector'
.2.1.2 Amazon -imple -torage -ervice /-)
4tro de los servicios cl.sicos de Ama*on es (' Amazon - es el servicio de
almacenamiento en la nube' $st. diseado para reali*ar el c&mputo He- a gran escala m.s %.cil'
Ama*on ( proporciona una sencilla inter%a* de servicios He- que pueden ser utili*ados para
almacenar y recuperar cualquier cantidad de datos, en cualquier momento, desde cualquier lugar
en la He-' (e permite a cualquier desarrollador acceder a la in%raestructura altamente escala-le,
%ia-le, seguro, r.pido, que Ama*on utili*a para e0ecutar su propia red mundial de sitios He-' $l
servicio tiene como o-0etivo ma9imi*ar los -ene%icios de escala y pasar esos -ene%icios a los
desarrolladores' Ama*on ( est. creado intencionadamente con un con0unto de %unciones
m+nimas KBL'
+scriba% lea # elimine objetos que contengan desde 1 -yte )asta " giga-ytes de datos'
$l n@mero de o-0etos que puede almacenar es ilimitado'
Cada objeto est& almacenado en un depsito, y se recupera por medio de una clave
e9clusiva asignada por el desarrollador'
Dn depsito puede estar almacenado en una de varias Regiones' ,e-e escoger una
Megi&n cercana para optimi*ar la latencia, minimi*ar los costes o a%rontar e9igencias
reguladoras' Ama*on ( est. actualmente disponi-le en las Megiones $$' ??'
est.ndar, ?$ 8<rlanda:, oeste $$' ??' 8norte de Cali%ornia: y Asia /ac+%ico
8(ingapur:' 7a Megi&n $$' ??' est.ndar redirige autom.ticamente las solicitudes
)acia instalaciones situadas en el norte de Iirginia o en el noroeste del /ac+%ico por
medio de asignaciones de red'
2os objetos almacenados en una Regin nunca abandonan la misma, a menos que
usted los trans%iera' /or e0emplo, los o-0etos almacenados en la Megi&n ?$ 8<rlanda:
nunca salen de la ?$'
-e inclu#en mecanismos de autenticacin diseados para garanti*ar que los datos se
mantienen seguros %rente a accesos no autori*ados' 7os o-0etos pueden )acerse
privados o p@-licos, y pueden otorgarse derec)os a usuarios determinados'
Dtiliza interfaces R+-5 # -OAP basadas en est&ndares diseadas para %uncionar
con cualquier Dit de )erramientas de desarrollo en <nternet'
+st& creado para ser fle8ible # permitir a@adir f&cilmente protocolos o capas
funcionales. $l protocolo de descarga predeterminado es S;;/' (e proporciona un
protocolo Fit;orren para reducir los costes de la distri-uci&n a gran escala'
'.$.$ 7icrosoft <indows #8ure
?no de los proveedores que m.s )a destacado por el momento es <indo1s Azure, que
o%rece la creaci&n de aplicaciones Oe- adaptadas a sus sistemas y su despliegue en los mismos
con ciertas limitaciones de consumo' Admite varios lengua0es de programaci&n y permite
compartir las aplicaciones con todo el mundo o s&lo con quien se desee' Asimismo, se puede
comen*ar a usar gratuitamente y s&lo pagar si se necesitan incrementar los l+mites o los recursos
utili*ados posteriormente, con un coste in%erior al de los sistemas tradicionales'
4tras empresas proveedoras de servicios de Paa- son .elneo o #8ure' Como e0emplo de
esta @ltima destaca <indo1s Azure Platform, una plata%orma que o%rece a los desarrolladores de
B
aplicaciones un entorno para crear y e0ecutar sus aplicaciones en los centros del proveedor'
=ic0o entorno proporciona las funcionalidades necesarias para $ue las aplicaciones creadas
con )l puedan realizar diversas tareas de negocio% almacenar informacin en bases de datos
de la EnubeF # comunicarse con otras aplicaciones creadas K"L' con ese o con otros entornos'
7os escenarios m.s comunes donde se emplea esta plata%orma a-arcan desde la creaci&n de sitios
Oe- para empresas )asta el almacenamiento de grandes cantidades de in%ormaci&n de %orma m.s
-arata y amplia-le en -ases de datos o sistemas de almacenamiento masivo'

Ilustracin 1> /lata%orma OindoHs A*ure K1!L
$ntre las o%ertas y servicios que o%rece OindoHs A*ure son:
<indo1s Azure 4 sistema operativo como un servicio en l+nea
!icrosoft -G2 Azure 4 soluci&n completa de -ase de datos Cloud relacional'
Plataforma AppCabric de <indo1s Azure 4 conecta servicios Cloud y aplicaciones
internas'
!E Jos Manuel Arvalo Navarro

Ilustracin 11 (ervicios en OindoHs A*ure K15L
7a plata%orma permite la total integraci&n de los servicios mencionados anteriormente
con )erramientas y aplicaciones que ya e9ist+an de Microso%t, como las que todos conocemos,
Microso%t 4%%ice, $9c)ange, todas ellas en modalidad (aa(, aunque la novedad reside en su
)erramienta CMM Microso%t ,ynamics, para el seguimiento de clientes y gesti&n empresarial en
general'
3.4 Cloud Computing y S!
$n esta secci&n se anali*ar.n y evaluar.n c&mo (4A y Cloud Computing coe9isten' 7a
secci&n discutir. las sinergias entre am-os modelos y se e9plicar. como el efecto de esta
combinacin es ma#or $ue la suma de los efectos individuales.
7a mayor parte de las implementaciones e integraciones -asadas en Cloud Computing
que se reali*an )oy en d+a tienen un prop&sito com@n, optimi*ar las aplicaciones a gran escala'
$stas aplicaciones necesitan ser %le9i-les, y la adopci&n de (4A puede proporcionar a los
desarrollos -asados en Cloud Computing un diseo para el acceso a los servicios a travs de un
-a0o acoplamiento y la )a-ilidad de evolucionar %.cilmente que de otro modo ser+a muy
comple0o' $l papel de (4A en Cloud Computing est. comen*ando a ser sistmico ya que ayuda
a la compresi&n de los procesos a nivel de dominio del pro-lema' $ste apartado presenta como
un -uen diseo orientado a servicios proporciona valor aadido a una arquitectura -asada en
Cloud Computing, as+ como (4A y Cloud Computing resultan soluciones in%orm.ticas
complementarias K12L'
Cloud Computing es un tipo de soluci&n, una alternativa m.s con las que a%rontar
nuestros retos pro%esionales, una %orma de crear un sistema en el que algunos o todos sus
!1
recursos de ;< e9istentes pueden estar en alg@n nivel de la in%raestructura Cloud de terceros, tales
como Ama*on $C2 o Force'com' /or lo tanto, Cloud Computing es algo que puede implicar
parte o la totalidad de una arquitectura' 7a di%erencia principal es que los recursos del sistema
van a ser m.s distri-uidos si ca-e'
(4A es todo so-re el proceso de de%inici&n de una soluci&n in%orm.tica o la arquitectura,
mientras que el Cloud Computing es una alternativa arquitect&nica' /or lo tanto, (4A no puede
ser sustituido por Cloud Computing' ,e )ec)o, la mayor+a de soluciones -asadas en la nu-e van
a ser de%inidas a travs de (4A' No compiten, son conceptos complementarios K12L''
4tro aspecto que de-emos considerar, es que (4A, adem.s de ser un patr&n
arquitect&nico, es una estrategia que alinea la tecnolog+a y las realidades del negocio, de0ando un
entorno listo para su%rir cam-ios 8tanto tecnol&gicos, como estratgicos: con el menor impacto
en costes posi-le' 7a decisi&n de introducir un modelo de servicios -asados en Cloud Computing
sin duda introduce serios cam-ios de la tipolog+a comentada anteriormente, veremos en qu
medida (4A puede mitigar el gap de adoptar un modelo -asado en Cloud'
?na de las principales venta0as de (4A es que est. alineado con los procesos de negocio
de la organi*aci&n, por lo tanto podemos delegar los aspectos espec+%icos de la in%raestructura al
proveedor de servicios Cloud que esco0amos' 7a venta0a de este aspecto reside en que, los
pro%esionales de una organi*aci&n pueden estar m.s preocupados en alinear negocio y ;< sin
preocuparse si la in%raestructura lo podr. soportar, dic)o de otro modo, se podr. en%ocar
es%uer*os en las necesidades reales de la organi*aci&n [12]' $n esta l+nea ca-e a%irmar que de
alg@n modo (4A proporciona un entorno con las -ondades que se )an e9plicado a lo largo del
tra-a0o, y Cloud Computing proporciona alta escala-ilidad de %orma transparente para el usuario,
esta a-stracci&n de in%raestructura y escala-ilidad evita tener que pensar en -alanceos de carga
de los servicios, centr.ndonos en las actividades que realmente proporcionan valor dentro de la
organi*aci&n, es decir, (4A est. orientada al negocio y Cloud est. orientado a la in%raestructura'
/or supuesto, la escala-ilidad de Cloud Computing se aplica a todo tipo de estilos
arquitect&nicos, no s&lo a (4A' (in em-argo, una de las ideas centrales en (4A, la reutili*aci&n
de la %uncionalidad y la co)erencia, es muc)o mayor cuando no )ay pro-lemas de escala-ilidad,
!2 Jos Manuel Arvalo Navarro
por la tanto podemos a%irmar que e9iste una clara sinergia entre reutili*aci&n y escala-ilidad'
$n cuanto a la gesti&n y go-ernan*a de los servicios, (4A es en s+ mismo un marco de
re%erencia K12L, es importante considerar que Cloud Computing va a llevar los servicios (4A
%uera del %ireHall interno donde sol+an alo0arse, se )ace necesario un sistema de gesti&n y
go-ernan*a tremendamente maduros' $l tremendo es%uer*o por introducir go-ierno (4A se ver+a
recompensando, ya que se le proporcionar+a a nuestra arquitectura Cloud caracter+sticas aadidas
tales como monitori*aci&n para el control de la actividad y cumplimiento de (7As por parte del
proveedor de in%raestructura Cloud K1"L, y un mayor control de la seguridad para mitigar el
aumento de riesgo que supone alo0ar en el e9terior los servicios al adoptar Cloud Computing'

Ilustracin 1$ (inergias entre (4A y Cloud Computing
;al y como se puede o-servar en la <lustraci&n 12, las sinergias entre Cloud Computing y
(4A aportar.n un gran valor aadido a nuestro sistema y a nuestra in%raestructura' 7a
com-inaci&n no solo nos aporta valor a nuestro negocio, (4A se ver. potenciado ya que Cloud
Computing e9tender. (4A %uera de las %ronteras de los %ireHalls internos de la organi*aci&n' Q
(4A proporcionar. a Cloud Computing todo un marco de gesti&n y go-erna-ilidad, inter%aces
d-ilmente acopladas -asadas en est.ndares y una -ase de diseo de la arquitectura a travs de
los principios de orientaci&n a servicios'
!
Captulo 4:
!dopcin" #ene$icios y riesgos en Cloud Computing
$n este cap+tulo se e9plicar.n los motivos por los cuales me puede interesar un modelo
!! Jos Manuel Arvalo Navarro
-asado en la nu-e' Qa )emos visto que permite el lan*amiento r.pido de servicios, el acceso a
los mismos desde cualquier lugar, se %acilita su di%usi&n y pu-licidad, es capa* de a-sor-er
crecimientos r.pidos y picos de carga, %acilita la integraci&n con otros servicios, etc' Ieamos
cu.les son las principales venta0as competitivas que Cloud Computing o%rece y que par.metros
son importantes para elegir unos modelos u otros' /or @ltimo anali*aremos que riesgos de-emos
asumir y poner es%uer*o para evitarlos'
4.1 !spectos claves en la eleccin de IaaS $rente a sistemas tradicionales
A continuaci&n se muestra de %orma esquemati*ada una comparaci&n entre el uso de los
sistemas in%orm.ticos tradicionales requeridos por una organi*aci&n, y los cam-ios que puede
aportar el uso de <aa('
$n el sistema tradicional se desaprovec)an recursos, mientras que en un sistema <aa( se
consigue una mayor e%iciencia en su utili*aci&n 8menos sistemas in%orm.ticos desaprovec)ados,
menor energ+a consumida por unidad de in%ormaci&n gestionada, sistemas m.s automati*ados:'
Asimismo, los recursos %+sicos se gestionan de manera uni%icada por parte del proveedor,
por lo que el tiempo necesario para adaptar los recursos de un usuario de <aa( a sus necesidades
reales en cada momento se reduce nota-lemente' As+, el proveedor de servicios podr. optimi*ar
el uso en todas sus m.quinas, reduciendo as+ los costes por el servicio'
7as m.quinas %+sicas utili*adas para <aa( son propiedad del proveedor de servicios, con el
consiguiente riesgo de que ste podr+a de0ar en alg@n momento de o%recer el servicio' (in
em-argo, esta caracter+stica aporta importantes venta0as, por e0emplo el )ec)o de que el
equipamiento se renueva m.s %.cilmente de-ido a la econom+a de escala de estos sistemas y de
que se siguen est.ndares que %acilitan la interopera-ilidad entre %a-ricantes'
/or otra parte, aunque en los sistemas tradicionales la in%raestructura es propiedad de la
organi*aci&n, tiene el inconveniente de que est. asociada a sistemas que se pueden quedar
o-soletos o ser incompati-les con otros'
$l empleo de servidores virtuales dedicados, que simulan una m.quina con un sistema
operativo propio, permite separar esta m.quina simulada del resto de %uncionalidades o%recidas
por el resto de la m.quina %+sica' As+, si la m.quina %+sica %alla, se puede utili*ar la m.quina
simulada en otra m.quina %+sica, por lo que las consecuencias de un %allo en alguna de las
!"
m.quinas y el tiempo de recuperaci&n se reducen dr.sticamente'
Adem.s, estas m.quinas utili*adas en <aa( se encuentran replicadas, y disponen de
centros %+sicos de almacenamiento y procesamiento con ciertas caracter+sticas 8como la
re%rigeraci&n de las m.quinas, su seguridad %+sica, etc': que, en el caso de ser implantadas en los
centros tradicionales, tendr+an unos costes demasiado elevados'
Ieamos los aspectos clave a tener en cuenta por parte de una empresa a la )ora de
escoger la implantaci&n de una soluci&n <aa('
Aspectos t)cnicos
$l proveedor de servicios <aa( o%rece una in%raestructura in%orm.tica para determinados
(istemas 4perativos y so%tHare 8como -ases de datos, alo0amiento Oe-, entornos de desarrollo
de aplicaciones, servidores de aplicaciones, codi%icaci&n y streaming de v+deo: y la empresa
usuaria de-e tener en cuenta que no podr. incorporar otros sistemas particulares de su soluci&n'
Aspectos estrat)gicos
7os usuarios pueden desplegar m.quinas virtuales en la in%raestructura %+sica de <aa( en
muy poco tiempo 8en los casos m.s sencillos, en pocos minutos:, por lo que se reduce
significativamente el tiempo # coste asociado de puesta en marc0a de nuevos sistemas'
Adem.s, la capacidad de ampliacin de los recursos 0ard1are es -astante menos costosa y
r.pida que en el caso tradicional'
/or otro lado, la disponibilidad # calidad de servicio o%recidos en <aa( suelen estar
garantizados durante casi todo el tiempo de utili*aci&n, o%reciendo soluciones alternativas en el
caso de %alta de servicio' As+, uno de los aspectos estratgicos por los que una empresa podr+a
optar por <aa( ser+a conseguir una reducci&n signi%icativa de la inversi&n en recursos para
garanti*ar la disponi-ilidad del sistema, que generalmente consiste en la adquisici&n de sistemas
%+sicos redundantes para evitar prdidas de servicios que )a-itualmente no se usan, con el
consecuente coste que suponen los recursos desperdiciados'
4tro aspecto estratgico a tener en cuenta es el )ec)o de que la deslocali*aci&n %+sica del
)ardHare utili*ado 0unto con el uso de redes privadas virtuales 8I/N: posi-ilita el acceso
!# Jos Manuel Arvalo Navarro
simult&neo # seguro de m7ltiples empleados de la organizacin a los sistemas con mayor
%acilidad de disponer de alta velocidad de cone9i&n'
Aspectos econmicos
$l coste de utilizacin de los servicios <aa( sigue varios modelos:
?$n el primer modelo se co-ra una tarifa fija por 0ora # unidad de recursos utilizados'
$sto suele ser @til para aplicaciones poco pro-adas en los que el consumo sea impredecible.
?$n el segundo, se o%rece la posi-ilidad de disponer de un recurso reservado% con un
pe$ue@o coste% # un cobro por el uso posterior' (uele emplearse en aplicaciones con un uso
predeci-le y que necesiten de capacidad reservada, incluyendo recuperaci&n ante desastres'
?$n otros modelos, se paga en funcin del uso instant&neo que se )aga de los recursos'
$ste @ltimo caso es adecuado cuando se necesita una alta %le9i-ilidad de los recursos en
determinados momentos, por e0emplo, grandes consumos en momentos determinados del d+a
no predeci-les'
Sa-itualmente, se pueden com-inar estos modelos para adaptarlos a las necesidades espec+%icas
del usuario'
Aspectos legales
$l uso de <aa( o-liga a sus usuarios a que no e9i0an la locali*aci&n en todo momento de
la u-icaci&n %+sica de la in%ormaci&n gestionada' 4tra caracter+stica a tener en cuenta es que
algunos de los proveedores de servicios <aa( reali*an -acDGups o copias de la in%ormaci&n que
gestionan' $stos dos aspectos son importantes si se gestiona in%ormaci&n protegida de car.cter
personal o empresarial'
4.2 !spectos claves en la eleccin de PaaS $rente a sistemas tradicionales
Al igual que en <aa(, el uso de /aa( aporta ciertas me0oras y %acilidades %rente a sistemas
tradicionales, entre las que destacan:
Calidad final
$l importante es%uer*o cola-orativo reali*ado en aplicaciones in%orm.ticas creadas con
!5
/aa( )ace posi-le que en la gran mayor+a de los casos el usuario perci-a una calidad %inal mayor
que la o%recida por aplicaciones convencionales:
A diferencia del proceso tradicional, donde se desarrolla en un entorno y posteriormente
se traslada a otros para su prue-a y puesta en marc)a, en Paa- la creacin de la aplicacin se
realiza en un entorno unificado # $ue ser& el mismo al $ue acceder&n sus usuarios finales, por
lo que se reducir.n los errores de-idos a las di%erencias entre entornos y ser.n m.s sencillos de
corregir'
/or otra parte, el )ec)o de gestionar toda la in%ormaci&n de manera centrali*ada permite
o-tener estad+sticas de la in%ormaci&n real accedida en cada momento, las cuales podr+an
reutili*arse para me0orar la aplicaci&n u otras similares'
,nteroperabilidad con otros sistemas en l"nea
?n elevado n@mero de aplicaciones, tales como sistemas de comercio electr&nico o
sistemas de predicci&n meteorol&gica, requieren acceso en tiempo real a in%ormaci&n disponi-le
en otros puntos de <nternet u otras redes' ;ra-a0ar con /aa( %acilita la conectividad a esos
recursos, ya que am-os estar.n diseados espec+%icamente para tra-a0ar de %orma con0unta, y
permite actuali*ar autom.ticamente las cone9iones entre los recursos, lo cual supone una venta0a
respecto al desarrollo reali*ado en los sistemas tradicionales'
Asimismo, /aa( utili*a %recuentemente una in%raestructura <aa(, ya descrita
anteriormente, -ene%ici.ndose de sus venta0as como ampliar o reducir los recursos %+sicos
e%icientemente'
A continuaci&n, se citan los aspectos clave a tener en cuenta por parte de una empresa a
la )ora de escoger la implantaci&n de una soluci&n /aa('
Aspectos t)cnicos
A la )ora de crear las aplicaciones que posteriormente se situar.n en los sistemas /aa(,
)ay que tener en cuenta que la tecnologa a usar en las mismas de-e ser compatible con dic)os
!6 Jos Manuel Arvalo Navarro
sistemas' $n general, la tecnolog+a estar. -asada en est.ndares internacionales, pero el rango de
%unciones que o%rece puede ser -astante limitado en ciertos casos' /or e0emplo, en la creaci&n de
aplicaciones Oe- so-re Google App *ngine, descrito en el apartado #'!, los lengua0es de proG
gramaci&n utili*ados @nicamente pueden ser Pyt)on y +ava' $sto puede reducir el rendimiento de
determinadas aplicaciones'
/or otro lado, las plata%ormas /aa( permiten ampliar %.cilmente los recursos disponi-les
para la aplicaci&n ya que, por e0emplo, se usan sistemas de %ic)eros y -ases de datos espec+%icas
para ello' (in em-argo, la gesti&n de la in%ormaci&n en estos sistemas es -astante m.s comple0a,
por lo que en la pr.ctica se con%+a parte de ese control al proveedor de servicios' (e de-er.
conocer )asta qu punto la in%ormaci&n gestionada es cr+tica, y qu niveles de seguridad se
esta-lecer.n' $sto o-liga al proveedor a suministrar in%ormaci&n so-re la estructura de los datos'
Finalmente, la gestin de las aplicaciones una ve* situadas en las m.quinas de /aa(
suele ser m.s sencilla que en las instalaciones tradicionales, pero se dispone de menor control de
todos los sistemas'
Con /aa( se o%recen soluciones de almacenamiento y computaci&n para los
desarrolladores de so%tHare accesi-les independientemente de la u-icaci&n geogr.%ica,
adoptando as+ econom+as de escala y %le9i-ilidad de con%iguraci&n sin que los usuarios de la
plata%orma necesiten mantener la tecnolog+a su-yacente'
Aspectos econmicos
7os proveedores /aa( )a-itualmente o%recen un periodo de prue-as sin coste en los que
los usuarios pueden compro-ar las venta0as competitivas que pueden encontrar en /aa(, o
pueden e9perimentar con nuevas aplicaciones adaptadas a ese tipo de sistemas'
Com@nmente, se o%rece un coste por uso de los recursos del sistema, es decir, se co-ra
una cantidad %i0a por cada CFyte de almacenamiento, por cada )ora de procesamiento o por cada
CFyte de in%ormaci&n transmitida )acia terceros' Asimismo, para %omentar la implantaci&n de
/aa( se tiende a o%recer un servicio gratuito limitado a una cantidad diaria de uso, a partir del
cual se reali*a el co-ro seg@n se )a descrito'
!B
Aspectos legales
Al comen*ar a usar los servicios /aa(, se esta-lece un acuerdo entre el proveedor y el
usuario en el que se descri-en las condiciones del servicio o%recido' Sa-itualmente, el usuario se
compromete a no reali*ar un uso inde-ido de los sistemas que se le o%recen'
/or otro lado, el proveedor seala las condiciones de tari%icaci&n del servicio, de garant+a
de acceso y gesti&n adecuada de la in%ormaci&n, y de las garant+as legales en caso de errores o
desastres en sus sistemas'
4.3 !spectos claves en la eleccin de SaaS $rente a sistemas tradicionales
$n la pr.ctica, las aplicaciones (aa( se di%erencian de las aplicaciones tradicionales en
ciertos aspectos %undamentales, varios de ellos ya comentados en las venta0as generales o%recidas
por Cloud Computing:
Coste
7as aplicaciones tradicionales tienen un coste inicial alto -asado en la adquisici&n de las
licencias para cada usuario' $stas licencias suelen ser a perpetuidad, es decir, no imponen
restricciones temporales a su uso'
$n cam-io, para las aplicaciones (aa( el coste se -asa en el uso, no en el n@mero de
usuarios, y el gasto de mantenimiento es nulo, ya que la las aplicaciones las gestiona el propio
proveedor' ?n modelo m.s equili-rado entre am-os podr+a ser el uso de sistemas -asados en un
uso ilimitado durante un periodo de tiempo'
Administracin inform&tica
7as organi*aciones que usan so%tHare tradicional com@nmente necesitan un
departamento de administraci&n o una su-contrataci&n de esas competencias a otras empresas
para que se resuelvan pro-lemas asociados a la implantaci&n de la in%raestructura in%orm.tica o
la resoluci&n de pro-lemas como la seguridad de los sistemas, la %ia-ilidad, el rendimiento
o%recido o pro-lemas de disponi-ilidad' (i se utili*a (aa(, esta administraci&n se ve reducida
considera-lemente, ya que la reali*a el proveedor de servicios -as.ndose en el acuerdo de nivel
"E Jos Manuel Arvalo Navarro
de servicio'
,ndependencia de las mejoras en las aplicaciones
$l proveedor de (aa( no s&lo se encarga de la administraci&n, como se aca-a de
comentar, sino que tam-in es el que se encarga de instalar, mantener y actuali*ar las
aplicaciones del cliente, por lo que este @ltimo podr. invertir su tiempo en las tareas propias de
su negocio, utili*ando sus recursos en las .reas m.s estratgicas'
$9isten ciertos aspectos clave a la )ora de decidir optar por soluciones (aa( de %orma
total o parcial en la organi*aci&n:
Aspectos t)cnicos
7as aplicaciones in%orm.ticas (aa( suelen o%recer cierta %le9i-ilidad de con%iguraci&n
para su adaptaci&n a las necesidades del cliente' (in em-argo, e9isten empresas que necesitan
aplicaciones muy particulares, cuya adaptacin a partir de soft#are (aa( es demasiado costosa
econ&mica o tcnicamente para los proveedores de servicios' $n esos casos, esas empresas
de-er.n desarrollar un soft#are espec+%ico'
4tro %actor a considerar es el tipo 2 la cantidad de datos a transmitir a las aplicaciones
de la empresa' Sa-itualmente, las redes de comunicaciones o%recen altas velocidades de
transmisi&n de datos en sus instalaciones, y menores velocidades en su acceso a <nternet' (i se
utili*a una aplicaci&n (aa(, se )a de considerar que se de-er. acceder a <nternet para transmitir
in%ormaci&n' /ara paliar la lentitud del sistema al transmitir in%ormaci&n, las aplicaciones (aa(
s&lo transmiten la in%ormaci&n estrictamente necesaria 8tam-in llamada soluci&n -asada en
cac): o agrupan la in%ormaci&n para transmitirla en el momento &ptimo 8soluci&n denominada
transmisi&n por lotes:'
$n algunas empresas se presenta cierta resistencia a que las %uncionalidades de gesti&n
de la empresa se e9ternalicen )acia sistemas en <nternet' (in em-argo, se pueden reali*ar
proyectos de prue-a en los que se analicen las me0oras que puede aportar a la empresa el uso de
estos sistemas (aa(' $n consonancia con ello, los proveedores de (aa( o%recen a menudo
periodos de prue-a para que las empresas puedan reali*ar estos an.lisis'
"1
Aspectos econmicos
/ara reali*ar un an.lisis adecuado se )a de comparar el coste total de propiedad 8llamado
en trminos econ&micos, ;C4: de una aplicaci&n (aa( %rente al del so%tHare tradicional' Aunque
el coste inicial de una aplicaci&n (aa( es )a-itualmente in%erior, el coste a largo pla*o se puede
llegar a incrementar de-ido a las tari%as por el uso del servicio' 7os %actores m.s destacados que
a%ectan al ;C4 de una aplicaci&n incluyen el n@mero de licencias de usuario del so%tHare
necesarias o la cantidad de con%iguraci&n requerida para integrar la aplicaci&n a la in%raestructura
de la organi*aci&n' Asimismo, se )a de tener en cuenta si se )an reali*ado inversiones recientes
en in%raestructuras de las que se espera un retorno de la inversi&n en cierto periodo de tiempo'
Aspectos legales
Algunas organi*aciones que operan en varios pa+ses est.n su0etas a legislaciones que
e9igen la o-tenci&n de in%ormes que descri-an c&mo gestionan la in%ormaci&n' (in em-argo, es
posi-le que los proveedores de (aa( no sean capaces de proporcionar esos in%ormes, o de utili*ar
sistemas de tra*a-ilidad o seguimiento de la in%ormaci&n que gestionan. 5odo esto debe
aparecer claramente especificado en el acuerdo de nivel de servicio /-2A).
4.4 tros %aaS: &l caso del 'irtual (es)top In$rastructure *'(I+
,ada la creciente popularidad que est.n adquiriendo las distintas soluciones -asadas en
Cloud Computing, )a surgido una %amilia de modelos de servicios que se aaden a las ya
comentadas 8(aa(, /aa(, <aa(: y que se denomina Naa(' $sta %amilia de servicios tiene como
e0emplos, ;esting as a (ervice, (ecurity as a (ervice, Modeling as a (ervice, todo como servicio'
+n ocasiones cuando se descontrola la terminolog"a sobre un concepto% esta% deja de aportar
valor, cuando lo que realmente aportar valor aadido es la propia %uncionalidad que te o%rece
determinado servicio' No o-stante, )ay un modelo de la %amilia Naa( y que est. siendo
adoptando por grandes compa+as como por e0emplo el FFIA' +ste modelo se denomina
=esHtop as a -ervice /=aa-)% aun$ue su nombre m&s popular es .irtual =esHtop
,nfrastructure /.=,)'
2a idea que )ay detr&s de lo $ue se llama .irtual =esHtop ,nfrastructure /.=,) es
"2 Jos Manuel Arvalo Navarro
ejecutar sistemas operativos de escritorio # aplicaciones en m&$uinas virtuales $ue residen en
los servidores del centro de datos 9I;' A los sistemas operativos de escritorio dentro de m.quinas
virtuales tam-in se les conoce como los escritorios virtuales' 7os usuarios acceden a los
escritorios virtuales y aplicaciones desde un cliente /C de escritorio o de cliente ligero con un
protocolo de visuali*aci&n a distancia y llegar a casi todas las %unciones como si las aplicaciones
se cargan en sus sistemas locales, con la di%erencia de que las solicitudes son administradas' Al
igual que la virtuali*aci&n de servidores, I,< o%rece muc)os -ene%icios' $n concreto, las tareas
administrativas # de gestin se 0an reducido significativamente 9I;A aplicaciones de %orma
r.pida se pueden agregar, eliminar, actuali*ar, y parc)es, la seguridad es centrali*ada'
I,< tiene algunas similitudes con una arquitectura de in%raestructura de aplicaciones para
compartir, donde el acceso del usuario es a travs de un cliente ligero' (in em-argo, )ay
di%erencias' /or e0emplo, I,< permite a las empresas a aislar a los usuarios entre s+ en el caso de
un %allo de sesi&n individual' I,< ;am-in puede e0ecutar la mayor+a de aplicaciones de %orma
nativa sin modi%icaciones' I,< soporta aplicaciones que requieren un cliente TpesadoT'
$sta capacidad de soportar toda la gama de tipos de escritorio es esencial, ya que muc)os
usuarios quieren los -ene%icios, tales como el espacio de almacenamiento personal, que un /C
completo o%rece'
F.sicamente, los usuarios desean las caracter+sticas y %le9i-ilidad del escritorio
tradicional, pero sin los pro-lemas de la tasa de %allos'
7os cam-ios como la instalaci&n de una nueva aplicaci&n, la actuali*aci&n de una
aplicaci&n e9istente, o aplicar un parc)e se puede )acer sin tener que tocar la /C %+sica del
usuario es transparente al usuario K6L'
2a programacin # automatizacin de parc0es # actualizaciones tienen una tasa de
)8ito ma#or #a $ue se puede iniciar J detener las m&$uinas virtuales de escritorio en el centro
de datos 9I;. $stas m.quinas virtuales son independientes de )ardHare y se puede e0ecutar en
cualquier servidor de centro de datos y se puede acceder desde cualquier cliente' Adem.s, los
datos asociados con estas aplicaciones se pueden almacenar en el centro de datos, por lo que es
m.s %.cil )acer una copia de seguridad de los datos y protegerlo de usuarios no autori*ados'
Adem.s de )acer que sea m.s %.cil de desplegar y mantener aplicaciones, .=, tambi)n
"
simplifica la resolucin de problemas 9I;. /or e0emplo, cuando un usuario llama al servicio de
asistencia, el personal puede tra-a0ar en el pro-lema en el centro de datos y no tiene que visitar el
escritorio'

Ilustracin ; Modelo Iirtual ,esDtop <n%rastructure K1EL
I,< tam-in se puede utili*ar para proporcionar acceso a aplicaciones y datos a los
usuarios remotos que no est.n dentro del %ireHall de la pared de la empresa' $sto es @til cuando
un departamento de ;< de-e apoyar a los usuarios que tra-a0an desde casa o en otros, o%icinas
geogr.%icamente dispersas' Apoyar a los usuarios es a menudo una tarea di%+cil' Cuando )ay
pro-lemas, el usuario a menudo se necesita enviar su escritorio o port.til a la o%icina principal
para su reparaci&n' Con I,<, los pro-lemas son m.s %.ciles de solucionar ya que los sistemas
virtuales se mantienen en el centro de datos donde )ay un personal de ;<'
?n -ene%icio adicional del uso de I,< es que permite a las empresas a mantener la
seguridad # cumplir con las regulaciones de cumplimiento% sin tener $ue poner como foco
tanto en la seguridad del PC K6L virtuales mediante la asignaci&n de m.s recursos de C/? y
memoria'
I,< reduce el tiempo de inactividad, las velocidades de la resoluci&n de pro-lemas,
me0ora la capacidad de gesti&n y control, y ayuda a mantener la seguridad de ;< y protecci&n de
datos. +l resultado final es una ma#or disponibilidad # productividad de los trabajadores
mejora'
"! Jos Manuel Arvalo Navarro
4., -iesgos en Cloud Computing
Como consecuencia directa de adoptar un nuevo modelo, siempre ca-e la posi-ilidad de
que se de-an asumir riesgos adicionales, en Cloud Computing la ma#or"a de los riesgos son
similares # comunes al resto de modelos y sistemas de in%ormaci&n, pero es conveniente
afrontarlos de cara # a@adir soluciones' A continuaci&n se anali*an los riesgos m.s comunes en
Cloud Computing'
$n secciones anteriores se )an mencionado las caracter+sticas y -ondades que o%rece
Cloud Computing, pero el motivo de este apartado es sealar que este nuevo modelo no de-e
tomarse a la ligera, que no es %.cil adoptarlo y que supone un reto' $9isten determinados riesgos,
riesgo de seguridad interna, riesgo de seguridad e9terna, riesgo de ca+da del servicio, riesgo de
protecci&n de datos, riesgo de prdida de datos' /ero entraremos a detallar los introducidos
especialmente por Cloud Computing'
Riesgo de p)rdida de datos4
?na de las mayores venta0as de mover nuestros recursos a la nu-e, es la despreocupaci&n
de reali*ar -acDups diariamente, resulta una preocupaci&n menos' /ero e9iste el riesgo de que
toda esa in%ormaci&n se pueda perder, si estamos )a-lando de un Cloud p@-lico, el (7A de-e
asegurar la in%raestructura est. replicada en distintas *onas geogr.%icas y un sistema de
recuperaci&n tremendamente maduro y gestionado K1L' ?na soluci&n para prevenir perdida de
datos en Clouds p@-licos es optar por una soluci&n de Cloud )+-rida, en la cual solo migraremos
a la parte p@-lica nuestros procesos menos cr+ticos' 4tra posi-le soluci&n es optar por una
segunda nu-e p@-lica que sea redundante a la primera y que sirva como -acDup'
Riesgo de ca"da del servicio4
?no de los riesgos que m.s impacto puede causar en nuestro negocio, es sin duda, la
ca+da del servicio, este riesgo es mayor si estamos )aciendo uso de una <aa( p@-lica K1L' 7a ca+da
de un servicio no solo a%ecta a que durante un tiempo determinado estemos teniendo prdidas ya
""
que nuestra %uncionalidad est. ca+da' (i no que adem.s nuestra imagen con respecto a nuestros
clientes se ve deteriorada si no lo gestionamos -ien'

)abla 1 $0emplos ca+das de servicio
Como soluci&n es necesario solicitar un completo (7A -a0o el cual estemos -lindados si
nuestro proveedor de servicios no cumple con las e9igencias negociadas' Algunos e0emplos
)ist&ricos de ca+das de servicio de grandes proveedores son los que aparecen en la %igura a
continuaci&n'
"# Jos Manuel Arvalo Navarro
Captulo ,:
Integracin de un caso de estudio en la nu#e
4 Integracin de un caso de estudio en la nu5e
"5
A continuaci&n se e9plicar. todo el desarrollo del caso de estudio reali*ado y que
supondr. la consecuci&n de uno de los o-0etivos de este proyecto %in de master'
$n apartados anteriores se )an comentado las caracter+sticas y -ondades de la
computaci&n en la nu-e, pero es ocasi&n de llevarlo a la pr.ctica' $s importante de%inir un claro
posicionamiento, descri-iendo las caracter+sticas del que va a ser nuestro nuevo modelo y
posteriormente e0ecutarlo so-re nuestro sistema de partida inicial 8Cesimed:' Anali*aremos las
venta0as introducidas, as+ como los o-st.culos encontrados de adoptar Cloud Computing y el
impacto que )a tenido so-re la arquitectura de nuestro sistema, as+ como un an.lisis de costes y
del retorno de la inversi&n 8M4<: como consecuencia de adoptar este modelo'
:.1 -istema de informacin inicial4 Kesimed
7a integraci&n que reali*aremos en este proyecto, tiene como punto de partida la @ltima
versi&n de Cesimed K11L y que supuso el caso de estudio del proyecto %in de carrera )ace dos
aos. Kesimed se implement con servicios 1eb # basado en -OA, la arquitectura %inal se
dise& de la siguiente manera'
Ilustracin 1' Arquitectura de Cesimed K12L
"6 Jos Manuel Arvalo Navarro
Cront?+nd4 $ste m&dulo implementa la inter%a* He- que se le presenta al usuario
mediante servicios He- M$(;' ;iene integrados los servicios (4A/ del FacDG$nd y reali*a las
tareas de orquestador de servicios en %unci&n de los eventos que provoca el usuario' $st. -asado
en tecnolog+a Java y alo0ado en un entorno de m.quina local mediante un servidor de
aplicaciones Jetty'
3acH?+nd4 $ste su-sistema implementa mediante servicios He- compuestos -asados en
O(,7 todo el n@cleo de Cesimed, se disearon e implementaron todos los servicios necesarios
para cu-rir toda la %uncionalidad 87ogin, gesti&n de usuarios, gesti&n de im.genes, etc':' $ste
m&dulo accede a los datos alo0ados en la -ase de datos, incluso las im.genes est.n alo0adas en la
-ase de datos dada su naturale*a o-0eto relacional, asumimos la -ase de datos como un sistema
legacy' $ste FacDG$nd est. implementado con tecnolog+a 'Net y OindoHs Communication
Foundation 8OFC:'
:.2 Posicionamiento de Kesimed en la nube
?na ve* reali*ado el estudio so-re el paradigma de Cloud Computing, ya sa-emos que
alternativas y venta0as nos o%rece' +n esta seccin se e8plicar& de $u) manera vamos a
posicionar Kesimed en la nube, como ya se )a visto los modelos pueden ser (aa(, /aa(, <aa('
/or ello se detallar. cu.l va a ser el posicionamiento e9acto de Cesimed en la nu-e' 2os motivos
se justificar&n en detalle en apartados posteriores, ya que esta secci&n tan solo nos permitir.
tener una idea glo-al y de alto nivel de la estrategia seleccionada para nuestro caso de estudio'
)abla $ /osicionamiento de Cesimed(aa( en la nu-e
"B
7a ta-la muestra cu.l ser. nuestra posici&n en la nu-e con respecto al respecto al resto
del mercado' ,ada la %uncionalidad de Cesimed y puesto que esta la que marca la categori*aci&n
de un sistema en alguno de los tipos de modelos que o%rece Cloud Computing, se 0a
considerado $ue el modelo $ue le aplica es el de -aa-, la 0usti%icaci&n a esta decisi&n se puede
encontrar en el siguiente cap+tulo' /or otro lado vamos a 0acer uso de una infraestructura como
servicio para conseguir las caracter+sticas que rigen un modelo (aa(, se realizar& un estudio de
costes /seccin :.*) # del RO, /seccin :.:) frente a dise@ar una infraestructura con un
modelo tradicional'
:. Posicionar Kesimed en un modelo -aa-
Cuando en alguna ocasi&n nos planteamos una migraci&n, la adopci&n de un nuevo
modelo, en de%initiva, un cam-io, la pregunta que de-e dar sentido a la motivaci&n de esa
iniciativa es 1/or qu3' 7legados a este punto y a pesar de )a-er descrito caracter+sticas muy
-ene%iciosas del Cloud Computing, la pregunta ra*ona-le de este punto es 1/or qu adoptar
Cloud Computing3, 1/or qu posicionar Cesimed en otro modelo (aa(3'
$ste apartado no solo pretende e9plicar c&mo se )a reali*ado la transici&n )acia un nuevo
modelo, si no tam-in 0usti%icar las ra*ones que nos )an llevado a )acerlo' /arece muy o-vio,
pero lo cierto es que, Cloud Computing o%rece tantas alternativas y oportunidades, que el a-anico
de casos de estudios posi-les se multiplican, y las ra*ones, o-0etivos u en%oques de cada uno de
ellos puede ser muy distintos'
(iendo concisos, los motivos que nos )an llevado a tomar la decisi&n de migrar nuestro
sistema de in%ormaci&n )ac+a un modelo (aa( son:
? !otivos de integracin
Cada ve* es m.s t+pico encontrar a usuarios que acuden a portales de contenidos He-
donde se les o%rece adquirir aplicaciones' ,ic)os portales suelen tener la caracter+stica de ser
agregadores de servicios o <(IJs, es muy com@n que los <(IJs de-an implementar un contrato
de servicios o inter%a* de servicios He- previamente, generalmente un O(,7'
#E Jos Manuel Arvalo Navarro
Nuestro sistema est. -asado en (4A' Cracias a que partimos de un sistema orientado a
servicios la integraci&n con agregadores de servicios, marDetplaces, appsGstores, etc', podr+a
resultar muy sencilla y potenciar+a comercialmente la aplicaci&n'
? !otivos Comerciales
$l modelo de (o%tHare as a (ervice, tiene como caracter+stica el pago por uso, mediante
un modelo de %acturaci&n -asado en licencias o por tiempo de uso, en nuestro caso podr+amos
incluso de%inir por intercam-io en megas del tamao de las im.genes mdicas 8mayor calidad,
mayor precio:' Nuestro sistema suele llegar con mayor %recuencia al sector de la investigaci&n,
durante periodos muy concretos de tiempo, como es la duraci&n de un proceso de investigaci&n o
lo que dure una asignatura universitaria'
,e-emos de%inir detalladamente un modelo de su-scripci&n concreto, cuota de alta,
cuota mensual, promociones, etc' /or otro lado el proceso de -a0a del servicio de-e ser din.mico
y %le9i-le, ,a golpe de rat-n.. Cualquier tipo de su-scripci&n que o-liguemos al usuario m.s
all. del tiempo que lo va a usar puede resultar que es dinero desperdiciado o una molesta para
reali*ar la -a0a del servicio' A continuaci&n se detalla %ormalmente la lista de procesos necesarias
para reali*ar una migraci&n )acia (aa('
a) Asegurarse de $ue se entiende por$ue $ueremos implementar -aa-
$n la introducci&n de este cap+tulo )emos dado respuesta a esta cuesti&n que se considera
de-e ser la primera' $s muy importante conocer nuestros actuales procesos y %uncionalidades,
anali*ar )acia donde queremos llegar, detectar los riesgos y esta-lecer la )o0a de ruta del
proyecto'
b) -olicitar un -2A antes de firmar ning7n contrato
;anto desde el punto de vista del cliente como del proveedor, de-eremos con%eccionar un
(7A, con todo el tipo de soporte que o%receremos, tiempos de resoluci&n de incidencias, etc'
/ero tam-in se lo solicitaremos a nuestros proveedores de servicios, en nuestro caso servicios
de in%raestructura 8AO(:'
#1
c: Planificar un e$uipo de soporte 5,
$n ocasiones surgir.n incidencias de distinto tipo y gravedad, nuestro (7A tendr. una
serie de caracter+sticas que de%inen la %orma en la que se responder. a dic)as incidencias' (er.
necesario contar con un equipo tcnico y de soporte para dar respuesta a esos requisitos -a0o los
cuales nos comprometemos con el cliente'
d) =efinir un modelo de negocio para las aplicaciones
$ste es uno de los apartados m.s importantes, consiste es de%inir -a0o qu modelo el
usuario puede )acerse con nuestro servicio, es decir, las opciones que se le van a o%recer, puede
ser -a0o licencias de uso, individuales o por paquetes' $s muy com@n esta-lecer una pol+tica de
promociones, del tipo trial, -ienvenida, por tramos, etc' A continuaci&n se de%ine nuestro modelo
de negocio'
/uesto que nuestro sistema est. muy ligado al .m-ito investigador, es muy pro-a-le que
est motivado a usarse en grupos 8grupo universitario, grupo mdico:, por ello vamos a o%recer
nuestra aplicaci&n (aa( mediante pa$uetes de diez usuarios% la idea es $ue $ui)n las compr)
/profesor% jefe de departamento) asigne cada una de las diez licencias diez personas'
/ara compensar la idea de que alguien quiera )acer uso individual, )emos de%inido una
promocin de degustacin o trial de dos meses de duracin # una sola licencia, -a0o la cual
estar. li-re de pagar nada' Cuando la promoci&n de degustaci&n %inalice, el usuario de-e comprar
la aplicaci&n si no quiere perder todos sus datos'
/ara todos los usuarios que quieran dis%rutar de la aplicaci&n en modo de pago, les
proporcionamos una promocin de bienvenida de un mes de duracin, est. se aplicar.
independientemente de )a-er dis%ruta de la de degustaci&n, esta promocin se obtiene por valor
de diez licencias # cuando cadu$ue se empezar&n a realizar los cobros mensuales.
$n cuanto al n@mero de licencias que se compren %uera de las promociones anteriormente
#2 Jos Manuel Arvalo Navarro
mencionadas, se )an esta-lecido una pol+tica de precios por tramos como muestra la %igura a
continuaci&n'

)abla ' /recios Cesimed(aa(
7a idea es que estos precios no sean nuestra @nica %uente de ingresos, se estudiar. la
opci&n de introducir pu-licidad segmentada por tipo de usuario en las versiones de degustaci&n y
-ienvenida, as+ como la integraci&n no solo con portales de aplicaciones (aa( si no la posi-ilidad
de cola-orar con portales de centros de investigaci&n' /or @ltimo se muestra un prototipo de
%ormulario, en el proceso de compra de la aplicaci&n, cada MarDet/lace lo implementar. a su
manera pero recomendamos seguir este modelo para mayor %acilidad de integraci&n'
#

Ilustracin 1- Modelo de negocio en %ormulario He-
e) =esarrollo de las aplicaciones basado en <+3 2.L
7a He- 2'E no es una tecnolog+a actual pero dado que la mayor+a de las aplicaciones
-asadas en (aa( son He-, se )ace necesario %acilitarle al cliente una me0or e9periencia como
usuario' Nos permitir. introducir noti%icaciones multicanal 8$mail, (M(, M((:, llevar un control
de actividad con )erramientas como Coogle Analitics, etc' Aunque el aspecto m.s importante en
este conte9to es la implementaci&n -asada en mas)ups' $stos pueden ser %.cilmente
implementa-les mediante alg@n %rameHorD -asado en A0a9 8,o0o, Mootols: y servicios He- de
tipo Mest o (4A/, el %rameHorD reali*a peticiones as+ncronas con %ormato Java (cript 4-0ect
Notation 8J(4N: a los servicios, recoge la in%ormaci&n y la di-u0a en la p.gina, normalmente en
tiempo de carga de la p.gina K1#L' As+ se podr.n di-u0ar di%erentes m&dulos independientes y
%uncionales, un claro e0emplo es iCoogle' +n un !arHetPlace de e0emplo, podr"amos tener las
aplicaciones como !as0ups% justo antes de iniciar el proceso de compra o para a@adirlas al
carrito como muestra la imagen.
#! Jos Manuel Arvalo Navarro
Ilustracin 15 mas)up Cesimed(aa( en marDetplace
f) Ar$uitectura de integracin con un marHetplace
7os MarDet/laces a modo de ecosistemas (aa(, son una de las motivaciones por las
cuales los <(I migran a un modelo (aa(' 7os clientes potenciales acudir.n a estos portales de
autoservicio de aplicaciones y so%tHare como servicio para adquirir los distintos servicios que se
les o%rece' (i queremos potenciar las oportunidades de nuestro sistema y llegar al m.9imo
n@mero de gente posi-le nos integraremos con un MarDet/lace' (in duda tenemos la venta0a de
que partimos de un sistema -asado en (4A, aunque en este proceso se detectan algunas tareas
que pueden causar mayor o menor impacto en %unci&n de la arquitectura de partida'
7as tareas detectadas necesarias en este proceso son:
o ,mplementacin del contrato de integracin del !arHetPlace
$l MarDet/lace contendr. una inter%a* de integraci&n estandari*ada y de%inida
para poder entender el modelo de negocio de cada aplicaci&n, este ser. di%erente en cada
caso y por ello una de las maneras m.s optimas de integrar aplicaciones con un modelo
de negocio esta, as+ podr.n conocer los precios, si se o%recen licencias unitarias o por
paquetes, si tiene promociones y sus caracter+sticas, etc'
o Proporcionar nuestras interfaces al !arHetPlace
#"
$sta tarea va a resultar m.s o menos traum.tica en %unci&n de nuestro diseo y
arquitectura de partida' Como m+nimo de-emos proporcionar al MarDet/lace la inter%a*
de ((4 ya que de-er. )acer login a los usuarios contra nuestro sistema, pero tam-in
puede solicitarnos servicios relativos a la gesti&n de usuarios 8CMM: o %acturaci&n
8Filling:' Ca-e destacar que partimos de inter%aces O(,7 de-ido a nuestro diseo (4A
y por la tanto esta tarea no de-e causar impacto en nuestra implementaci&n'
g) =efinir el Road!ap de las aplicaciones
CesimedO( pasar. a ser un <(Is -asado en (aa(, como tal cualquier actuali*aci&n,
parc)e o me0ora de-e ser transparente para el usuario' /or ello es se considera muy @til para
causar -uena imagen al usuario' (i en cortos periodos de tiempo el cliente ve me0oras, notar. que
la aplicaci&n no est. a-andonada y por tanto el miedo a perder los datos alg@n d+a ser. menor'
;odos los procesos anali*ados anteriormente, se consideran una lista no cerrada para cada
caso de estudio, pero es lo su%icientemente genrica como para tomarla en cualquier desarrollo
-asado en (aa(' ,ado que este proyecto es de car.cter investigador y algunos aspectos
comentados pueden quedar %uera del alcance se muestra una ta-la con las actividades que se
llevaron a ca-o'
)abla - /roceso de adopci&n (aa(
:.* ,ntegracin sobre ,aa-
## Jos Manuel Arvalo Navarro
?na ve* )emos conseguido posicionar Cesimed(aa(, vamos a )acer uso de una
in%raestructura como servicio, )emos escogido Ama*on Oe- (ervices como proveedor de dic)o
servicio por varios motivos'
? 4%rece servicios para distintas plata%ormas 87inu9 y OindoHs:'
? 4%rece servicios para una variedad de lengua0es de programaci&n 80ava, 'net, p)p''etc':'
? ;iene una comunidad activa de desarrolladores y o%rece gran documentaci&n'
? (us servicios tienen una gran reputaci&n y llevan aos en el mercado'
$l motivo principal de adoptar <aa( es poder atender a la %luctuante demanda de
peticiones de servicio a Cesimed(aa(, para ello se considera necesario un gran esfuerzo en
conseguir una alta escalabilidad con unos costes de gestin pr&cticamente planos' Kracias a
obtener todos los recursos 0ard1are como un servicio% podremos olvidarnos de todos los
procesos de mantenimiento de infraestructura y centrarnos en la tarea que nos ocupa,
evolucionar Cesimed(aa(' 7os servicios y caracter+sticas computacionales que )emos usado del
proveedor de servicios de in%raestructura son:
? +C2 /+lastic Cloud :
1
:
$ste servicio nos proporcionar. elasticidad en nuestra in%raestructura gracias a las
m.quinas virtuales que nos proporciona, tam-in llamadas Ama*on Mac)ine <mages 8AM<s:' $l
ciclo de vida de cada una de las AM<s es el siguiente'

Ilustracin 16 Ciclo de vida Ama*on Mac)ine <mage KBL
$ntre los distintos tipos de instancias )emos escogido el modelo intermedio que o%rece
Ama*on pero que se adapta a nuestras necesidades, las caracter+sticas son las siguientes:
1
)ttp:WWs'ama*onaHs'comWec2GdoHnloadsWec2'Hsdl
#5
)abla 5 <nstancias est.ndar en Ama*on Oe- (ervices KBL
$9isten m.quinas de prop&sito espec+%ico pero para nuestro caso y la demanda que
esperamos se a0usta me0or el modelo est.ndar grande'
$n cuanto al (7A, es importante anali*ar el que nos proporciona Ama*on, las
caracter+sticas son las siguientes KBL:
=Ao de servicio> son los #" d+as anteriores a partir de la %ec)a de una reclamaci&n
de (7A'
$l =/orcenta0e de tiempo de actividad anual> se calcula restando a 1EER el porcenta0e
de periodos de " minutos durante el Ao de servicio en el que Ama*on $C2 se
encontr& en el estado de =Megi&n no disponi-le>' (i )a estado utili*ando Ama*on
$C2 durante un periodo de tiempo in%erior a #" d+as, su Ao de servicio seguir.n
siendo los #" d+as anteriores, pero se considerar. que los d+as anteriores a su uso del
servicio )an tenido una ,isponi-ilidad de regi&n del 1EER' ;odo tiempo de
inactividad que tenga lugar antes de una reclamaci&n de Crdito de servicio con 9ito
no podr. utili*arse para %uturas reclamaciones' 7as mediciones de /orcenta0e de
tiempo de actividad anual e9cluyen los tiempos de inactividad derivados de %orma
directa o indirecta de cualquier $9clusi&n de (7A de Ama*on $C2 (7A 8de%inido a
continuaci&n:'
=Megi&n no disponi-le> y =No disponi-ilidad de la regi&n> signi%ican que m.s de una
Xona de disponi-ilidad en la que est. e0ecutando una instancia, dentro de la misma
#6 Jos Manuel Arvalo Navarro
Megi&n, est. =No disponi-le> para usted'
=No disponi-le> signi%ica que todas sus instancias en e0ecuci&n no tienen
conectividad e9terna durante un periodo de cinco minutos, y que no podr. e0ecutar
instancias de sustituci&n'
?n =Crdito de servicio> es un crdito en d&lares, calculado tal y como se esta-lece a
continuaci&n, que podr+amos a-onar a una cuenta Ama*on $C2 que cumpliera
determinadas condiciones'
-i el Porcentaje de tiempo de actividad anual de un cliente de Amazon cae por debajo
del MM%M:N durante el a@o de servicio% dic0o cliente optar& a recibir un cr)dito de servicio
e$uivalente al 1LN de su factura 8e9cluyendo los pagos @nicos reali*ados por <nstancias
reservadas: durante el /eriodo de crdito apto'
? - /-imple -torage :
2
:
(e )a cre+do conveniente )acer uso de este servicio de almacenamiento para alo0ar las
distintas im.genes mdicas de nuestro sistema, son im.genes muy pesadas y este servicio nos
proporcionar. escala-ilidad en este aspecto'
$n cuanto a los precios, Ama*on cuenta con las siguientes tari%as:
)abla 6 /recios almacenamiento en ( KBL
$n principio vamos a )acer uso ilimitado del almacenamiento ya que cu.nto m.s
im.genes de-emos cargar, mayor es el uso que )acen los usuarios de nuestros servicio y
2
)ttp:WWs'ama*onaHs'comWsGdoHnloadsWs'Hsdl
#B
o-tendremos un alto retorno de la inversi&n' A continuaci&n se esquemati*a las instancias que
levantaremos de todos los servicios para Cesimed(aa('
/or @ltimo ca-e destacar algunos cam-ios importantes en el FacDG$nd de nuestro sistema
de partida' Como se )a e9plicado y se )a podido o-servar, el FacDG$nd aglutina-a toda la
%uncionalidad en un mismo m&dulo, si queremos integrarnos con otros sistemas y adoptar una
<aa(, es necesario modulari*ar las %uncionalidades de los servicios para desacoplarlos a@n m.s,
esto proporcionar. una gran %le9i-ilidad de integraci&n ya que de-emos tener en cuenta que
nuestro sistema de partida es (4A y eso nos dar. una gran venta0a'
7as im.genes )an sido sacadas de la -ase de datos y se )an introducido en el servicio de
almacenamiento para ganar en escala-ilidad' 7os m&dulos en los que se )a dividido son:
? 3illing4 (istema de %acturaci&n por uso de la aplicaci&n
? --O4 /rotocolo de autenticaci&n al sistema
? CR!4 Funcionalidad de gesti&n de usuarios
? ,mages Repositor#4 Almacenamiento de las im.genes mdicas
? 3acHend: /rocesamiento de im.genes'
Ilustracin 19 Arquitectura integraci&n <aa(
/or @ltimo, en la ta-la 5 detallaremos el coste de cada una de estas instancias mediante la
calculadora que nos proporciona Ama*on KBL' $n la @ltima secci&n de este cap+tulo se de%inir. un
an.lisis entre esta soluci&n -asada en <aa( %rente a disear nuestra propia soluci&n para o-tener
un entorno dedicado 'n(ouse'
51

)abla 9 Coste del caso de estudio
Ca-e destacar que algunos precios pueden verse incrementados con respecto a las ta-las
anteriores, pero de-emos tener en cuenta por e0emplo el caso de la -ase de datos, la cual viene
con la licencia y la instalaci&n del (27G(erver de Microso%t' ;am-in )emos aadido dos ipG
el.sticas para compra de nuestro dominio en internet, as+ como detalles en el anc)o de -anda de
entrada y salida con el datacenter situado en <rlanda de Ama*on'
:.: Ar$uitectura global del sistema e implicaciones de la integracin
Como resultados de las secciones anteriores, ya disponemos de un posicionamiento claro
dentro de Cloud Computing, de una de%inici&n clara de lo que va a ser nuestro modelo de
negocio y de una %uerte in%raestructura que nos proporcionar. elasticidad y escala-ilidad a
nuestro sistema' /ero se )an detectado algunos o-st.culos en la integraci&n del sistema con la
<aa( y con el MarDet/lace'
Obst&culos con la integracin del !arHetPlace
Como se )a comentado en los primeros cap+tulos, los proveedores de servicios -asados
en Cloud Computing, -ien sea, (aa(, /aa(, <aa(, necesitan estandari*ar su o%erta y sus
inter%aces, de lo contrario no podr+an responder a la demanda del servicio con las -ondades que
o%rece la nu-e' /or ello de-emos asumir que cualquier <(I que quiera integrarse con un
MarDet/lace de-e )acer un desarrollo adicional que consiste en implementar su contrato de
integraci&n 8O(,7:' Cracias a nuestro diseo de partida (4A y posterior modulari*aci&n del
sistema este impacto es menor de lo que podr+a ser con un sistema tradicional' $sta
implementaci&n se requiere para poder transmitir nuestro modelo de negocio al MarDetplace,
de-emos tener en cuenta que cada <(I tendr. su propio modelo de negocio' /or ello el
MarDet/lace solicita a travs de una inter%a* @nica y estandari*ada el modelo de negocio
concreto de cada aplicaci&n en el momento que el usuario desee comprarla'
$l @ltimo o-st.culo encontrado en esta parte del proceso de integraci&n es la de
proporcionar las inter%aces de autenticaci&n, de-emos tener en cuenta que cuando un usuario
quiera comprar la aplicaci&n y usarla, el MarDetplace de-e autenticar al usuario contra nuestro
sistema' /ero este o-st.culo no )a sido tal, ya que part+amos de un sistema -asado en (4A, con
inter%aces claramente de%inidas, tan solo es necesario proporcionar los endpoints al equipo de
desarrollo del MarDet/lace, por otro lado si %uera necesario podemos proporcionar m.s inter%aces
como Filling y CMM, por lo comentado anteriormente'
Obst&culos con la integracin la ,aa-
$l principal pro-lema encontrado en la integraci&n de la <aa( es el de adaptaci&n a sus
inter%aces, esto se ve muy claro con la migraci&n de las im.genes desde la -ase de datos al
servicio de almacenamiento (' A)ora de-emos acceder a ellas mediante servicios M$(; y ello
)a causado impacto en el FrontG$nd ya que la inter%a* de comunicaci&n es totalmente di%erente'
$ste )ec)o es -astante sintom.tico de lo que es Cloud Computing, ya que si )u-iera sido
la <aa( la que se )u-iera tenido que adaptar a nosotros, no estar+amos realmente ante un servicio
en la nu-e, no s si estar+amos ante algo me0or o peor, pero no ser+a Cloud Computing' ,e-emos
tener en cuenta que en este caso Ama*on Oe- (ervices tiene todo un reto por delante de-ido al
tipo de servicio que o%rece y esto no ser+a posi-le si no estandari*a su o%erta e inter%aces tal y
como pasa-a con el MarDet/lace' A continuaci&n se muestra la arquitectura glo-al del sistema'
5
Ilustracin 1; Arquitectura %inal integraci&n MarDetplace
/or @ltimo se )a reali*ado un an.lisis comparativo de los costes de toda la soluci&n
llevada a ca-o, tanto la adopci&n de un modelo (aa( como la integraci&n con una <aa(, %rente a
los costes que supondr+a no )a-er escogido Cloud Computing y )a-er optado por una soluci&n
dedicada inG)ouse'
)abla ; An.lisis de costes Cloud Computing %rente soluci&n inG)ouse
,e esta ta-la se pueden sacar varias conclusiones' 7a primera est. claramente que se
puede o-servar el alto coste inicial de los recursos )ardHare en mi in%raestructura interna %rente a
los costes planos de una <aa( y un coste mensual de ese gasto energtico que provocan mis
instalaciones' (in em-argo los riesgos ser.n muc)o menores, de-ido a esa alta inversi&n en
%ireHalls y seguridad que no proporciona una <aa( p@-lica'
7a segunda gran conclusi&n de esta ta-la, es el alto coste que )a ocasionado migrar
nuestro modelo de negocio a (aa(, ya que a)ora de-emos a%rontar soporte y mantenimiento, ya
que estamos o%reciendo un servicio' (in em-argo en un modelo de so%tHare tradicional esto no
tiene por qu ser as+' Ca-e destacar comparando inversiones, se tardar+a unos oc)os aos en
llegar al gasto que tiene una soluci&n interna, sin em-argo esta, estar+a diseada y pensada
totalmente por el cliente, no como en la <aa( en la que el usuario m.s que disear su soluci&n,
escoge entre lo que le o%recen'
5"
Captulo .:
Conclusiones y tra#a/os $uturos
6 Conclusiones y tra5a7os futuros
A continuaci&n se entrar. a descri-ir las conclusiones o-tenidas del actual tra-a0o,
o-0etivos conseguidos 8o no conseguidos:, as+ como venta0as que se )an o-servado y o-st.culos
encontrados' /or @ltimo se reali*ar. una serie de propuestas de proyectos como posi-les tra-a0os
%uturos'
A.1 Conclusiones
$ste proyecto de %in de master propon+a reali*ar un estudio detallado acerca de la
situaci&n real del paradigma de Cloud Computing tanto desde un punto de vista tecnol&gico, para
lo que se )a incluido un estudio de sus principios centrados en las con%iguraciones
arquitect&nicas m.s )a-itualesA como desde un punto de vista de negocio, incluyendo re%erencias
y comentarios acerca de las plata%ormas de implementaci&n o%recidas por algunas de las
compa+as que actualmente m.s est.n apostando por este paradigma'
/or otro lado, se esta-leci& como o-0etivo complementario, la implementaci&n y
despliegue de un supuesto pr.ctico 8Cesimed: so-re una arquitectura de Cloud real' /ara ello, se
)a posicionado Cesimed en un modelo (aa(, con el %in de potenciar sus posi-ilidades de
negocio' A tal %in, se )a reali*ado un an.lisis de que procesos y tareas )acen %alta en cualquier
integraci&n en la nu-e, lo que nos )a resultado muy @til como )o0a de ruta en nuestro caso de
estudio'
Adem.s, con la reali*aci&n de este proyecto )emos o-tenido una in%raestructura con
unos costes de gestin # mantenimiento $ue son pr&cticamente planos # $ue 0emos
aumentado dr&sticamente la escalabilidad de nuestro sistema' (in em-argo, en cuanto a la
integraci&n para integrar Cesimed en -aa-% nos 0a introducido una carga de trabajo que antes
no ten+amos, toda la parte de operaciones que nos a)orr.-amos con la <aa(, a)ora como somos
el proveedor del servicio recae so-re nosotros'
/or el contrario )emos tenido que pagar un precio muy caro% las interfaces de nuestro
sistema actual 0an debido ser adaptadas a la ,aa-, de no )a-er sido as+, no )u-iramos estado
ante una <aa( real, si la <aa( es la que se tiene que adaptar a tus sistemas entonces no estamos
)a-lando de un entorno -asado en Cloud computing' Kracias a $ue nuestro sistema de partida
estaba basado en -OA el esfuerzo de esta integracin 0a sido m"nimo'
55
A.2 5rabajos futuros
(e )a conseguido un nuevo )ito en este proyecto que se inici& con el proyecto %in de
carrera cuya evoluci&n )a dado lugar a esta tesis %in de master' /ero estudiar Cloud Computing
no )a )ec)o si no dar m.s ideas y oportunidades para seguir aumentando nuestros conocimientos
y e9plorar nuevas v+as de desarrollo'
$sta secci&n propone una serie de proyectos para quin le pudiera gustar proponerlo a sus
alumnos como posi-les proyectos %in de carrera o investigaci&n interna'
!igracin de 0erramientas de modelado 0acia una apro8imacin Paa- ' 7a
primera propuesta es poder aprovec)ar todas las caracter+sticas de /aa(, migrando
)erramientas desarrolladas internamente en el Yy-ele, -asadas M,A como por
e0emplo Arc)imedes K1L )acia un modelo de /aa('
=esarrollo de un sistema de fic0eros distribuido en la nube /O#bele3o8) ' 7a
idea es poder simular una )erramienta como ,ropFo9, teniendo claros los
conceptos vistos en este tra-a0o y de%iniendo un alcance del proyecto se puede
desarrollar este proyecto con %rameHorDs de desarrollo de sistemas de %ic)eros
como ,oDan 8)ttp:WWdoDanGdev'netWenW: o Sadoop 8)ttp:WW)adoop'apac)e'orgW:'
%eferencias
K1L Ant)ony $. Velte, $oby +. Velte, &loud &omputing a practical approac), /001.
K2L 2ob o3ano, *xecutive4s guide to &loud &omputing, /050
KL 6r 7ar! ' 8illiams, A 9uic! start guide to &loud &omputing, moving your business into t)e cloud
/050
K!L 2arrie Sosins!y, &loud &omputing bible, /055.
K"L &loud Application Arc)itectures: 2uilding Applications and 'nfrastructure in t)e &loud ;$)eory in
Practice ;<="eilly>> by George "eese ;Paperbac! ? Apr 50, /001>
K#L Programming Ama3on 8eb Services: S@, *&/, SAS, %PS, and Simple62 by +ames 7urty ;Paperbac!
? Apr 5, /00B>
K5L &loud &omputing SaaS And 8eb Applications Specialist evel &omplete &ertification Cit ? Soft#are
As A Service Study Guide 2oo! And <nline &ourse ? Second *dition by 'van!a 7en!en and Gerard
2lo!dij! ;Paperbac! ? Sep D, /050>
K6L 6emystifying t)e Virtual 6es!top: Starting #it) 6es!top Virtuali3ation by 7ic)ael %ox ;Paperbac!
? <ct @0, /050>
KBL Ama3on 8eb Services, )ttp:WWaHs'ama*on'comWdocumentationW' @ltimo acceso /0E0FE/055
K1EL $)omas *rl. S<A &oncepts, tec)nology and design, /00B
K11L +os 7anuel Arvalo, 7igraci-n de un sistema de informaci-n basada en S<A con un aproximaci-n
basada en 76A.
K12L 7arcos ope3 San3, Arc)imedes: A Service <riented %rame#or! for 7odel 6riven 6evelopment of
Soft#are, /055
K1L $)omas *arl, S<A #it) .G*$ and 8indo#s A3ure, /001
K1!L 6avid it)ium &loud &omputing and S<A &onvergence in Hour *nterprise: A Step?by?Step Guide,
/00B
K1"L +efrrey (anson, 7as)ups Strategies for t)e modern *nterprise, /00D
K1#L Microso%t OindoHs A*ure )ttp:WWmsdn'microso%t'comWenGusWli-raryWgg!#"B#'asp9, ultimo acceso
50E0@E/055
K15L Steve 8eber, Sell on Ama3on: A Guide to Ama3on=s 7ar!etplace, Seller &entral, and %ulfillment by
Ama3on Programs
K16L Servidores(P )ttp:WW)1EE1E'HHH1')p'comWHHpcWesWesWsmWOFE#aW5EBB!"G5EBB!"G51E1E2G
52256BG52256BG!16#!2')tml Iltimo acceso /5E0JE55
K1BL Almacenamiento )ttp:WW)1EE1E'HHH1')p'comWHHpcWesWesWsmWOFE2aW121#BG5B6"E2GB"!#2#')tml
Iltimo acceso /5E0JE55
K2EL "esto de productos (P )ttp:WWHHH6')p'comWesWesW)ome')tml Iltimo acceso /5E0JE55

Cloud Computing Fundamentos, Diseño y Arquitectura

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Cloud Computing Fundamentos, Diseño y Arquitectura

Enviado por

Direitos autorais:

Formatos disponíveis

Cloud Computing: Fundamentos, diseo y arquitectura aplicados a un caso de estudio

Você também pode gostar