UNIVERSIDAD NACIONAL DEL

CENTRO DEL PERU

FACULTAD DE INGENIERIA DE SISTEMAS

TESIS

MIGRACIÓN DE APLICACIONES COLABORATIVAS IN-

HOUSE A UN ENTORNO VIRTUAL BASADO EN LA NUBE
PARA MEJORAR EL SERVICIO DEL ESPACIO
COLABORATIVO INTEGRADO DE INVESTIGACIÓN EN EL
CENTRO INTERNACIONAL DE LA PAPA

PRESENTADO POR:
CÓRDOVA SOLÍS, Raúl Ángel

TESIS PARA OPTAR EL TÍTULO PROFESIONAL DE:

INGENIERO DE SISTEMAS

HUANCAYO – PERU
2012
 ASESOR:

Ing. Richard Mercado Rivas

ii
 AGRADECIMIENTOS:

AGRADEZCO A DIOS
Por darme el regalo de la vida y la oportunidad de seguir
compartir gratos momentos con las personas que más quiero y
seguir desarrollándome en mi carrera.

A MIS PADRES
Por el ejemplo y ayuda incondicional desde siempre,
a mis hermanos por su ayuda y consejos, y a toda mi familia
por ser mi aliento e inspiración para ser cada vez mejor.

A MI ALMA MATER
Por haberme guiado en el camino de mi carrera profesional,
a mis profesores por sus consejos y enseñanza, y a mi asesor por
su apoyo en el desarrollo de la presente investigación.

AL CENTRO INTERNACIONAL DE LA PAPA

Por darme la oportunidad de crecer profesionalmente, a Reinhard Simon
por compartir su conocimiento, a Mirella Flores
por su ayuda trabajando en equipo y a todo
el equipo de RIU por su colaboración.

iii
Dedicatoria:

A mi familia, mi madre Dina, mi padre

Porfirio y mis hermanos Milagros y Miguel,
quienes siempre han estado y siguen
estando a mi lado ayudándome a seguir
adelante personal y profesionalmente.

iv
 RESUMEN

La presente tesis titulada “Migración de aplicaciones colaborativas in-house a un entorno

virtual basado en la nube para mejorar el servicio del espacio colaborativo integrado de
investigación en el Centro Internacional de la Papa” ha surgido como respuesta ante la
notable ralentización de los accesos de los usuarios desde las oficinas regionales del CIP, el
problema principalmente se presentó en las oficinas ubicadas en África, donde se obtuvieron
tiempos de carga y de acceso muy altos, generando por consiguiente una poca colaboración
del personal del CIP ubicados en las regiones lejanas geográficamente de la sede central de
Lima y por consiguiente se registraron niveles de satisfacción lejos de lo ideal. Según la
bibliografía consultada y diversos estudios realizados mencionan la capacidad de la
computación en la nube de brindar soluciones que son reflejados en el corto tiempo y con
bajos niveles de inversión, entre los principales beneficios está la mejora de performance, la
flexibilidad y la capacidad de escalar horizontal y verticalmente.
La metodología utilizada es una variante hecha por el autor a las metodologías utilizadas en
la migración hacia software libre, sin embargo se trata de una metodología flexible que
permite adaptaciones según el grado de automatización de la plataforma tecnológica y de la
infraestructura existente. Finalmente el proceso de migración se realizó siguiendo las fases
planteadas en esta metodología logrando reducir el tiempo de acceso desde África en casi
40 veces, triplicándose el número de visitas globales, mientras que el número de visitantes
aumento en un 33% y el número de retorno de los colaboradores al espacio colaborativo se
cuadruplicó según las evaluaciones realizadas en los primeros meses de funcionamiento en
la nube, esto permitió que el nivel de satisfacción de los colaboradores llegue a un 85% de
los usuarios que están satisfechos y altamente satisfechos. Sin embargo es importante tener
en cuenta que para que esto sea constante en el tiempo se necesita adoptar políticas
institucionales que favorezcan el espíritu colaborativo a fin de poder mejorar la comunicación
y la capacidad de colaboración.

v
 ABSTRACT

This thesis entitled "Migration of collaborative applications in-house to a virtual environment

based on the cloud to improve the service of integrated collaborative space research in the
International Potato Center" emerged in response to the notable slowdown of users
accesses from CIP regions quarters , the main problem has appeared in Africa offices, where
we obtained high load times and server slow access, this problems caused a small
participation of CIP staff located in geographically distant regions Lima headquarters and
therefore satisfaction levels were far from ideal. Several studies mention the ability of cloud
computing to deliver solutions that are achieved in a short period of time and with low levels
of investment. The benefits are flexibility, the improve of performance, and the ability to scale
horizontally and vertically.
The methodology used is a variant made by the author of the methodologies used in the
migration to free software, however is a flexible methodology, which allows adjustments to
the degree of automation technology platform and infrastructure. Finally, the migration was
raised in stages following the methodology proposed by the author, managed to cut the
server slow access in Africa almost 40 times, tripling the number of visits, the number of
visitors to collaborative space increased by 33% and the number return of employees
quadrupled as assessed in the first months of operation in the cloud.

vi
 ÍNDICE
Pág.
ASESOR ii
AGRADECIMIENTOS iii
DEDICATORIA iv
RESUMEN v
ABSTRACT vi
ÍNDICE vi

CAPITULO I
GENERALIDADES
1.1 PLANTEAMIENTO DEL PROBLEMA 3
1.2 FOMULACIÓN DEL PROBLEMA 12
1.3 OBJETIVO DE LA INVESTIGACIÓN 12
1.4 JUSTIFICACIÓN DE LA INVESTIGACIÓN 12
1.5 HIPÓTESIS 13
1.6 DISEÑO METODOLÓGICO 15
1.6.1 Nivel y Tipo de investigación 15
1.6.2 Método y Diseño de la investigación 15
1.6.3 Población y Muestra 16
1.6.4 Técnica de recolección de la información 16
1.6.5 Instrumentos de la investigación 16
1.6.5 Fuentes y Técnicas para la recopilación de información 16

CAPITULO II
MARCO DE REFERENCIA
2.1 ANTECEDENTES 18
A1. Saleem, Rehan (2011). Cloud Computing’s effect on Enterprises in terms of Cost and
Security. Tesis de Maestría. Universidad de Lund. Suecia. 18
A2. Gaikwad, Manisha (2011). EC2LAB: SAAS using Amazon elastic Cloud Compute. Tesis
de Maestría. Universidad Estatal de San José. Estados Unidos. 19
A3. Sobotta, Adrian (2008). Enhancing the agility promoting benefits of service-orientation
with Utility Computing. Tesis de Maestría. Universidad de Copenhague. Dinamarca. 20
A4. Mark-Shane, Scale (2010). Assessing the Impact of Cloud Computing and Web
Collaboration on the Work of Distance Library Services. Artículo de Investigación de
Maestría. Universidad de las Indias Occidentales. Jamaica. 21
A5. Han, Yan (2011). Cloud Computing: Case Studies and Total Costs of Ownership.
Artículo de Investigación. Universidad de Arizona. Estados Unidos. 21
2.2 MARCO TEÓRICO 22
2.2.1 Virtualización 22
2.2.2 Computación en la nube 24
2.2.2.1 Un nuevo paradigma 24
2.2.2.2 Atributos de la nube 25
2.2.2.3 Modelos de infraestructura 26
2.2.2.4 Cualidades sistémicas de la nube 27
2.2.2.5 Obstáculos para la adopción generalizada 28
2.2.2.6 Tendencias de la computación en la nube 29
2.2.3 Modelos de servicio de la computación en la nube 30
2.2.3.1 Aplicaciones empresariales (SaaS) 30
2.2.3.2 Herramientas para desarrolladores (PaaS) 31
2.2.3.3 Recursos de infraestructura (IaaS) 31
vii
2.2.4 Niveles de valor de la computación en la nube 32
2.2.4.1 Nivel de utilidad 34
2.2.4.2 Nivel de transformación de procesos 34
2.2.4.3 Nivel de innovación del modelo de negocio 35
2.2.5 Filosofía de la Web 2.0 36
2.2.5.1 Espacios colaborativos en la actualidad 37
2.2.5.2 Atlassian Confluence 38
2.2.5.3 Atlassian JIRA 38
2.3 MODELO APLICATIVO 39
2.4 MARCO CONCEPTUAL 43

CAPITULO III
INTERVENCIÓN METODOLÓGICA
3.1 FASE 1: PLANEAMIENTO GENERAL DE LA MIGRACIÓN 46
3.1.1 Sensibilización organizacional 46
3.1.2 Organización de grupos de trabajo y responsabilidades 47
3.2 FASE 2: DIAGNÓSTICO DEL ESTADO ACTUAL 48
3.2.1 Diagnóstico de la infraestructura física actual 49
3.2.2 Diagnóstico de la configuración actual de los servidores 50
3.2.3 Diagnóstico de las actuales aplicaciones colaborativas 51
3.2.4 Diagnóstico del motor de base de datos actual 52
3.3 FASE 3: EVALUACIÓN DE ALTERNATIVAS DE MIGRACIÓN 53
3.3.1 Evaluación general de Cloudbuilder 54
3.3.2 Evaluación general de RackSpace Cloud 55
3.3.3 Evaluación general de Amazon Elastic Compute Cloud 57
3.3.4 Selección del proveedor y capacidad informática en el Cloud Computing 58
3.4 FASE 4: CONFIGURACIÓN Y PRUEBA DE LA NUEVA INFRAESTRUCTURA 59
3.4.1 Creación de las nuevas Instancias 59
3.4.2 Configuraciones de seguridad 62
3.4.3 Instalación de los principales servicios 63
3.4.4 Acceso al servidor virtual 65
3.4.5 Configuración, acceso y envío de la base de datos 67
3.4.6 Pruebas de funcionamiento 70
3.5 FASE 5: MIGRACIÓN DEL ESPACIO COLABORATIVO 70
3.5.1 Notificación a los colaboradores 70
3.5.2 Ejecución de script de transferencia 71
3.5.3 Comprobación de integridad de base de datos 71
3.5.3.1 A nivel de estructura 71
3.5.3.2 A nivel de datos 72
3.5.4 Configuración de Confluence y JIRA 73
3.5.4.1 Configuraciones Generales 73
3.5.4.2 Configuraciones de certificado de seguridad SSL 74
3.5.4.3 Configuración proxy Apache 75
3.5.5 Inicializar los servicios colaborativos 76
3.5.5.1 Actualización de plugin 78
3.5.5.2 Configura la autentificación vía LDAP 78
3.5.5.3 Configuraciones finales 79
3.5.5.4 Reindexamiento del contenido 80
3.5.6 Comprobación de la migración 81
3.6 FASE 6: SOPORTE Y MONITOREO 84
3.7 FASE 7: DOCUMENTACIÓN 84

CAPITULO IV
ANALISIS y DISCUSIÓN DE RESULTADOS
4.1 ANÁLISIS DE RESULTADOS 86
4.1.1 Análisis del rendimiento del servidor de Java en la nube 86
4.1.2 Análisis del rendimiento del servidor de MySQL en la nube 91
viii
4.1.3 Análisis del rendimiento del espacio colaborativo integrado 92
4.1.4 Análisis de los resultados de la actividad del espacio colaborativo 96
4.1.5 Análisis de los resultados de los accesos del espacio colaborativo 101
4.1.6 Análisis de los resultados de la satisfacción de los usuarios 104
4.2 PRUEBA DE HIPÓTESIS 106
4.3 DISCUSIÓN DE RESULTADOS 107
4.3.1 Rendimiento del servidor de Java en la nube 107
4.3.2 Rendimiento del servidor de MySQL en la nube 107
4.3.3 Rendimiento del espacio colaborativo integrado 108
4.3.4 Evaluación de la actividad del espacio colaborativo 108
4.3.5 Evaluación de los accesos al espacio colaborativo 109
4.3.6 Resultados de la satisfacción de los usuarios 110

CONCLUSIONES 111
RECOMENDACIONES 112
REFERENCIAS 113
ANEXOS 115

ix
 ÍNDICE DE TABLAS Y FIGURAS

ÍNDICE DE TABLAS

CAPITULO I
GENERALIDADES
Tabla Nº 1.1. Comparación de evaluaciones de acceso desde Ámsterdam 8
Tabla Nº 1.2. Comparación de tiempos de descarga desde Nairobi 10
Tabla Nº 1.3. Variables de estudio 14
Tabla Nº 1.4. Operalización de las variables 14

CAPITULO II
MARCO DE REFERENCIA
Tabla Nº 2.1. Niveles de valor de la computación en la nube 33

CAPITULO III
INTERVENCIÓN METODOLÓGICA
Tabla Nº 3.1. Organización de grupos de trabajo y responsabilidades 48
Tabla Nº 3.2. Diagnóstico de la Infraestructura actual 49
Tabla Nº 3.3. Diagnóstico de la configuración actual 51
Tabla Nº 3.4. Diagnóstico de las aplicaciones colaborativas 52
Tabla Nº 3.5. Diagnóstico del motor de base de datos 53

CAPITULO IV
ANALISIS y DISCUSIÓN DE RESULTADOS
Tabla Nº 4.1. Estadísticas de tráfico en la red del servidor MySQL 91
Tabla Nº 4.2. Estadísticas de consultas del servidor MySQL 92
Tabla Nº 4.3. Comparación de ‘grados’ y tiempos de descarga desde Ámsterdam 93
Tabla Nº 4.4. Evaluación tiempo de carga y respuesta desde varios países 95
Tabla Nº 4.5. Informe de actividad de servidor in-house (anterior) 97
Tabla Nº 4.6. Informe de actividad de servidor en la nube 98
Tabla Nº 4.7. Principales ciudades de conexión al servidor Java in-house 102
Tabla Nº 4.8. Número de visitas y visitantes por continente 103
Tabla Nº 4.9. Comparación de variables antes y después de la migración 106

ÍNDICE DE FIGURAS
CAPITULO I: GENERALIDADES
Gráfico Nº 1.1. Ubicación de las oficinas regionales y de enlace del CIP 4
Gráfico Nº 1.2. Principales componentes para la acreditación ISO 17025 5
Gráfico Nº 1.3. Principales problemas percibidos del servicio colaborativo 6
Gráfico Nº 1.4. Percepción del tiempo de acceso al servicio colaborativo 7
Gráfico Nº 1.5. Comparación de tiempos de descarga desde Nairobi – Kenia 9
Gráfico Nº 1.6. Infraestructura del servidor actual “Calypson” 10
Gráfico Nº 1.7. Mapa Global de conectividad 11
x
CAPITULO II: MARCO DE REFERENCIA
Gráfico Nº 2.1. Roles de los proveedores del Cloud Computing 32
Gráfico Nº 2.2. Comparación de metodologías de migración 40
Gráfico Nº 2.3. Metodología de migración utilizada 43

CAPITULO III: INTERVENCIÓN METODOLÓGICA

Gráfico Nº 3.1. Panel de administración de Tomcat - Apache 50
Gráfico Nº 3.2. Panel de Control de Cloudbuilder 55
Gráfico Nº 3.3. Panel de Control de RackSpace Cloud 56
Gráfico Nº 3.4. Zonas de disponibilidad de Amazon Cloud Computing 57
Gráfico Nº 3.5. Panel de Control de Amazon Cloud Computing 58
Gráfico Nº 3.6. Selección de la región para creación de servidor virtual en AWS 60
Gráfico Nº 3.7. Selección del AMI de la nueva instancia en AWS 60
Gráfico Nº 3.8. Selección del tipo de instancia y zona de disponibilidad en AWS 61
Gráfico Nº 3.9. Creación y descarga de la clave pública/privada en AWS 61
Gráfico Nº 3.10. Creación de las instancias virtuales en AWS 62
Gráfico Nº 3.11. Configuración de seguridad de los servidores en AWS 62
Gráfico Nº 3.12. Acceso al servidor Java-Server-EU 63
Gráfico Nº 3.13. Características del CPU del servidor 63
Gráfico Nº 3.14. Verificando correcta instalación de Java 64
Gráfico Nº 3.15. Comprobación de funcionamiento del servicio de MySQL 65
Gráfico Nº 3.16. Acceso vía WinSCP al servidor Java-Server-EU 66
Gráfico Nº 3.17. Etapas del script de transferencia de archivos 68
Gráfico Nº 3.18. Comparación de estructuras de las bases de datos origen y destino 68
Gráfico Nº 3.19. Comparación a nivel de datos de las bases de datos origen y destino 69
Gráfico Nº 3.20. Comprobación de integridad de estructura de BDs de Confluence 72
Gráfico Nº 3.21. Comprobación de integridad de datos de BDs de JIRA 73
Gráfico Nº 3.22. Certificado de seguridad otorgado por GoDaddy 74
Gráfico Nº 3.23. Procesos y puerto utilizados por el servidor 76
Gráfico Nº 3.24. Página inicial de Confluence 77
Gráfico Nº 3.25. Página inicial de JIRA 77
Gráfico Nº 3.26. Comprobación de actualización de plugin en JIRA 78
Gráfico Nº 3.27. Configuración de LDAP en Confluence 79
Gráfico Nº 3.28. Configuración y prueba de envío de mail 80
Gráfico Nº 3.29. Re-indexamiento en Confluence y Jira 81
Gráfico Nº 3.30. Detección de nuestro proveedor en la nube 81
Gráfico Nº 3.31. Ubicación de nuestro servidor virtual 82
Gráfico Nº 3.32. Instancias de los servidores virtuales 82
Gráfico Nº 3.33. Nueva infraestructura de los servidores en la nube 83

CAPITULO IV: ANALISIS y DISCUSIÓN DE RESULTADOS

Gráfico Nº 4.1. Monitoreo del consumo máximo de CPU 87
Gráfico Nº 4.2. Monitoreo del consumo promedio de CPU 87
Gráfico Nº 4.3. Consumo porcentual de CPU con JavaMelody 88
Gráfico Nº 4.4. Consumo utilizada de memoria RAM del servidor con JavaMelody 89
Gráfico Nº 4.5. Consumo real de memoria RAM de Confluence con JavaMelody 89
Gráfico Nº 4.6. Consumo de memoria RAM actual de Confluence 89
Gráfico Nº 4.7. Consumo de memoria RAM de JIRA con JavaMelody 90
Gráfico Nº 4.8. Consumo de memoria RAM actual de JIRA 91
Gráfico Nº 4.9. Resumen de evaluación de Confluence desde Ámsterdam 93
Gráfico Nº 4.10. Resumen de evaluación de JIRA desde Ámsterdam 94
Gráfico Nº 4.11. Rendimiento de páginas de Confluence y JIRA 96
Gráfico Nº 4.12. Visitantes diarios al servidor Java in-house 97
Gráfico Nº 4.13. Visitantes mensuales al servidor Java in-house 98
Gráfico Nº 4.14. Visitantes diarios al servidor Java en la nube 99
Gráfico Nº 4.15. Visitantes mensuales al servidor Java en la nube 99
xi
Gráfico Nº 4.16. Visitas y visitantes mensuales totales al espacio colaborativo 100
Gráfico Nº 4.17. Visitantes mensuales al espacio colaborativo 100
Gráfico Nº 4.18. Visitantes por país de origen al servidor Java in-house 101
Gráfico Nº 4.19. Visitantes por país de origen al servidor Java en la nube 102
Gráfico Nº 4.20. Percepción de velocidad del espacio colaborativo 104
Gráfico Nº 4.21. Satisfacción del servicio del espacio colaborativo 105

xii
 INTRODUCCION

En los tiempos actuales donde el conocimiento tiene un gran beneficio invaluable para todas
las Organizaciones, la gestión de los espacios colaborativos cobra un rol importante ya que
se convierte en uno de los principales espacios de encuentro común entre los colaboradores
y a la vez representa un desafío ya que se debe mantener un ambiente rápido, ágil y de fácil
acceso para todos los colaboradores para poder mantener una comunicación efectiva entre
los mismos, motivo por el cual se desarrolló la presente investigación para mejorar el
servicio del espacio colaborativo del Centro Internacional de la Papa, la cual tiene la
siguiente estructura:
En el primer capítulo titulado Generalidades se detalla el estado actual del servicio
colaborativo, donde se muestran las evidencias encontradas que indican la existencia del
problema, tratando en la medida posible de cuantificarlos para tener indicadores numéricos
que reflejen la magnitud y naturaleza del problema, las fuentes utilizadas son tanto internas
a partir de los propios archivos de registro del servicio y encuestas realizadas a algunos
colaboradores como también se tiene información externas que se obtuvo luego de un
proceso de auditoría. La formulación del problema incluye el objetivo que se trata de
conseguir en la presente tesis, también se explica las justificaciones teóricas, metodológicas
y prácticas en las cuales se respalda la presente investigación, llegando a formular la
hipótesis y finalmente se detalla el diseño metodológico de la presente investigación.
En el segundo capítulo denominado Marco de Referencia, se presenta las investigaciones
relacionadas a la presente tesis, existen diversos libros y artículos que sustentan el estudio
sobre computación en la nube y espacios colaborativos, la bibliografía consultada afirma que
el potencial de la informática en la nube es real e inmediato ya que tiene la capacidad de
ofrecer flexibilidad y control de los gastos mediante un modelo de servicio modular
construido sobre la base de una plataforma común, resultando muy atractivo para las
Organizaciones. El modelo aplicativo es una variante personal de las ya existentes y usadas
en las comunidades de software libre y finalmente el marco conceptual comprende los
principales términos asociados al trabajo, poniendo énfasis en la computación en la nube
debido a lo nuevo de su terminología y confusión existente.
En el tercer capítulo Intervención Metodológica, se desarrolla las fases de la metodología
sobre migración a la nube propuesta por el autor, esta metodología esta estructurada en
seis fases idealmente ejecutadas una a continuación de otra, sin embargo dependiendo de
los diferentes escenarios cabe que en algún momento se desarrollen algunas fases de
manera paralela, existen también fases que son transversales como la fase de
documentación. Además es recomendable saber que para cada caso particular se puede
otorgar a cada fase de la metodología el esfuerzo que se considere necesario dependiendo
de la plataforma tecnológica y de la infraestructura existente, también es flexible para que
1
cada Organización pueda efectuar reajustes o realizar procesos con mayor nivel de detalle
dependiendo de la complejidad de su plataforma tecnológica y de los recursos que se
asignen.
En el cuarto y último capítulo denominado Análisis y Discusión de resultados se explicar los
resultados obtenidos y se compara estos valores con la información previa, obtenida antes
de la migración. Es una evaluación crítica de los resultados tomando en consideración la
situación inicial y la final de las variables utilizadas en la metodología de la investigación, el
orden de los mismos está en dependencia lógica del modelo. En primer lugar se aborda
diferentes análisis de rendimiento antes y después de la migración de las aplicaciones
colaborativas integradas y posteriormente se compara información de actividad y de
percepción del servicio del espacio colaborativo integrado, logrando identificar los beneficios
en los primeros 3 meses de funcionamiento, siendo en algunos casos plenamente
reconocidos por los colaboradores.
Se finaliza con las Conclusiones y Recomendaciones, siendo la conclusión más importante
que los beneficios de la migración del espacio colaborativo integrado a un ambiente virtual
basado en la nube es real y los resultados se reflejan a los pocos meses después de la
migración, se ha conseguido reducir el tiempo de carga completo a menos de 12 segundos
desde cualquier parte del mundo en condiciones normales de conexión y se ha logrado
duplicar la percepción de satisfacción del servicio, llegando a un 85% de usuarios
satisfechos y altamente satisfechos con el servicio del espacio colaborativo integrado.

Raúl Ángel Córdova Solís

2
 CAPITULO I
GENERALIDADES

En el presente capitulo se detalla las evidencias encontradas que prueban la existencia del
problema en el servicio del espacio colaborativo integrado de investigación del Centro
Internacional de la Papa, se ha tratado en la medida posible de mostrar valores cuantitativos
que respalden la misma, luego se formula el problema y objetivo general que se espera
lograr, también se explica las justificaciones teóricas, metodológicas y prácticas en las
cuales se respalda la presente investigación, llegando a formular la hipótesis y finalmente se
detalla el diseño metodológico de la presente investigación.

1.1 PLANTEAMIENTO DEL PROBLEMA

El Centro Internacional de la Papa (CIP, por sus siglas en español) es el mayor centro en
el mundo dedicado a la investigación científica en tubérculos y raíces andinas. El CIP
tiene por objetivo disminuir la pobreza y alcanzar la seguridad alimentaria en los países
en desarrollo mediante la investigación científica y actividades relacionadas con el
estudio de papa, camote y otras raíces y tubérculos andinos.
El CIP es miembro del Grupo Consultivo sobre Investigación Agrícola Internacional
(CGIAR), el CGIAR es una alianza mundial que reúne a 15 centros internacionales de
investigación en estrecha colaboración con cientos de organizaciones asociadas,
incluidos los institutos de investigación nacional y regional, las organizaciones de la
sociedad civil, academias y sector privado.
El CIP tiene como sede la ciudad de Lima, pero existen sedes de investigación alrededor
del mundo, así podemos mencionar la oficina de CIP - Quito en Ecuador y la sede
regional en el África subsahariana que se encuentra en Nairobi - Kenia, los científicos del
CIP también se encuentran trabajando en Uganda, Malawi, Mozambique, Angola y
Benín, personal de casi 30 países de Asia, África, Europa, Oceanía y América Latina
investigan e intercambian constantemente información sobre todas las variedades de
papa actualmente existentes en el mundo, en el Gráfico Nº 1.1 se muestra las
ubicaciones de todas las oficinas a nivel mundial.

3
 Gráfico Nº 1.1
Ubicación de las oficinas regionales y de enlace del CIP

Fuente: Centro Internacional de la Papa

Elaboración: Centro Internacional de la Papa

Como se aprecia en el gráfico Nº 1.1 el CIP tienen presencial a nivel mundial, las sedes
regionales están separados por grandes distancias y la comunicación y las herramientas
de comunicación y colaboración son de vital importancia ya que existen pocos espacios
donde pueden concurrir profesionales de los diferentes países y de diferentes disciplinas
científicas, además es importante mencionar que también existe comunicación con los
otros centro de investigación pertenecientes al consorcio del CGIAR.
El CIP tiene como principal herramienta colaborativa de investigación el software
comercial conocido como “Confluence” (desarrollada por la empresa australiana
Atlassian), ésta herramienta permite la creación colaborativa de contenido y ayuda a
crear, compartir y conversar conjuntamente sobre proyectos, ideas, especificaciones,
mockups, diagramas y ficheros. Atlassian tiene licencias comunitarias gratuitas que
están diseñados para las Organizaciones no lucrativas e instituciones benéficas que no
tengan fines de lucro como es el caso del CIP.
El uso de esta aplicación colaborativo en el CIP son amplias, uno de los espacios de
colaboración más usados es el sitio de Acreditación ISO del CIP, que es donde se
muestra información relacionada con la norma ISO 17025, que es una norma de calidad
a nivel mundial que establece normas para la competencia técnica de un laboratorio. La
acreditación ISO ofrece una garantía para los usuarios de los bancos de germoplasma
del CIP que cualquier material que recibe (como pequeñas plántulas in vitro) es de la

4
más alta calidad y libre de cualquier plaga o enfermedad, el complejo del CIP alberga el
más grande banco de germoplasma in vitro del mundo ya que mantiene 7180 variedades
de papa (2248 de las cuales son silvestres y 4732 son variedades de papas andinas),
8026 variedades de camote (de las cuales 1171 son silvestres) y 1556 variedades de
raíces y tubérculos andinos y ha sido el primero en obtener una Acreditación 17025 de la
Organización Internacional para la Estandarización. La acreditación requiere de una
cuidadosa documentación de cómo tanto el material vegetal y la información se mueven
a través de la adquisición de todo el proceso de distribución, en el gráfico Nº 1.2 se
muestra un diagrama simplificado sobre los principales procesos para la acreditación.
Gráfico Nº 1.2
Principales componentes para la acreditación ISO 17025

Los procesos,
certificaciones,y los materiales
verificados

Más de 500 Personal en distintos

documentos, procesos y lugares del mundo,
fuentes de información necesaria para acceder,
compilados y organizados compartir, revisar, modificar y
Acreditacion aprobar los documentos
ISO 17025
"garantía visible de
la calidad del
germoplasma que
se distribuye"

Fuente: Centro Internacional de la Papa

Elaboración: Propia

Del gráfico Nº 1.2 se puede apreciar la gran importancia que tiene el sitio colaborativo
para poder procesar y tener disponible toda la información tanto estructurada y no
estructurada, esta documentación valida la calidad del material distribuido, además
existen otros sitios colaborativos de igual importancia, por citar algunos están:
 Espacio del Laboratorio de Calidad y Nutrición. Relacionada con la evaluación
nutricional y en el mejoramiento de la papa, camote, otras raíces y tubérculos y de
otros alimentos básicos como maíz, yuca, frijoles, arroz, trigo y mijo, también ofrece el
servicio de análisis de nutrientes en estos cultivos.
 Base de datos mundial de ensayos de campo de papa y camote. Este espacio
colaborativo proporciona acceso a los datos y documentación sobre papa y camote

5
 de datos de prueba en el campo y la información asociada, como las genealogías y
evaluaciones.
 Red Latinpapa. Este espacio colaborativo tiene como objetivo fortalecer la
colaboración entre investigadores y entidades de América Latina que realizan trabajos
de fitomejoramiento e innovación tecnológica con el cultivo papa para lograr impacto
en la seguridad alimentaria y la economía de agricultores pequeños de la región.
En septiembre del 2010 dentro de las recomendaciones realizadas por el organismo
auditor del Reino Unido, United Kingdom Accreditation Service (UKAS) se realizaron
algunas observaciones, una de las cuales fue sobre la preocupación por la capacidad de
respuesta ante desastres de los servidores donde se tienen la documentación
digitalizada del banco de germoplasma, así también se manifestó preocupación por la
poca capacidad de colaboración con personal ubicado en otras sedes del CIP. A partir
de esto último se realizó una pequeña encuesta para valorar la satisfacción del servicio
colaborativo (ver anexo Nº 01) con algunos de los colaboradores que se encuentran
laborando en la sede Lima y en las oficinas regionales, especialmente las ubicadas en el
África para ver el motivo de su escasa colaboración y participación, según esta encuesta
el 40% se mostró satisfecho y muy satisfecho con el servicio, un 35% califico el servicio
como normal mientras que un significativo 25% dijo que se estaba insatisfecho y muy
insatisfecho siendo de este grupo en su totalidad colaboradores de otras regiones, al
preguntar sobre el motivo por el cual consideran un mal servicio respondieron que se
debe a varios factores (ver gráfico Nº 1.3).
Gráfico Nº 1.3
Principales motivos de descontentos de servicio colaborativo

60%
60%
20%

40%

10% 10%
20%

0%
Falta de Desconocimiento Demora en el Otros
actualización de del uso de acceso al espacio
documentos servicio

Fuente: Centro Internacional de la Papa

Elaboración: Propia
Del gráfico anterior se puede observar un claro descontento originado por la demora en
el tiempo de acceso a los principales espacios colaborativos del CIP, el segundo factor
6
de descontento es la falta de actualización de los documentos disponibles en el espacio
colaborativo, que es una consecuencia indirecta de la demora en el acceso al espacio ya
que no encontraron algunos documentos de interés que otros colaboradores no pudieron
compartir debido al deficiente acceso, constituyendo de esta manera un círculo vicioso
entre calidad de servicio y la falta de actualización de la información ya que la situación
parece irresoluble al existir estas circunstancias que son a la vez causa y efecto una de
la otra y que actúan de manera recíproca. Para poder comprender la dimensión del
problema de conexión al espacio colaborativo desde la sede principal y demás regiones
se consideró un ítem exclusivo dentro de la encuesta sobre el problema de conectividad
y acceso, en la gráfica Nº 1.4 se puede apreciar los resultados de la apreciación
personal del tiempo de acceso según su propia valoración.
Gráfico Nº 1.4
Calificación del tiempo de acceso al servicio colaborativo

Calificacción acceso
Muy lento 15%

Lento 30%

Normal 20%

Rápida 25%

Muy rápida 10%

0% 5% 10% 15% 20% 25% 30%

Fuente: Centro Internacional de la Papa
Elaboración: Propia

Del gráfico Nº 1.4 se puede ver nuevamente resultados abiertamente opuestos ya que
los colaboradores de la sede principal Lima, de las estaciones experimentales de
Huancayo y San Ramón y de la sede regional de Quito en su gran mayoría califican el
tiempo de acceso como rápido y muy rápido, mientras que los colaboradores de las
regiones del África subsahariana califican el servicio desde muy lento a normal.
En base a lo anterior se realizó varias mediciones de conectividad, en una primera
evaluación se utilizó la herramienta web “Pingdom” (http://tools.pingdom.com/) que tiene
una red global de servidores para controlar los accesos a los diferentes sitios web, el
servicio gratuito incluye estadísticas de tiempo de actividad y tiempo de respuesta, asi la
prueba consistió en simular conexiones de usuarios ubicado en Ámsterdam – Países
Bajos (como la más cerca a África) y se testeo la página principal de nuestra sitio
colaborativo, la página principal de Google como uno de los sitios más veloces e
7
optimizados, el Portal de conocimiento de camote (SKP) y finalmente la página web del
CIP. Para cada sitio se midió 5 veces la descarga de la página y se tomó el promedio
para dos criterios: un score (grado) de 0 a 100 que mide la construcción técnica de una
página para un buen desempeño donde 100 lo mejor; y segundo, el tiempo de descarga
donde cuando el tiempo es menor es mejor, los resultados se muestra en la tabla Nº 1.1.
Tabla Nº 1.1
Comparación de grados y tiempos de descarga desde Ámsterdam

Tiempo
Sitio Grado
(segundos)

Portal Principal del CIP 67.4 18.4

Portal de Conocimientos de Camote (SKP) 76.0 2.7

Espacio Colaborativo (Lima) 84.2 60.0

Google 86.0 0.4

Fuente: Herramienta online “Pingdom”

Elaboración: Propia

De la tabla Nº 1.1 se puede apreciar como el sitio actual de Confluence en Lima es el

más lento con 60 segundos (según la encuesta realizada el tiempo de acceso al servicio
es el principal motivo de descontento del servicio) y 23 veces más lento que un servicio
similar, se nota también que la construcción técnica de las páginas de Confluence es
casi a la par con la de Google, como la página de Google no tiene mucho contenido el
tiempo de descarga se mas rápido con 0.4 segundos.
En una segunda evaluación se utilizó la herramienta WebPagetest, que fue desarrollada
originalmente por AOL para su uso interno, desde el 2008 está bajo licencia BSD, esta
plataforma está en constante desarrollo por varias empresas y contribuyentes de la
comunidad de código de Google. La versión en línea en www.webpagetest.org ejecuta
una prueba de velocidad en vacío de cada página web desde múltiples ubicaciones en
todo el mundo que utilizan navegadores reales (IE y Chrome) y en las velocidades reales
de consumo de conexión, se pueden ejecutar pruebas sencillas o realizar pruebas de
avanzada que incluye varias opciones configurables de las transacciones, captura de
video, bloqueo de contenido y mucho más.
Estos resultados proporcionan amplia información de diagnóstico, incluidas las gráficas
de recursos cascada de carga, controles de velocidad para la optimización de al página y
sugerencias de mejora, para esta evaluación se utilizó los servidores ubicados en
Nairobi – Kenia utilizando el navegador Internet Explorer 9 de los cuales se obtuvieron
los resultados mostrados en el gráfico Nº 1.5.

8
 Gráfico Nº 1.5
Comparación de tiempos de descarga desde Nairobi - Kenia

Tiempo (seg.)

150
140 138
125

100

75

50

25

0
Portal (antes de Portal (despues de
configuración) configuración)

Fuente: Herramienta online “WebPagetest”

Elaboración: Propia

En el gráfico Nº 1.5 se puede ver el tiempo de demora en la carga de los sitios

colaborativos a pesar de haber realizado las optimizaciones en la configuración del
Servidor Apache (configuración en cache, compresión de archivos, etc.), viendo que en
la primer carga se demora aproximadamente 140 segundos y en una segunda
evaluación un tiempo de 138 segundos aproximadamente en promedio, luego de haber
realizado 5 mediciones durante diferentes horarios de trabajo, lo cual reafirma el
resultado anterior que mencionaba una buena construcción técnica del espacio
colaborativo pero sin embargo tiene un pésimo rendimiento en la primera carga
completa.
Finalmente se contactó con personal técnico de la sede regional de Nairobi – Kenia
donde se consideró nuevos factores como el navegador utilizado y la hora de acceso ya
que ambos factores son importantes al momento de medir el tiempo de carga de las
aplicaciones, se volvió a considerar el portal de Conocimiento de Camote (SKP), la
página principal del sitio colaborativo Confluence y los espacios de WSA (Atlas Mundial
de la Papa), RIU (documentación de los sistemas informáticos de investigación) y GADC
(Pagina de acreditación del ISO - CIP), en esta oportunidad se evaluó espacios
colaborativos del CIP que en algunos casos necesitan autentificación, los resultados
podemos ver en la tabla Nº 1.2.
Con las mediciones realizadas y mostradas en la tabla Nº 1.2 se comprueba la deficiente
conectividad para usuarios de otras regiones de las sedes del CIP siendo en mejor de
los casos 30 segundos de carga de la página principal siendo significativamente mayor
el tiempo de carga promedio de otros sitios de otros centros, habiendo una ligera
9
disminución utilizando el navegador Chrome y Mozilla Firefox pero debido a la
ralentización del tiempo de respuesta en periodos de mayor número de transacciones no
es notable, superando en algunos casos dos minutos para la carga completa de los
diferentes espacios de nuestro sitio colaborativo, la conexión es casi 20 veces más lento
desde la oficina regional de Nairobi que un acceso similar desde las instalaciones de la
sede central en Lima, la conexión desde Lima y las estaciones experimentales de
Huancayo y San Ramón es casi la misma.
Tabla Nº 1.2
Comparación de tiempos de descarga desde Nairobi
8 – 12 AM 2 – 4:30 PM
Kenia Kenia

Firefox Chrome Firefox Chrome

http://www.sweetpotatoknowledge.org 5:02 5:01 3:03 3:06

https://research.cip.cgiar.org/confluence 30:02 30:05 120:50 130:05

https://research.cip.cgiar.org/confluence/display/WSA 80:10 90:00 180:09 240:04

https://research.cip.cgiar.org/confluence/display/RIU 60:50 80:10 120:47 180:01

https://research.cip.cgiar.org/confluence/display/gadc 60:37 60:00 120:01 100:00

Fuente: Centro Internacional de la Papa

Elaboración: Propia

Teniendo una evaluación de los tiempos de conexión desde las diferentes oficinas
regionales se procedió a evaluar la infraestructura actual que la soporta, el CIP tiene 6
servidores destinados a la investigación (gráfico Nº 1.6).
Gráfico Nº 1.6
Infraestructura del servidor “Calypson”

Fuente: Centro Internacional de la Papa

Elaboración: Propia

10
En el gráfico Nº 1.6 se observa los servidores través de los cuales brinda diferentes
servicios a los científicos y usuarios en general, el servidor “Calypson” está basado en
VMware Virtual Center que es un software de administración de infraestructura virtual
para configurar, asignar aplicaciones, servicios y servidores virtuales. Este servidor tiene
seis servidores virtuales, vemos que de los servidores virtuales los utilizados para dar
soporte a la colaboración son VM-Java (Java Server - Producción) y VM-MySQL
(MySQL Enterprise - Producción). “Calypson” tiene una antigüedad de cinco años,
periodo durante en el cual se ha ido repotenciando, agregando la capacidad de
procesamiento (memoria RAM) y almacenamiento (disco duro), lo cual implico costos
adicionales. Este servidor está ubicado físicamente dentro de las instalaciones de la
sede principal del CIP en Lima, está junto a otros servidores en la sala de servidores
(que es un ambiente que tiene las condiciones adecuadas, con una temperatura de
ambiente promedio de 20º C, donde existe acceso restringido, con alimentación eléctrica
ininterrumpida, etc.), ésta infraestructura responde a la estructura inicial del CIP donde
no contemplaba el aumento de recursos destinados a la investigación en el África
subsahariana que por ejemplo se calcula que en el año 2009 registró una asignación de
recursos por encima del 40% del presupuesto en proyectos de investigación.
Adicionalmente se identificó algunos inconvenientes geográficos, en el gráfico Nº 1.7
podemos ver el mapa de tráfico global donde muestra los flujos de tráfico mediante
cables submarinos y satélites, al mapa mundial agregamos la ubicación de nuestro
servidor actual in-house y la ubicación de algunos de los principales usuarios de las
herramientas colaborativas.
Gráfico Nº 1.7
Mapa Global de conectividad

Fuente: Telegeography
Elaboración: Propia
11
 Vemos en el gráfico Nº 1.7 que para poder conectarse un colaborador desde las
regiones, cada bit de información necesita recorrer enormes distancias, ya que para
conectarse desde África haciendo uso de un mayor ancho de banda necesita hacer el
trayecto de África – Europa – Norteamérica – Sudamérica, ya que la mayor parte del
tráfico de red generado desde África (entre un 70% y el 85%) se dirige a través de
servidores que se encuentran en otros lugares (principalmente Europa) esto
indudablemente agrega un tiempo de demora en el acceso ya que cada bit realiza este
recorrido de manera bidireccional cliente – servidor y viceversa.
En un estudio dado a conocer en setiembre del 2011 por Pando Networks, una empresa
líder en entrega de juegos digitales, reveló la velocidad y confiabilidad de conexiones de
Internet en todo el mundo con algunos hallazgos sorprendentes. Usando como base 27
millones de descargas por 20 millones de computadoras en 224 países, desde enero a
junio de 2011, el estudio ofrece una amplia vista panorámica a la accesibilidad de los
datos en todo el mundo. La velocidad promedio de descarga en todo el mundo es de 580
Kbps, siendo en el caso de países africanos como Kenia de 138 Kbps, Uganda tiene 138
Kbps, Mozambique tiene 80 Kbps, Angola tiene 113 Kbps y Benín 62 Kbps, en caso de
la sede principal del CIP en Lima la conexión es de 4 Mbps dedicado pero en las sedes
regionales la conexión de las oficinas está a la par con sus promedios nacionales ya que
no tienen un infraestructura dedicada.

1.2 FORMULACIÓN DEL PROBLEMA

1.2.1 PROBLEMA GENERAL
¿Cómo mejorar el deficiente servicio del espacio colaborativo integrado de
investigación en el Centro Internacional de la Papa?

1.3 OBJETIVO DE LA INVESTIGACIÓN

1.3.1 OBJETIVO GENERAL
Mejorar el servicio del espacio colaborativo integrado de investigación en el
Centro Internacional de la Papa.

1.4 JUSTIFICACIÓN DE LA INVESTIGACIÓN

1.4.1 JUSTIFICACIÓN TEÓRICA
Muchos estudios y publicaciones coinciden en que el potencial de la informática
en la nube es real e inmediato ya que tiene la capacidad de ofrecer flexibilidad,
performance y control de los gastos mediante un modelo de servicio modular
construido sobre la base de una plataforma alojada común, resultando muy
atractivo a los responsables de adquirir tecnología. Por otra parte las

12
 posibilidades de la virtualización en la nube son numerosas, es un sistema capaz
de transformar el rol que la tecnologías de información juega en la Organización
en la misma medida que Internet ha transformado las comunicaciones y el
comercio, ya que reduce el tiempo y el esfuerzo que se requieren para lanzar u
optimizar aplicaciones existentes, esta solución permite que el equipo de
tecnología de información responda de forma más acorde al ritmo y a la
dinámica de la Organización.

1.4.2 JUSTIFICACIÓN METODOLÓGICA

Las metodologías difieren en lo general dependiendo donde se aplican, hay
muchos autores y filósofos que así lo explican, sin embargo existe ciertas
coincidencias que son necesarios para comprender por dónde empezar y darle
forma a la migración, el plan de migración está conformado por una serie de
acciones agrupadas estratégicamente en 6 etapas o fases, la metodología a
emplear es una variante del autor a la metodología elaborada por el Instituto de
Estadística e Informática del Perú y recomendada por la Oficina Nacional de
Gobierno Electrónico e Informática, contempla el reajuste o realización con
mayor nivel de detalle dependiendo de la complejidad de la plataforma
tecnológica actual y de los recursos disponibles.

1.4.3 JUSTIFICACIÓN PRÁCTICA

Para las áreas de tecnología de información, instalar una nueva aplicación es
siempre un proyecto de gran envergadura, sin tiempo suficiente para reunir los
recursos humanos y financieros que se necesitan, muchos proyectos que
podrían beneficiar a la Organización se quedan atascados. Las aplicaciones
procedentes de la nube no requieren la instalación de una infraestructura
extensa en el emplazamiento del usuario, lo que reduce en gran manera la
dedicación anticipada de recursos concretos, por lo cual se plantea resolver el
problema existente mediante las potencialidades ofrecidas por la computación en
la nube, no obstante, existen algunas consideraciones prácticas a la hora de
decidirse a externalizar la infraestructura, motivo por el cual se emprende la
presente investigación.

1.5 HIPÓTESIS
1.5.1 HIPÓTESIS GENERAL
La migración de las aplicaciones colaborativas in-house a un entorno virtual
basado en la nube permite mejorar el servicio del espacio colaborativo integrado
de investigación en el Centro Internacional de la Papa.

13
1.5.2 DETERMINACIÓN DE VARIABLES
El modelo está integrado por las siguientes variables que se muestran en la
Tabla Nº 1.3:
Tabla Nº 1.3
Variables de estudio

Variable Dependiente Variable Independiente

(X) (Y)
Servicio del espacio colaborativo de Migración de las aplicaciones
investigación. colaborativas.
Fuente: Propia
Elaboración: Propia

1.5.3 OPERALIZACION DE VARIABLES

Para proporcionar mayor información sobre la variable en la tabla Nº 1.4 se
describen ambas variables definiéndolas conceptualmente y mencionando los
indicadores e instrumentos a utilizar.
Tabla Nº 1.4
Operalización de variables

VARIABLE DEFINICIÓN DIMENSIONES INDICADOR INSTRUMENTO

Migración de las Es un proceso 1. Eficacia 1. Nivel de Cuestionario de
aplicaciones complejo que 2. Confiabilidad percepción de encuesta.
colaborativas implica un trabajo 3. Recurso mejora. Análisis del log
(independiente) colaborativo para Humano 2. Tasa de retorno de rendimiento
no sólo tomar la 4. Seguridad de los visitantes del servidor.
funcionalidad 5. Infraestructura 3. Número de
existente sino páginas visitadas
realizar una por visitante
renovación en los 4. Uso de memoria
procesos que RAM
necesitan ser 5. Slow queries
optimizados. (consulta a la BD
mayor a 10s.)
Servicio del Es un conjunto de 1. Escalabilidad 1. Nivel de Cuestionario de
espacio actividades que 2. Robustez satisfacción de los encuesta.
colaborativo de buscan responder 3. Proceso usuarios Análisis del log
investigación a una o más 4. Planificación 2. Visitantes diarios de acceso del
(dependiente) necesidades de Estratégica 3. Número de servidor.
los usuarios, para 5. Eficiencia. visitas mensuales Evaluación con
que puedan 4. Visitantes herramientas de
intercambiar locales (América)- prueba de
información, mensuales velocidad
solicitar ayuda a 5. Visitantes otros
otros usuarios y continentes-
plantear todas mensuales
sus consultas. 6. Tiempo de carga
del espacio
colaborativo

Fuente: Propia
Elaboración: Propia

14
1.6 DISEÑO METODOLÓGICO
1.6.1 NIVEL Y TIPO DE INVESTIGACIÓN
El presente trabajo de investigación es de nivel explicativo y del tipo tecnológico.
Explicativo porque se tiene que ver la influencia de la variable independiente
sobre la variable dependiente y tecnológica porque se aplicará tecnologías de
información en el proceso del trabajo de tesis para determinar dicha influencia.

1.6.2 MÉTODO Y DISEÑO DE LA INVESTIGACIÓN

La presente investigación de una investigación tecnológica. El autor Mario
Bunge, distingue la investigación aplicada (o aplicativa) de la investigación
tecnológica, el mencionado autor explica que existen dos tipos de invención
tecnológica: innovación y mejoramiento tanto los problemas de invención
primaria como los de mejoramiento requieren el diseño de artefactos o de
procesos para hacer o fabricar algo útil para alguien de la manera más eficiente.
Pero hay diferencias ontológicas y epistemológicas obvias entre los dos, la
invención primaria puede llevarnos a una novedad radical, en tanto que la
invención secundaria sólo nos lleva a una alteración menor de la primera.
La estructura del diseño es cuasiexperimental con preprueba - posprueba de un
solo grupo, representado a continuación:
Serie preprueba Serie posprueba
G O1 x O2

Dónde:
Serie preprueba: Se realizó antes de la migración a un entorno virtual basado
en la nube.
Serie posprueba: Se realizó antes de la migración a un entorno virtual basado
en la nube para verificar si los objetivos se han logrado.
G: Grupo constituido por todos los colaboradores que acceden
al espacio colaborativo.
O1: Resultado de evaluación (pruebas, cuestionarios,
observaciones) antes de la migración.
O2: Resultado de evaluación (pruebas, cuestionarios,
observaciones) después de la migración.

1.6.3 POBLACIÓN Y MUESTRA

1.6.3.1 Población
La población estará conformada por la totalidad de colaboradores que
hacen uso de la infraestructura colaborativo del Centro Internacional de
la Papa.
15
 1.6.3.2 Muestra
Para la presente investigación se tomó aleatoriamente una muestra de
40 colaboradores distribuidos proporcionalmente al número de
colaboradores totales de la sede principal y de cada sede regional,
adicionalmente se consideró a 10 colaboradores arbitrariamente de
acuerdo a la relación de su puesto funcional con el espacio colaborativo.

1.6.4 TECNICA DE RECOLECCION DE LA INFORMACION

La información se recolecto aplicando la técnica de la encuesta, entrevistas,
observación directa de los logs de los servidores y pruebas de rendimiento.
- Encuesta: Esta técnica consiste en recopilar información de: sugerencias,
opiniones, repuestas y datos generales que se proporcionen a preguntas
formuladas sobre los diversos indicadores que se pretenden explorar.
- Entrevista: Es una conversación interpersonal entre el investigador y el sujeto
de estudio, con el fin de obtener la información oral de parte del entrevistado y
es recabada por el investigador en forma directa.
- Observación Directa: Esta técnica consiste en recoger sistemáticamente la
información de errores, perfomance, registros y accesos.
- Pruebas de Rendimiento: Esta técnica consiste en realizar pruebas utilizando
diferentes herramientas Web y de escritorio sobre el rendimiento de los servicios
colaborativos.

1.6.5 INSTRUMENTOS DE LA INVESTIGACIÓN

Para la recolección de la información se utilizaron como instrumentos:
- Cuestionario: Es un formulario que consta de una serie de preguntas e
instrucciones para responder, de manera abierta, cerrada o de opción múltiple.
El cuestionario está dirigido a los colaboradores del espacio colaborativo
integrado (Ver anexo 1).
- Registro de logs: Es un registro oficial de eventos durante un rango de tiempo
en particular ocurrido en los diferentes servidores.
- Evaluación de rendimiento. Son pruebas que se realizar para evaluar el
rendimiento, considerando diferentes escenarios debidamente documentados.

1.6.6 FUENTES Y TÉCNICAS PARA LA RECOPILACIÓN DE INFORMACIÓN

1.6.1.1. Fuentes primarias
 Libros sobre computación en la nube y/o espacios colaborativos.
 Tesis de licenciatura, maestría y/o doctoral sobre la computación en
la nube y/o espacios colaborativos.
16
  Encuestas y entrevistas a los colaboradores del CIP.
 Análisis de los logs (registros de actividad) de los sistemas.
 Observación directa.
1.6.1.2. Fuentes secundarias
 Artículos y/o publicaciones en revistas tecnológicas relacionados al
tema.
 Extracto de entrevista a expertos de la computación en la nube y/o
espacios colaborativos.
 Documentación técnica sobre los servidores actuales.
 Información disponible en Internet.

Basado en todo lo anterior podemos evidenciar la existencia del problema del servicio del
espacio colaborativo integrado en el Centro Internacional de la Papa lo cual se debe a
diversos factores, para poder validar la hipótesis propuesta se ha detallado la metodología a
emplear durante toda la investigación que combinada con la justificación deberá de
garantizar la consecución del objetivo planteado.

17
 CAPITULO II
MARCO DE REFERENCIA

En el presente capitulo se presenta las investigaciones relacionadas espacios colaborativos

y computación en la nube, es este último no hay muchas investigaciones a nivel nacional ya
que se trata de una tecnología que se encuentra en la fase temprana de desarrollo, sin
embargo existen numerosas investigaciones internacionales que serán evaluadas, además
se estableció las bases teóricas que sustentan el presente estudio, el modelo aplicativo es
una variante personal de las ya existentes y usadas en las comunidades de software libre y
finalmente el marco conceptual comprende los principales términos asociados al trabajo.

2.1 ANTECEDENTES
A1. Saleem, Rehan (2011). Cloud Computing’s effect on Enterprises in terms of
Cost and Security. Tesis de Maestría. Universidad de Lund. Suecia.
En esta tesis de investigación, su autor expresa que “las innovaciones son necesarias
para subirse a la ola del cambio inevitable, la mayoría de las Empresas se esfuerzan por
reducir sus costos de computación a través de los medios de la virtualización, ésta
demanda de reducir el costo de la computación ha dado lugar a la innovación del Cloud
Computing”. El mencionado autor agrega que sin embargo “la mayoría de Empresas
tienen diferentes ideas sobre Cloud Computing existiendo aún una confusión sobre la
verdadera definición, esto es comprensible ya que se trata de una esta tecnología que se
encuentra en su etapa inicial, sin embargo ya que es una tecnología que evolucionó a
partir de Grid Computing, la mayoría de las Empresas que hayan utilizado Grid
Computing son más capaces de entender el término de Cloud Computing. Hay una
confusión o desacuerdo acerca de los límites de la computación en la nube ya que
muchas Empresas e incluso los proveedores de Cloud Computing creen que la nube
privada es una parte de Cloud Computing. Sin embargo, en la investigación se ha
encontrado que el Cloud Computing es la suma de software como servicio (SaaS) y
Utility Computing, pero no incluye a las nubes privadas”.

18
En resumen, el autor menciona que “Cloud Computing se está convirtiendo en una gran
tecnología y muy beneficioso en el escenario actual y futuro, gran parte del trabajo se ha
puesto en él y se puede esperar más avances en la tecnología de Cloud Computing. Sin
embargo, para las Empresas el factor más importante para adoptar el Cloud Computing
hasta hoy se centra en el costo, mientras que la seguridad aún no es el valor añadido de
Cloud Computing para las Empresas, a pesar de sus beneficios”. El hallazgo más
importante es que el Cloud Computing es ideal para empresas medianas y pequeñas,
tanto en términos de costo-beneficio. Sin embargo, en términos de seguridad, no es tan
beneficioso para las empresas medianas y pequeñas al adoptar el Cloud Computing,
mientras que para las grandes Empresas es más eficaz adoptar la nube privada porque
con la nube privada pueden ahorrar costos y tener una mejor seguridad”.
En este trabajo de investigación, que aborda los efectos de Cloud Computing en
diferentes Empresas, el autor se centra en el costo y la seguridad y concluye que en las
Empresas de fueron parte de su estudio existe una confusión por lo nuevo de la
tecnología, esto para países como el nuestro se refleja de igual o mayor magnitud, sin
embargo como consecuencia de la globalización dentro de muy poco tiempo la adopción
de esta nueva tecnología será ampliamente aceptada.

A2. Gaikwad, Manisha (2011). EC2LAB: SAAS using Amazon elastic Cloud
Compute. Tesis de Maestría. Universidad Estatal de San José. Estados Unidos.
El autor de dicha investigación expone algunas experiencias sobre un proyecto donde
crea un entorno de laboratorio para los usuarios (especialmente estudiantes) para
trabajar con una gama de máquinas de múltiples núcleos. Utiliza Amazon Machine
Images para crear instancias bajo demanda, el uso empleado es del tipo de software
como servicio (SaaS) para aplicaciones web, que permite a los usuarios iniciar
fácilmente, monitorear y poner fin a las instancias a través de una interfaz web intuitiva.
De este modo, el autor menciona que “los usuarios pueden iniciar una instancia, trabajar
con varias máquinas de alto rendimiento de múltiples núcleos, y pueden para o terminar
dicha instancia cuando ya no es necesario”. Además agrega que proporciona una
plataforma de aprendizaje excelente para explorar las capacidades del servidor
utilizando los recursos físicos de los servidores y los recursos de alta performance de la
nube en bajo demanda. Para comenzar, terminar, o conectarse a la instancia virtual
generado por las aplicaciones EC2Lab las instancias virtuales son utilizadas para
experimentar el paralelismo del procesamiento y entender los conceptos de la capa de
infraestructura de la nube. Esta aplicación también puede ser utilizada por una pequeña
Organización cuando se desee obtener los recursos físicos bajo demanda desde la
nube, el administrador puede configurar y añadir nuevas máquinas que pueden ser
utilizados por los empleados para el desarrollo y pruebas, también puede supervisar las

19
instancias y poner fin en los casos cuando sea necesario, por su lado los empleados
pueden usar los privilegios de usuario para acceder a las instancias”.
Finalmente el autor concluye mencionando que “Este proyecto crea correctamente un
entorno de laboratorio para los usuarios para poder trabajar con la gama de máquinas
multi-núcleo. Esto ayuda a iniciar, controlar y poner fin a las instancias a través de una
interfaz web intuitiva, y proporciona una plataforma de aprendizaje excelente para
explorar las capacidades del servidor de recursos físicos de la nube. Las pruebas se
realizaron en las máquinas virtuales adquiridas en Amazon y en máquinas físicas
similares y los resultados apoyan que los recursos de nubes proporcionar un rendimiento
similar, y puede ser utilizado como un reemplazo de los equipos físicos reales”.
Esta investigación es una buena experiencia que servirá mucho en la fase de pruebas
previas a la migración a la computación en la nube, ya que se trata de una experiencia
práctica muy bien documentada sobre las dificultades, inconvenientes y facilidades
encontrados durante la creación y prueba de instancia utilizando Amazon Cloud
Computing y otros servicios similares.

A3. Sobotta, Adrian (2008). Enhancing the agility promoting benefits of service-
orientation with Utility Computing. Tesis de Maestría. Universidad de Copenhague.
Dinamarca.
El autor de dicha investigación menciona que “las Empresas han estado explotando la
agilidad de las mejoras de las habilidades en tecnología de la información, en gran
medida ocurridos en la última década. El problema de la falta de agilidad es
especialmente importante en el entorno actual que tiene una característica abrumadora
de cambio, uno de esos usos es la implementación orientado hacia los servicios que
promueve el acoplamiento y la reutilización de los otros conductores de la agilidad
altamente deseables”. Esta tesis de maestría propone una extensión del paradigma de
diseño de servicios de orientación para incluir al Cloud Computing basado en la utilidad,
este nuevo paradigma de diseño se encuentra para promover en las Empresas un nivel
de agilidad mayor que antes no era posible utilizando las arquitecturas tradicionales
orientadas a servicios por sí solos. En esta tesis se intenta encontrar una solución al
problema de las empresas que necesitan un nivel cada vez mayor de agilidad para
competir con eficacia, el entorno en el que las empresas de hoy deben operar cada vez
se vuelve más dinámica, con cambios que cada vez fuerzan a la Empresa a cambiar por
motivos internos y externos, si una Empresa es adecuadamente ágil en un momento
dado, entonces ningún cambio sería demasiado grande para que responda a él, incluso
podría beneficiarse de ella.
Esta tesis, por supuesto, no es el primer documento para sugerir una solución a la falta
de agilidad en el contexto de la tecnología de la información, la investigación sobre este

20
tema es muy diversa y provocan un especial análisis cada caso, porque apalancada en
el camino correcto podría permitir tener un impacto de manera significativa que
agregaría agilidad a las Empresas, sin embargo apalancada incorrecta, puede ser uno
de los inhibidores más importantes de la agilidad.

A4. Mark-Shane, Scale (2010). Assessing the Impact of Cloud Computing and Web
Collaboration on the Work of Distance Library Services. Artículo de Investigación
de Maestría. Universidad de las Indias Occidentales. Jamaica.
El autor de dicha investigación menciona que “la colaboración es un tema fundamental
en los tiempos modernos, esto implica cambiar cómo funcionan las Organizaciones, ya
que la colaboración moderna elimina las fronteras tradicionales, con la sinergia de las
tecnologías de información y la colaboración la construcción moderna de la Organización
virtual se crea, ya que no existen límites geográficos y los grupos de personas pueden
tener acceso y compartir recursos independientemente de su ubicación”. En el caso
práctico de los servicios bibliotecarios “la biblioteca en el futuro, a la luz de las
tendencias actuales será una entidad invisible que trabajará para facilitar el acceso a la
información. La perspectiva teórica de los bibliotecarios en la prestación de servicios a
distancia en la biblioteca en la era de la computación en la nube y la colaboración web
ha cambiado, pasando a usar proveedores externos de servicios y tecnología, para
poder ir donde están los usuarios e integrar los servicios que ofrece la biblioteca en los
flujos de trabajo de los usuarios. Con los entornos virtuales de aprendizaje, los
bibliotecarios se trasladaron para facilitar enlaces a los recursos de la biblioteca y los
servicios que se ponen dentro de los entornos de aprendizaje permiten que los
estudiantes y profesores puedan interactuar. Sin embargo, si los usuarios se mueven
fuera de los entornos de aprendizaje para hacer su trabajo, la biblioteca de servicio de
telefonía tendrá que adaptarse para seguir siendo visible para los usuarios”.
En la investigación mencionada el autor habla de sus experiencias de la migración desde
la forma de trabajar en el mundo físico a un mundo virtual, esto para aprovechar las
ventajas que te otorga el uso de la computación en la nube, que significa la eliminación
lo que denomina los límites geográficos, pero más que externalización de los servicios
bibliotecarios de los proveedores de informática habla de la necesidad de fortalecer otras
habilidades para alinear al personal para poder colaborar y aprovechar la colaboración.

A5. Han, Yan (2011). Cloud Computing: Case Studies and Total Costs of
Ownership. Artículo de Investigación. Universidad de Arizona. Estados Unidos.
En autor de dicha investigación menciona que “la ejecución de aplicaciones en la nube
ofrece muchas ventajas técnicas y resultados en ahorro de costos significativo en su
ejecución, a diferencia de los servidores administrados locales no se necesita la compra

21
 de un servidor y hacer algunas configuraciones básicas”. En los estudios de casos de
implementación de aplicaciones web el autor utiliza IaaS y PaaS con Amazon Web
Service, Linode AppEngine y Google. El autor de la mencionada investigación presenta
una comparación detallada de costos entre los nodos virtuales administrados en la
computación en la nube y la gestión de almacenamiento local utilizando servidores en el
modelo tradicional. El análisis muestra que el Cloud Computing tiene sus ventajas
técnicas y ofrece importantes ahorros de costos al mantener aplicaciones web. Las
aplicaciones web en la nube ofrecen varias ventajas técnicas sobre los servidores de
gestión local, la alta disponibilidad, flexibilidad y rentabilidad son algunos de los
beneficios más importantes. Sin embargo, la gestión local de almacenamiento sigue
siendo una solución muy atractiva en un caso típico de almacenamiento de menos de 10
TB ya que Amazon ofrece precios más bajos de almacenamiento de enormes cantidades
de datos, sin embargo recomienda a los lectores hacer sus propios análisis.
En la investigación anterior el autor reafirma las principales ventajas técnicas ofrecidas
por el Cloud Computing, en el análisis de costos, como menciona se recomienda hacer
las evaluación para cada especifico ya que el autor baso su investigación con un tipo de
perfil de la Organización que puede ser diferente a la nuestra, pero sin embargo no
debería tener diferencias drásticas ya que el uso de la computación en la nube se perfila
ser como más económica que la tecnología tradicional.

2.2 MARCO TEÓRICO

A continuación haremos una revisión exhaustiva de las teorías más recientes que
describen todo lo que se sabe o se ha investigado sobre computación en la nube (Cloud
Computing) y sobre espacios colaborativos.

2.2.1 Virtualización
La virtualización es una técnica de diseño fundamental para todas las
arquitecturas de la nube. En la nube informática se refiere principalmente a la
virtualización de la plataforma, o la extracción de la tecnología de información
física, recursos de las personas y las aplicaciones. La virtualización permite a los
servidores, dispositivos de almacenamiento y otros ser tratados como un conjunto
de recursos en lugar de sistemas discretos, por lo que estos recursos pueden ser
asignados en la demanda. En la computación en nube, es de gran interés
técnicas como la paravirtualización, que permite que un solo servidor pueda ser
tratado como varios servidores virtuales, y el clustering (agrupamiento), lo que
permite que múltiples servidores puedan ser tratados como un único servidor.
Como una forma de encapsulación de los recursos físicos, la virtualización
resuelve varios problemas fundamentales de los administradores de centros, una

22
de las empresas que más conoce sobre el tema de virtualización es Sun
Microsystems que en su documento “Take your business to a higher level: Sun
cloud-computing technology scales your infraestructure to take advantage of new
business opportunities” hace un listado de las ventajas específicas de la
virtualización, las cuales incluye:
- Tasas de utilización. Antes las tasas de utilización de virtualización, servidor y
almacenamiento en centros de datos empresariales por lo general tenían un
promedio de menos del 50% (de hecho, un 10% a 15% de las tasas de
utilización fueron comunes). A través de la virtualización, las cargas de trabajo
pueden ser encapsulados y se transfieren a los sistemas ociosos o
subutilizados - lo que significa que los sistemas existentes se pueden
consolidar, por lo que las compras de la capacidad del servidor adicional se
puede retrasar o evitar.
- Consolidación de recursos. La virtualización permite la consolidación de
múltiples recursos de TI. Más allá de consolidación de servidores y
almacenamiento, la virtualización ofrece una oportunidad para consolidar la
arquitectura de sistemas, infraestructura de aplicaciones, datos y bases de
datos, interfaces, redes, ordenadores de sobremesa, e incluso los procesos
de negocio, lo que resulta en ahorros de costos y mayor eficiencia.
- Consumo de energía/costos. La electricidad necesaria para ejecutar los
centros de datos de clase empresarial ya no está disponible en cantidades
ilimitadas, y el costo es en una espiral ascendente. Por cada dólar gastado en
hardware de servidores, se gasta un dólar adicional en alimentación
(incluyendo el costo de funcionamiento y refrigeración servidores). Utilizando
la virtualización para consolidar hace posible reducir el consumo total de
energía y ahorrar dinero significativamente.
- Ahorro de espacio. La proliferación de servidores sigue siendo un problema
grave en centros de datos de la empresa, pero la expansión de centros de
datos no es siempre una opción, con un promedio de los costos de
construcción de varios miles de dólares por metro cuadrado. La virtualización
puede aliviar la tensión mediante la consolidación de muchos de los sistemas
virtuales en menos sistemas físicos.
- Recuperación de desastres/continuidad del negocio. La virtualización puede
aumentar el nivel general de servicios, de la disponibilidad y tarifas de las
nuevas opciones para las soluciones de recuperación ante desastres.
- Los costos de operación reducidos. Las empresas en promedio gastan $8 en
el mantenimiento por cada $1 gastado en la nueva infraestructura. La

23
 virtualización puede cambiar la relación de servidor - administración, reducir la
carga administrativa total, y reducir los costos de las operaciones totales.

2.2.2 Computación en la nube

Para el Gartner Group (2009) la computación en la nube es un estilo de
computación que provee capacidades flexibles y escalables, como un servicio a
múltiples clientes, empleando tecnologías de Internet. Hay una pequeña
corrección con respecto a la definición original de 2008: se sustituye la cláusula
“escalables masivamente” por “flexibles y escalables” para calificar las
capacidades entregadas.
El Cloud Computing está convirtiendo Internet esencialmente en una plataforma
de computación mayor, extendiendo y mejorando de forma significativa las
tecnologías y las capacidades introducidas por estas iniciativas anteriores. La
nube se está convirtiendo en la plataforma para las aplicaciones, la información y
los servicios para los miles de millones de dispositivos inteligentes, así como para
los billones de sensores inteligentes conectados a Internet.
The Economist describe el Cloud Computing en su introducción en un reciente
informe especial sobre el tema, donde menciona: «Al principio los ordenadores
eran como humanos. Después tomaron la forma de cajas de metal, llenando salas
enteras antes de volverse cada vez más pequeños y estar cada vez más
extendidos. Ahora se están evaporando y se están convirtiendo en accesibles
desde cualquier sitio. [...] la computación está adoptando otra nueva forma. Se
está volviendo de nuevo más centralizada a medida que parte de la actividad se
traslada a centros de datos. Pero, lo más importante, se está convirtiendo en lo
que se ha llegado a llamar una “nube”, o un conjunto de nubes».

2.2.2.1 Un nuevo paradigma

Para los desarrolladores y Empresas que deseen adoptar el modelo de la
computación en la nube, se han desarrollado tecnologías críticas para
ofrecer el servicio a nivel empresarial y cualidades sistémicas a este nuevo
paradigma:
 Interoperabilidad. Mientras que las nubes actualmente ofertadas
utilizan plataformas cerradas y los proveedores de tecnología y
desarrolladores piden para la interoperabilidad. La computación en la
nube a futuro tiende en proporcionar la interoperabilidad de los
recursos de computación a gran escala. Actualmente todavía no hay
una total integración de estándares que permitan la interoperabilidad y
portabilidad de las aplicaciones entre diferentes proveedores de la
24
 nube, y este sin duda es un tema muy importante ya que evitar la
dependencia absoluta de un solo proveedor implica algo más que tener
acceso a precios competitivos o a un mejor servicio, se trata de
disponibilidad.
 Alta densidad de computación horizontal. Esta tecnología de alta
densidad se está incorporando en los diseños de nubes a gran escala
ya que permite cambiar rápidamente el número de instancias
independientes para que coincida con los cambios en la demanda, lo
que permite un mejor rendimiento debido a que hay varios ordenadores
trabajando en conjunto para aumentar el rendimiento del sistema,
además de mejorar el balanceo de carga hacia los diferentes nodos del
clúster.
 Datos en la nube. El fabricante de equipos de redes Cisco Systems
menciona que el tráfico mundial de datos en nube crecerá a un ritmo
anual compuesto del 66% entre 2010 y 2015, a medida que tanto las
Empresas traten de lograr un acceso sin restricciones a contenido y
aplicaciones, para ese año más de un tercio de todo el tráfico de
centros de datos estará basado en la nube, que permite que los datos
se almacenen y se acceda a ellos de manera remota.

2.2.2.2 Atributos de la nube

Casi todas las definiciones de la computación en la nube descompone sus
características en cinco atributos que, combinados de diferentes formas,
conducen a diversos modelos de computación en la nube. Gartner recalca
que no es recomendable enfocarse en un atributo aislado. Los cinco
atributos de la computación en la nube son los siguientes:
 Se basa en servicios. Requiere una completa automatización de la
respuesta del proveedor de servicios a la empresa usuaria; es decir, la
interfaz del servicio debe estar bien definida y esconder la complejidad
de la implantación.
 Es escalable y flexible. El servicio tiene una capacidad escalable hacia
arriba o hacia abajo y, además, el cambio de capacidad se efectúa con
rapidez (algunos segundos para unos servicios o algunas horas para
otros).
 Es compartida. Los servicios entregados comparten un pool de
recursos, que crea una economía de escala, y son usados con máxima
eficiencia.

25
  Se mide según el uso. Un modelo para la contabilidad del uso de los
recursos permite crear diferentes planes: «cuánto consumes, cuánto
pagas».
 Usa tecnologías de Internet. Las tecnologías que han permitido
servicios de venta on-line (como los de Amazon) o servicios de correo
(como los de Gmail o Yahoo), que implican la construcción de grandes
centros de datos con centenares de miles de servidores, han servido
de base para la entrega de los servicios de computación en la nube.
En resumen, la computación en la nube proporciona un modelo de relación
proveedor-consumidor en sustitución de la relación vendedor de tecnología
de información - usuario. En la primera se compran y se venden servicios;
mientras que, en la segunda, los usuarios adquieren tecnología de un
vendedor y deben desplegarla e integrarla o reemplazar la infraestructura
existente.

2.2.2.3 Modelos de infraestructura

La computación en la nube o Cloud Computing es una nueva tendencia en
las TIC que evoluciona muy rápidamente y que se está haciendo cada vez
más popular, representa un cambio importante en la forma en la que se
almacenan y ejecutan aplicaciones (aplicaciones de escritorio, aplicaciones
y servicios Web) posibilita un autoservicio bajo demanda. Permite mover la
computación a la nube, aunque el concepto no es muy nuevo el término
Cloud Computing aparece como tal en el año 2007, sin embargo ya desde
hace tiempo utilizamos ciertas formas de Cloud Computing como por
ejemplo las redes sociales como Facebook / MySpace y cuentas de correo
electrónico basadas en Web como Gmail. La computación en la nube
proporciona una infraestructura eventualmente ilimitada para almacenar y
ejecutar datos y programas de clientes. Los clientes no necesitan tener su
propia infraestructura, sólo acceso vía Web. Los principales modelos de
despliegue son:
 Nube privada. La infraestructura de Cloud sólo opera para una
Organización. Puede gestionarla la propia Organización o una tercera
parte y puede existir en el local o fuera.
 Nube comunitaria. La infraestructura de nube se comparte por parte de
varias organizaciones y soporta una comunidad específica que tiene
intereses compartidos (por ejemplo misión, requisitos de seguridad,
política y consideraciones de cumplimiento). La pueden gestionar las
Organizaciones o una tercera parte y puede existir en el local o fuera.
26
  Nube pública. La infraestructura de nube se hace disponible al público
en general o a un gran grupo industrial y es propiedad de una
Organización que vende los servicios de Cloud Computing.
 Nube híbrida. La infraestructura de nube es una composición de dos o
más nubes (privada, comunitaria o pública) única para las entidades
pero se limitan juntas por medio de tecnología propietaria o
estandarizada que permite la portabilidad de datos y aplicaciones.

2.2.2.4 Cualidades sistémicas de la nube

La naturaleza impredecible de las cargas de trabajo de Cloud Computing
exige que las nubes estén diseñadas para niveles extremadamente altos
de eficiencia, a nivel de disponibilidad, escalabilidad y manejabilidad,
seguridad, y otras cualidades sistémicas.
Inicialmente, las plataformas de computación en la nube son atractivos por
su bajo costo de desarrollo e implementación de capacidades, pero a
medida que las empresas utilizan cada vez más plataformas en la nube
para entornos de producción reales, se requieren altos niveles de
performance.
Maximizar las cualidades sistémicas requiere integrar el desarrollo de
estas cualidades en el proceso de diseño de las grandes arquitecturas.
Para el Cloud Computing, el foco de las cualidades sistémicas es diferente
de la basada en host, cliente-servidor y modelos basados en la Web del
pasado. De alguna manera el reto de lograr las cualidades sistémicas es
más complejo, por otro lado, si estas arquitecturas están bien diseñadas
desde el principio, esto puede contribuir a, y no como un desafío, hacia el
logro de las cualidades sistémicas.
La computación en la nube ha introducido una serie de innovaciones que
ofrecen a nivel empresarial cualidades sistémicas en las arquitecturas de
computación en la nube. Estas innovaciones se encuentran principalmente
en las áreas de eficiencia y economía, fiabilidad y disponibilidad, densidad
y escalabilidad, agilidad y seguridad.
 Eficiencia / Economía. La computación en la nube es pionero en
“tecnología verde” en movimiento con la eficiencia energética ya que ha
ahorrado que cientos de empresas gasten millones de dólares en
costos de energía por sí solos, además se caracteriza por el bajo costo,
innovador con las ofertas que abarcan el diseño de centros de datos,
hardware, sistema operativo y los componentes de software, los
principales defensores de software de código abierto utilizan las
27
 tecnologías de virtualización en todos los aspectos de diseño y
desarrollo de productos con el fin de lograr una mayor eficiencia de
energía. También permite un gran número de servidores para funcionar
de manera más eficiente y ahorrar costos en energía, cableado,
sistemas de climatización, y así sucesivamente; minimiza los gastos de
capital (infraestructura de propiedad del proveedor).
 Fiabilidad / disponibilidad. Es disponible a través de las características
incorporadas y sofisticado a nivel de hardware, ya que cuenta con la
disponibilidad de conmutación por error, a la agrupación a la
reconfiguración dinámica, además es fiable ya que se encuentra en
múltiples sitios redundantes, lo que lo hace adecuado para la
continuidad del negocio y recuperación ante desastres.
 Densidad / Escalabilidad. Los nodos de nubes en forma de sistemas de
datacenter en entorno de Cloud Computing, la virtualización y la
reconfiguración dinámica de ampliación son eficientes en alta demanda
sin tener picos de carga demasiados altos.
 Agilidad. Las múltiples arquitecturas de hardware para adaptar los
sistemas a las cargas de trabajo: multiusuario, permite compartir los
recursos (y costos) entre un gran número de usuarios, lo que permite la
centralización de la infraestructura en las zonas con menores costos,
tales como bienes raíces y la electricidad.
 Seguridad. Por lo general, mejora la seguridad con la centralización de
los datos y el aumento de los recursos centrada en la seguridad, por lo
que la computación en nube plantea preocupaciones acerca de la
pérdida de control sobre ciertos datos sensibles. Los accesos son por
lo general registrados, pero el acceso a los registros de auditoría es
casi imposible de conseguir.

2.2.2.5 Obstáculos para la adopción generalizada

La compañía global de consultoría de gestión “Boston Consulting Group
(BCG)” en su experiencia en consultoría sobre la computación en la nube
hace un listado de algunos obstáculos para la adopción generalizada del
Cloud Computing, esta lista publicada en el documento «Captar el
verdadero valor del Cloud Computing» están descritas a continuación.
 Rendimiento, disponibilidad, escalabilidad y adaptabilidad. Aún existen
inquietudes sobre la latencia de las redes de datos e interrupciones de
servicio, también se tiene la incertidumbre sobre la capacidad para
gestionar un gran número de usuarios de forma simultánea.
28
  Seguridad y normativa. Existe preocupación sobre la seguridad de los
datos, en especial la información crítica de los clientes, existe una
estricta normativa sobre la privacidad y la protección de los datos en
algunos países como también hay normas poco desarrolladas en el
intercambio de datos entre países.
 Entorno de los distribuidores. Los planteamientos de algunos
proveedores no son claros con respecto a la funcionalidad, el
rendimiento y los costos. Existen obvias inquietudes sobre la viabilidad
a largo plazo de algunos proveedores, también como los estándares de
Cloud Computing están poco desarrollados, lo que hace que la
migración entre proveedores sea difícil.
 Inercia organizacional. Existe la resistencia cultural a compartir datos y
cambiar el modo tradicional de trabajar, una falta de claridad en los
procesos de tecnología de información ya que anteriormente se tenía
acostumbrado las grandes inversiones en aplicaciones tradicionales,
infraestructura y otros recursos.

2.2.2.6 Tendencias de la computación en la nube

Estudios de mercado de la transnacional IBM mencionan que en el 2012 el
mercado de cloud estará alrededor de mil millones de dólares, y en
Latinoamérica solamente, se registrará hasta el 2015 un crecimiento en
promedio anual de 40 a 45%. Estamos en el inicio de la curva, y crecerá en
las agendas de los CIOs, para mejorar su capacidad de entregar
tecnología porque ve ahí un potencial de ahorro y mejora del uso de los
activos de la compañía.
El cómputo en la nube se encuentra en fase emergente. Se estima que
para antes de 2015 sea ya un modelo maduro con los recursos
tecnológicos necesarios para entregar servicios pertinentes a empresas de
cualquier tamaño. Está claro que durante ese periodo las estructuras de
las compañías estarán mejor preparadas para enfocar el suministro de
servicios de negocio mediante las TI. Tal como plantean los analistas, el
éxito de la nube dependerá de cómo los servicios se consuman y si
realmente abre nuevas oportunidades de negocio.
Por último, es el momento del Cloud Computing desde el punto de vista
medioambiental. El cambio climático es una de las cuestiones con más
presencia en los medios de comunicación, por lo que una reducción en el
coste de la energía y en el impacto medioambiental también sería
considerada muy positivamente frente a las presiones por implantar
29
 políticas “verdes” en las Empresas y en la gestión de los Gobiernos. Una
tendencia que se establecerá en los próximos años será la predisposición
de las Organizaciones a disminuir los costos relacionados con el consumo
de energía, así como los esfuerzos conjuntos por parte de los países para
disminuir las emisiones de gases de efecto invernadero generadas por el
consumo de electricidad. El Cloud Computing se establece como modelo
de TI sostenible dado que el consumo energético es más eficiente en los
centros de procesamiento y almacenamiento compartidos frente al de los
individuales de las empresas.

2.2.3 Modelos de servicio de la computación en la nube

Una aplicación popular de la computación en la nube, para individuos o
Empresas, es el correo basado en la red, como Gmail. También es popular el uso
entre empresas pequeñas y medianas de aplicaciones de productividad, como
procesadores de palabras, hojas de cálculo o incluso software administrativo,
alojado en un servidor remoto, al que se accede vía Internet.
Según Prasad Padhy, Prasad Rao, 2011 y Cardoso, 2011 las capacidades de TI
que se ofrecen con la informática en la nube se pueden agrupar en tres
categorías generales:

2.2.3.1 Aplicaciones empresariales (SaaS)

Este modelo permite obtener una licencia para una aplicación dada en
forma de servicio bajo demanda, por lo que no se necesita adquirir el
programa e instalarlo en toda la organización. El SaaS se suele ofrecer a
través de un modelo de suscripción con cargos basados en el uso. Los
proveedores de SaaS suelen ofrecer el software y la asistencia técnica, y
con frecuencia colaboran con un proveedor de hosting en la operación de
los sistemas SaaS y la asistencia técnica.
La capacidad proporcionada al consumidor consiste en utilizar las
aplicaciones del proveedor que se ejecutan en la infraestructura de nube y
son accesibles desde diversos dispositivos cliente (PCs-notebooks,
teléfonos móviles, iPhones, etc.) utilizando una interfaz cliente ligero como
un navegador Web (por ejemplo correo electrónico basado Web o
webmail). El consumidor no gestiona, ni controla la infraestructura de nube
subyacente, red, servidores, sistemas operativos, de almacenamiento o las
capacidades de cada aplicación individual, con la posible excepción de
establecer de forma limitada la configuración de la aplicación específica del
usuario.

30
 Este modelo es potencial para las Empresas establecidas, es el modelo
más maduro de servicio en la nube, el SaaS está dirigido a empresas que
desean aumentar la eficiencia mediante la normalización de ciertas
funciones (gestión de las relaciones con los clientes (CRM), nóminas, otras
funciones de contabilidad) sobre una plataforma de software común que se
puede distribuir a través de la nube. El SaaS es una buena opción para
aplicaciones que no requieren una personalización excesiva.

2.2.3.2 Herramientas para desarrolladores (PaaS)

Este modelo proporciona una plataforma informática con los recursos
necesarios para desarrollar e implementar aplicaciones de Web, sin
necesidad de adquirir, instalar y gestionar los sistemas de hardware y
software correspondientes.
La capacidad proporcionada al consumidor se despliega en las
aplicaciones creadas por el consumidor de la infraestructura de nube
utilizando lenguajes de programación y herramientas soportadas por el
proveedor (como Java, Python, .Net). El cliente no gestiona, ni controla la
infraestructura de nube subyacente, red, servidores, sistemas operativos o
almacenamiento pero el consumidor tiene control sobre las aplicaciones
desplegadas y posiblemente las configuraciones del entorno de hospedaje
de la aplicación.
Este modelo es potencial para las empresas en crecimiento, la solución
PaaS fue diseñada en un principio para desarrolladores independientes
que no disponían de los recursos necesarios para construir y gestionar sus
propios centros de datos. Pero ahora los desarrolladores empresariales
han descubierto que estas herramientas son extremadamente útiles en las
fases previas a la implementación, después de lo cual puede ser necesario
transferir la aplicación al entorno de hosting particular de la empresa.

2.2.3.3 Recursos de infraestructura (IaaS)

En este modelo, la nube funciona como una infraestructura de utilidades, el
principal atractivo de este tipo de solución es que permite obtener
capacidad informática para las aplicaciones críticas sin tener que diseñar,
adquirir, construir y gestionar la infraestructura subyacente.
La capacidad proporcionada al consumidor es la provisión de
procesamiento, almacenamiento, redes y otros recursos de computación
fundamentales donde el consumidor puede desplegar y ejecutar software
arbitrario que puede incluir sistemas operativos y aplicaciones. El

31
 consumidor no gestiona, ni controla la infraestructura de nube subyacente,
pero tiene control sobre los sistemas operativos, almacenamiento,
aplicaciones desplegadas y posiblemente sobre componentes de red
seleccionados (como firewall, balanceadores de carga, etc.).
A medida que aumenta la demanda por servicios informáticos, las
aplicaciones empresariales requieren una mayor capacidad de
procesamiento y de almacenamiento de datos. Las organizaciones han
descubierto que para gestionar toda esta vasta infraestructura de
información se requiere un modelo de informática revolucionario.
Los modelos de infraestructuras mostrados se pueden visualizar en el
siguiente diagrama (Ver Gráfico Nº 2.1).
Gráfico Nº 2.1
Roles de los proveedores del Cloud Computing

Fuente: CloudBuilder en SIMO Network - 2010

Elaboración: CloudBuilder en SIMO Network – 2010

En el gráfico anterior se puede ver los diferentes roles del cloud comercial
que existe en estos momentos, lo cual ayuda a comprender los conceptos
de SaaS, PaaS e IaaS, ya que estos son distintos niveles de virtualización,
desde interactuar con la nube a través de un servicio o herramienta o
interactuar accediendo al servidor mismo.

2.2.4 Niveles de valor de la computación en la nube

De las diferentes consultarías de Boston Consulting Group realizada a diferentes
Empresas y publicadas en el documento “Captar el verdadero valor del Cloud
Computing” se ha diferenciados el valor en 3 niveles, cada uno de ellos se basa
en el anterior y requiere un cambio en los actuales procesos de negocio. Sin
embargo, cada nivel también permite la creación de valor hasta un orden de
magnitud mucho mayor que el nivel anterior, estos niveles son:

32
 Nivel de utilidad. Las empresas pueden beneficiarse de la disminución de los
costos y de un mejor servicio a través de la disponibilidad de recursos
informáticos elásticos y de modelos de pago por uso.
 Nivel de transformación de procesos. Las empresas pueden introducir
procesos de negocios nuevos y mejores aprovechando los activos comunes y
escalables y el potencial de colaboración del Cloud Computing.
 Nivel de innovación del modelo de negocio. Es posible crear nuevos modelos
de negocio vinculando, compartiendo y combinando los recursos por medio
del Cloud Computing en un único ecosistema de negocios.
A pesar de que los servicios de Cloud Computing pueden generar resultados
netos con gran rapidez en cuanto a su utilidad, los beneficios de los niveles de
transformación de procesos y de innovación del modelo de negocio requerirán
más tiempo para materializarse, ya que representan cambios fundamentales en el
modo en el que ese trabajo se lleva a cabo en las Empresas y entre los socios
comerciales (Ver Tabla Nº 2.1).
Tabla Nº 2.1
Niveles de valor de la computación en la nube

Ejemplo de nivel de Ejemplo de nivel de

Ejemplo de nivel de
transformación de innovación del modelo de
utilidad
procesos negocio

Empresa internacional de Negocio de tamaño Empresa médica

energía.
La total virtualización de
servidores tiene como
resultado:
• Mayor utilización de
servidores.
• Mejora de la funcionalidad
de la base de datos.
• Menos tiempo dedicado a
la gestión del sistema
operativo.
• Menos licencias de
software.
• Menores costes de
almacenamiento.
pequeño-medio.
La implementación de
servicios compartidos en la
gestión de documentos
genera:
• Mejoras en el flujo de
trabajo a través de escaneo
remoto, entrada de datos y
procesamiento de
actividades de back-office,
como efectos a cobrar y a
pagar o gestión de las
reclamaciones.
Internacional.
La estandarización y
automatización de los
elementos del proceso de
búsqueda dan lugar a:
• Capacidad para acceder a
aplicaciones de gestión de
datos y data mining en una
plataforma abierta que
conecta a las compañías
farmacéuticas y sus socios
de investigación.
•Mayor disponibilidad de
herramientas de
colaboración, de seguridad,
gestión de datos,
diagnóstico de datos y
análisis.

Impacto estimado Impacto estimado Impacto estimado

• Ahorro entre el 10% y el • Una mejora del 50% en • Un aumento de hasta el
12%, o 45 millones de eficiencia. 30% en rapidez de ensayos.
dólares al año, en costos de • Beneficios del arbitraje • Ahorro de hasta 400
TI. laboral. millones de dólares por
fármaco.
Fuente: Experiencias de casos de Boston Consulting Group
Elaboración: Boston Consulting Group

33
En la tabla Nº 2.1 se ve de manera concreta algunos ejemplos de tipos de
Empresas que utilizan en diferente nivel la computación en la nube y los
beneficios obtenidos por los mismos donde a mayor nivel de compromiso y
planificación a largo plazo se alcanza mejores impactos organizacionales. Muchas
compañías han empezado a beneficiarse del nivel de utilidad, aunque son muy
pocas las que han explorado los niveles de transformación de los procesos e
innovación de los modelos de negocio, para lograrlo, los directores generales de
TI tendrán que colaborar con los directivos de toda la Empresa para desarrollar
una fuerte comprensión de los requisitos estratégicos y operacionales de sus
organizaciones. Sin embargo, como las compañías están descubriendo, los
beneficios de cada nivel son considerables

2.2.4.1 Nivel de utilidad

A pesar de que es posible que las pequeñas y medianas Empresas hayan
sido las pioneras en el uso del Cloud Computing, las grandes Empresas
están empezando a escoger de forma selectiva aplicaciones que explotan
la mayor eficiencia, escala y objetivo de los proveedores de servicios en la
nube para mejorar el despliegue de recursos humanos, hardware, software
y energía de sus compañías. Genentech, la compañía de biotecnología
adquirida recientemente por F. Hoffman-La Roche, es un ejemplo de una
empresa que ha recurrido a Google Apps para sus programas de correo
electrónico y calendario y una gran cantidad de otras aplicaciones para sus
11.000 empleados. En el momento de su migración al modelo de Cloud
Computing, hace ahora un año, Genentech tenía 36 terabytes de correo
electrónico y 2 millones de reuniones programadas almacenados en sus
sistemas.
Genentech estaba pensando en gastar decenas de millones de dólares en
un nuevo centro de datos. Genentech evitó ese gasto de capital y redujo su
costo anticipado de titularidad en varios millones de dólares en los
próximos cinco años utilizando los proveedores de servicios cloud y las
tecnologías de virtualización.

2.2.4.2 Nivel de transformación de procesos

A pesar de que el valor de los servicios de Cloud Computing en lo que
respecta a la utilidad puede resultar muy atractivo, principalmente para los
directores de TI, los beneficios de la transformación de los procesos
deberían ir en aumento en el seno de una Empresa, de forma que permita
al personal de finanzas realizar transacciones de una forma más eficiente,
34
 a los investigadores crear y modificar los modelos informáticos con mayor
rapidez, y a los vendedores permitir atender a sus clientes de forma más
efectiva.
Por lo general, las Empresas tienen dificultades a la hora de mejorar los
sistemas y procesos de negocio, a pesar de los mayores esfuerzos tanto
de los directivos de TI como de los de todas las áreas de la Empresa. A
menudo, los procesos de negocio no cuentan con el apoyo adecuado por
parte de las tecnologías subyacentes (una serie de sistemas diferentes y
estructuras de datos incompatibles). El modelo de Cloud Computing de
aplicaciones, formatos de datos y herramientas de desarrollo
estandarizadas contribuye a facilitar la implementación de procesos que
dependen del acceso a los datos compartidos, de la colaboración y del
acceso móvil o remoto.
Una Empresa pretende ofrecer, pasando al modelo de Cloud Computing,
precios entre un 30% y un 50% más bajo que sus competidores en el
almacenamiento y la gestión de documentos digitales. Para ello, está
desarrollando un modelo que incluye escaneo de documentos y
procesamiento deslocalizado. El modelo se basa en sistemas de workflow,
aplicaciones de gestión de procesos, una base de datos comunes y el
almacenamiento disponible a través del Cloud Computing.

2.2.4.3 Nivel de innovación del modelo de negocio

Todas las Empresas se basan en mayor o menor medida en asociaciones
y cooperación con otras Empresas y Organizaciones. Algunos de los
denominados ecosistemas de negocios son bien conocidos, altamente
desarrollados y de gran éxito, tales como el programa Connect and
Develop de Procter & Gamble y la red de proveedores de Toyota Motor.
El Cloud Computing puede ayudar a potenciar la próxima generación de
ecosistemas de negocios al facilitar la deconstrucción de las cadenas de
valor y la aparición de modelos de negocio nuevos e innovadores. La
cadena de valor del sector de la atención médica, por ejemplo, está
formada por compañías farmacéuticas, aseguradoras, médicos, hospitales
y pacientes. En el actual sistema que se observa en muchos mercados,
partes del historial médico de un paciente se almacenan en varias
ubicaciones, pero pocas veces se halla todo el historial en un único lugar.
Poco a poco, los datos de los pacientes y los historiales médicos están
disponibles a través de proveedores de Cloud Computing.

35
 Quest Diagnostics, por ejemplo, pone los resultados de laboratorio a
disposición de los pacientes a través de Google Health y Microsoft
HealthVault, ambos servicios cloud. A pesar de que esto es un pequeño
paso, finalmente podría conducir a que la información fuera más fácilmente
accesible, lo cual puede ayudar a ofrecer una atención médica de una
forma más eficiente y eficaz.

2.2.5 Filosofía de la Web 2.0

Cuando en 1989 Tim Berners-Lee, propuso la creación de la World Wide Web
(WWW), imaginaba un gran espacio de información a través del cual las personas
se comunicaran de forma que compartieran su conocimiento (Berners-Lee, 1999).
Sin embargo el concepto de “lectura-escritura” que Berners-Lee visionó, se perdió
en la primera versión de la WWW. Nos dice Berners-Lee (1999) que el primer
desarrollo incluía un navegador o cliente Web que permitía ver y editar páginas
HTML; por razones de acelerar el proceso de adopción de la Web, la capacidad
de editar con el navegador no fue implementada en esa primera versión. Esta
situación se mantuvo a través del tiempo y llevó a la creencia de que la Web era
un medio en el cual un reducido número de personas podía publicar y el resto
solo podía buscar información.
El término Web 2.0 fue acuñado oficialmente por Dale Dougherty en el 2004, en
una discusión de trabajo referente a una conferencia sobre la Web que se estaba
planificando en O´Reilly Media Inc. La idea por la cual surgió el nombre era la de
que la Web estaba cambiando y que surgían nuevas aplicaciones. Consideraban
que surgía una segunda generación de Web, basada en comunidades de
usuarios y servicios que fomentan la colaboración y el intercambio de información
entre ellos.
Como indican Franklin y Van Harmelen (2007) la Web 2.0 comprende una
variedad de significados, que incluyen: contenidos generados por el usuario,
contenidos y datos compartidos, trabajo colaborativo y nuevas formas de
interactuar con las aplicaciones basadas en Web. Continúan diciendo que
mientras en la Web 1.0 un grupo pequeño de autores generaban el contenido
para una audiencia relativamente pasiva, en la Web 2.0 los usuarios comunes
encuentran una plataforma donde generar, reutilizar y consumir contenidos
compartidos.
Encontramos en la literatura diferentes definiciones para la Web 2.0, así como
diferentes opiniones sobre lo que esta significa. Sin embargo, tomando lo que dice
Tim O´Reilly en su blog, la Web 2.0 es definitivamente sobre las personas;
considera O´Reilly que el principal punto para el éxito de las aplicaciones de la

36
Web 2.0 está en aprovechar la inteligencia colectiva de los usuarios. De la Torre
(2006) hace énfasis en que la principal característica de la Web 2.0 es que ésta
sustituye el concepto de Web de lectura por el de Web de lectura-escritura, siendo
este un término que encontramos repetidamente en la literatura para hacer
referencia a la Web 2.0, “Read-Write Web” o Web de lectura-escritura.
Una manera de entender mejor la Web 2.0 es conociendo las aplicaciones o
sistemas asociados a ella. Estos sistemas residen en servidores y puede
accederse a ellos vía “browser” o navegador. Todas estas herramientas pueden
agruparse bajo el nombre de “software social”, software creado para apoyar los
procesos de trabajo colaborativo de los usuarios (Franklin, Van Harmelen, 2007).
Por otra parte Fumero (2006) nos plantea que la Web 2.0 al permitirnos crear,
editar, publicar y compartir contenidos, le da un significado social a nuestras
acciones.

2.2.5.1 Espacios colaborativos en la actualidad

Para grandes empresas como Microsoft, las redes sociales están
cambiando la forma en que nos relacionamos en el mundo virtual, esto
está afectando no solo los hábitos de interacción sino principalmente la
expectativa que los usuarios tienen de las herramientas. Cada vez que los
usuarios se enfrentan a las limitaciones de los sistemas tradicionales, se
genera una frustración que los impulsa a buscar soluciones más apegadas
a sus expectativas, es por eso que las herramientas más cercanas al
usuario serán las que tengan éxito en este nuevo modelo.
Sin embargo el cambio debe ser cultural. Las empresas deben encontrar la
forma de que haya un “pensamiento colectivo” en la ejecución de
procesos. Un usuario que tiene un problema, en vez de sentirse aislado y
no poder enfrentarlo, ahora se siente virtualmente acompañado y busca
dentro de esta red para solventar su problema”.
El asunto cobra relevancia en la medida que el colaborador se siente parte
clave de los procesos de la compañía, es un tema hasta de Management,
“a medida que hay un mayor involucramiento de los individuos en la toma
de decisiones y opinión sobre temas críticos para la compañía que
normalmente escaparían de sus roles, hay una mayor posibilidad de
expresión e intercambio de ideas, así como a un aumento de la sensación
de horizontalidad en la estructura de mando”.
Aunque claro que todos los beneficios se puede volver en contra si no
tomamos en cuenta temas como la seguridad, la confidencialidad, la
usabilidad y sobretodo la interoperabilidad, es decir que si modifico un

37
 documento utilizando mi dispositivo móvil no comprometo el formato y de
alguna forma pueda dañar el archivo original”.
Pero la colaboración social no será la tendencia por sí sola, nos aclara
Microsoft. El concepto de redes sociales no será el motor de estos
cambios, más bien serán las tendencias de computación en la nube las
que impactarán las inversiones que se deben realizar en cuanto a la
capacidad de las redes de datos y la implementación del concepto de nube
privada impactará de lleno en los requisitos de almacenamiento.

2.2.5.2 Atlassian Confluence

Confluence fue desarrollada por la empresa australiana Atlassian, este
software facilita la colaboración en equipos de trabajo, con cientos de
características para ayudar a los usuarios de cualquier organización a
crear contenido rico, rápido y fácilmente. Confluence es una herramienta
de creación colaborativa de contenido usada por más de 12.000
Organizaciones y millones de usuarios en todo el mundo, para ayudarles a
crear, compartir y conversar conjuntamente sobre proyectos, ideas,
facturas, especificaciones, mockups, diagramas y ficheros. Algunos de los
clientes son Boeing, Citigroup, Facebook, Intuit, Netflix, la Universidad de
Stanford, Zynga y muchos otros.
“Confluence ofrece una experiencia de edición potente e intuitiva que
cambiará la forma en la que los equipos crean contenido y colaboran en
proyectos online” dice Mike Cannon-Brookes, CEO y co-fundador de
Atlassian, además agrega que “no hay nada que iguale la facilidad de uso
y su profundidad de sus características.”
El lema bajo el cual funciona Confluence es “menos reuniones, más
resultados” ya que representa un punto de encuentro online para que los
equipos colaboren y compartan conocimiento. Tiene además integración
con Office y JIRA, y cientos de complementos que ayudaran a los equipos
a crear intranets, documentación técnica y centros de conocimiento, a
pesar de que Confluence es un producto comercial, se dan licencias gratis
para proyectos open-source, instituciones sin ánimo de lucro y
organizaciones caritativas, como es el caso del CIP.

2.2.5.3 Atlassian JIRA

Es una aplicación basada en web para el seguimiento de errores, de
incidentes y para la gestión operativa de proyectos. JIRA también se utiliza

38
 en áreas no técnicas para la administración de tareas, la herramienta fue
desarrollada por la empresa australiana Atlassian.
Inicialmente JIRA se utilizó para el desarrollo de software, sirviendo de
apoyo para la gestión de requisitos, seguimiento del estatus y más tarde
para el seguimiento de errores, JIRA puede ser utilizado para la gestión de
procesos y para la mejora de procesos, gracias a sus funciones para la
organización de flujos de trabajo.
JIRA es una herramienta de gestión de proyectos que ayuda a los equipos
a construir mejor software, JIRA se sitúa en el centro de su proceso de
desarrollo, conectando su equipo con el trabajo gestiona bugs, enlaza
tareas con el código relacionado, planifica ágilmente, monitorea la
actividad, y obtiene informes sobre el estado del proyecto y mucho más.
En todo el mundo JIRA cuenta con más de 11.500 clientes en 107 países,
a pesar de que JIRA es un producto comercial, se dan licencias gratis para
proyectos open-source, instituciones sin ánimo de lucro, organizaciones
caritativas y personas individuales.

2.3 MODELO APLICATIVO

El modelo aplicativo a utilizar es una variante del autor de la “Guía para la migración de
software libre en las entidades públicas del Perú” elaborado por el Instituto de
Estadística e Informática del Perú en el año 2002 y respaldado de la Oficina Nacional de
Gobierno Electrónico e Informática.
Esta metodología en el nivel de planeamiento comprende el diagnóstico, la evaluación
de herramientas/aplicaciones a migrar, la implementación, pruebas, capacitación y
documentación del proceso. Los lineamientos de la guía en las entidades públicas
aplican un método de trabajo general e integral para migrar los sistemas de información,
servidores de base de datos, aplicaciones, gestión y administración de la plataforma, la
metodología empleada describe en detalle las fases a seguir en el proceso de migración
y contempla que cada Institución pueda otorgar a cada fase de la metodología el
esfuerzo que considere necesario dependiendo del grado de automatización de los
procesos estratégicos de cada institución, de la plataforma tecnológica y de la
infraestructura existente, también es flexible para que cada Institución pueda efectuar
reajustes o realizar procesos con mayor nivel de detalle dependiendo de la complejidad
de su plataforma tecnológica y de los recursos que se asignen.
Para el caso de la migración de las herramientas colaborativas hacia la nube y a
diferencia del caso de la migración de software libre no se pone mucho interés en la
capacitación al usuario final ya que la migración hacia la nube no implica un cambio en
las herramientas utilizadas, por el contrario se trata de evitar todo cambio visual al

39
usuario final (a menos que implique también una actualización de la herramienta, pero
no por el resultado en sí de la migración hacia la nube), el cambio que deberá ver
reflejado el usuario final será que el procesamiento, cálculo, tiempo de carga y demás
deberá de tener una mejor performance.
Otra diferencia que contempla la migración hacia la nube es que la fase de
implementación se contempla en 2 fases, la primera fase que es la preparación y puesta
en marcha del servidor en la nube, comprobando que se tenga todo correctamente
instalado y configurado haciendo pruebas de funcionamiento de las aplicaciones y una
segunda etapa del día de la migración en sí, el cual por ser un espacio colaborativo
deberá ser con los últimos cambios realizados por los colaboradores, ésta segunda
implementación significa en si la adopción o migración hacia el nuevo servidor en la
nube, el cual deberá tomar de preferencia como máximo 1 día no laborable para evitar
en lo posible la perdida de horas de trabajo. En el Gráfico Nº 2.2 se puede ver las
diferencias que contempla la nueva metodología propuesta por el autor que es una
variante existente del usado en la migración de software libre a nivel nacional.
Gráfico Nº 2.2
Comparación de metodologías de migración

Fuente: Propia
Elaboración: Propia
Cómo se ve en la Gráfica Nº 2.2 la metodología de software libre pone bastante interés
en la capacitación al usuario final ya que la adopción de software libre implica un cambio
en su trabajo cotidiano, que en algunos casos resulta completamente significativo, la otra
gran diferencia es que el proceso de migración e implementación en si del software libre
se realiza de manera gradual, lo cual toma algunos días o semanas de trabajo a partir de
la migración, por el contrario en la migración a la nube el mayor trabajo se realiza previo

40
a la migración y el usuario verá el cambio reflejado desde el mismo instante de la
migración.
Estas 3 etapas generales de migración están desarrolladas en 7 fases de la
metodología, las cuales son:

PRE MIGRACIÓN:
Fase 1. Planeamiento general de la migración.
Esta fase corresponde a la planificación global y para el éxito de la misma es importante
contar con el compromiso y apoyo de la alta dirección. El plan de migración está
conformado por una serie de acciones agrupadas estratégicamente en etapas para
lograr migrar el espacio colaborativo integrado, debe haber participación activa del área
de informática y otras áreas encargadas de administrar los espacios colaborativos de
investigación, en esta fase interviene más la interacción humana que el desarrollo o
elaboración de algún entregable físico sin embargo se han identificado 2 actividades:
 Sensibilización organizacional
 Organización de grupos de trabajo y responsabilidades

Fase 2. Diagnóstico del estado actual.

En esta fase se registraran la situación actual de los servidores que se utilizan, como sus
características físicas, configuraciones de seguridad, mecanismos de respaldos de
backup, información técnica disponible, de igual manera se debe evaluar las
herramientas colaborativas integradas verificando las versiones utilizadas, en el caso de
las bases de datos es muy importante comprobar la integridad de la misma, el desarrollo
de esta fase está dividida en 4 actividades:
 Diagnóstico de la infraestructura física actual.
 Diagnóstico de la configuración actual de los servidores.
 Diagnóstico de las actuales aplicaciones colaborativas.
 Diagnóstico del motor de base de datos actual.

Fase 3. Evaluación de alternativas de migración.

En la evaluación de alternativas es necesario analizar una serie de elementos, entre los
cuales está la disponibilidad presupuestal con que se cuenta para ver la factibilidad total
o parcial de la migración, la infraestructura requerida para las bases de datos y las
herramientas colaborativas.
Las actividades a realizar son principalmente 2 de evaluación y de selección:
 Evaluación general de los proveedores de Cloud Computing
 Selección del proveedor y capacidad informática en el Cloud Computing

41
MIGRACIÓN:
Fase 4. Configuración y pruebas de la nueva infraestructura.
En esta fase se creara la nueva instancia donde funcionaran los servidores virtuales en
la nube, considerando temas como la seguridad, rendimiento, integridad, etc. también
se debe realizar pruebas de funcionamiento y pruebas de accesos y restricciones, así
como pruebas de alta del servicio colaborativo, es importante además tratar aprovechar
todos los beneficios que nos ofrece la computación en la nube. Esta fase constituye la
de mayor tiempo ya que deberá de dejar toda la infraestructura lista para la migración y
está dividida en las siguientes actividades:
 Creación de las nuevas Instancias
 Configuraciones de seguridad
 Instalación de los principales servicios
 Acceso al servidor virtual
 Configuración, acceso y envío de la base de datos
 Pruebas de funcionamiento

Fase 5. Migración del espacio colaborativo integrado y base de datos que la

soporta.
En esta fase que debería durar en promedio máximo 1 día, es la fase más crítica ya que
se tiene al tiempo como un factor en contra pues implica que el servicio colaborativo no
esté disponible o esté disponible solo para consultas, en esta fase es importante
comunicar a todos los usuarios que podrían existir problemas en el acceso al servicio
colaborativo, las actividades principales son las siguientes:
 Notificación a los colaboradores
 Transferencia de archivos al servidor destino
 Comprobación de integridad de base de datos a nivel de estructura y datos
 Configuraciones generales y especificas
 Inicialización de los servicios colaborativos
 Comprobación de la migración

POST MIGRACIÓN:
Fase 6. Soporte y monitoreo.
Esta fase consiste en monitorear y gestionar los sistemas de manera efectiva para
lograr una administración más eficiente de la plataforma, siendo necesario la visibilidad
del ambiente operativo y habilitando una planificación efectiva. Además, se debe
proporcionar una respuesta expeditiva ante inconvenientes de funcionamiento y ayuda a
los procesos que garantizan la estabilidad de los servidores y de los sistemas y base de
datos que en ella funcionan.
42
 Fase 7. Documentación.
Esta fase es realidad una fase permanente, que se inicia desde el diagnóstico y va hasta
el soporte y monitoreo, se pone como fase final ya que es al final se puede agrupar y
ordenar la documentación generada en cada fase, su importancia radica en que esto
ayuda a otra persona entender el proceso de migración entendiendo el propósito,
evaluaciones, configuraciones y demás, esta fase nos servirá como retroalimentación
para futuros proyectos.
En el gráfico Nº 2.3 se puede ver el diagrama de la metodología a emplear.
Gráfico Nº 2.3
Metodología de migración utilizada

Fuente: Propia
Elaboración: Propia
Estas fases pueden tener pequeños reajustes dependiendo de la complejidad de la
plataforma tecnológica, la fase de migración del espacio colaborativo y BDs hace
mención al día fijado para la migración y es la fase más crítica de la metodología, la fase
de documentación si bien es cierto se menciona al final de la metodología es una fase
permanente desde el inicio hasta el final, se considera como última fase ya que deberá
de consistir en reunir toda la documentación generada en el proceso de migración.

2.4 MARCO CONCEPTUAL

 Amazon Elastic Compute Cloud (Amazon EC2). Es un servicio web que proporciona
capacidad informática con tamaño modificable en la nube. Está diseñado para
facilitar a los desarrolladores recursos informáticos escalables y basados en web.
 Amazon Web Services (AWS). Es un servicio web que proporciona una plataforma
de infraestructura escalable de alta fiabilidad y de bajo coste en la nube, su
tecnología es segura y duradera con certificaciones y auditorías reconocidas

43
 Acuerdos de Nivel de Servicio (SLA). Es un acuerdo negociado entre un cliente y un
proveedor que registra un entendimiento común acerca de la calidad del servicio en
aspectos tales como tiempo de respuesta o disponibilidad horaria.
 Computación en la nube o “Cloud Computing”. Es un estilo de computación en el que
se ofrecen capacidades de tecnología de computación extremadamente flexibles y
escalables a varios clientes en forma de servicio mediante tecnología de Internet.
 Confluence. Es una herramienta de creación colaborativa de contenido para
ayudarles a crear, compartir y conversar conjuntamente sobre proyectos, ideas,
facturas, especificaciones, mockups, diagramas y ficheros.
 Datacenter o centro de datos. Es una instalación utilizada para albergar sistemas de
ordenadores y sus componentes asociados, esta instalación concentra todo o parte
de los recursos necesarios para el procesamiento de la información de una
Organización.
 Espacio colaborativo. Son los espacios o sitios que permiten acceder a ciertos
servicios que facilitan a los usuarios comunicarse y trabajar conjuntamente sin
importar que estén reunidos en un mismo lugar físico.
 Habilitadores. Los habilitadores se diferencian de los proveedores porque ofrecen
algún elemento de un producto o servicio de la nube; por ejemplo, los proveedores
de plataforma como servicio.
 Instancia. Es un conjunto de recursos de computación que están disponibles para
una imagen en ejecución y es el equivalente de lo que sería un hardware real sobre
el que ejecutar un sistema operativo.
 JIRA. Es una aplicación basada en web para el seguimiento de errores, de incidentes
y para la gestión operativa de proyectos.
 Migración de servidor. Es el proceso que consistente en hacer que los datos y las
aplicaciones existentes funcionen en una computadora, software o sistema operativo
distinto.
 Pay-per-use o pago por uso. Es un sistema de tarificación por el cual el cliente paga
a un proveedor de servicios únicamente por la utilización que hace del servicio
prestado. El cliente soporta un costo variable proporcional al consumo que realiza del
recurso.
 Portabilidad. La portabilidad de los servicios de nube se refiere a la facilidad para
cambiar de un proveedor a otro; un proceso que estaría garantizado, si se
establecieran estándares, lo cual aún no ha ocurrido.
 Potencia de cómputo (ECU). En las instancias es el recurso que modela lo que sería
el procesador de un servidor tradicional se denomina ECU (EC2 Compute Unit) el
cual es la unidad de cómputo de la instancia.

44
  Proveedores. Las compañías que crean un ambiente de computación en la nube,
incluyendo servidores, software, almacenamiento y otros recursos disponibles a los
usuarios vía Internet, son proveedores de servicios de nube.
 Servidor virtual. Es una reproducción plenamente operativa de un servidor físico pero
que no dispone de recursos computacionales dedicados, sino que los comparte con
otros servidores virtuales por medio de la tecnología conocida como virtualización.
 Servicios administrados. Son servicios ofrecidos por un proveedor a sus clientes, que
usan algunos de los principios de la computación en la nube. A diferencia de la
computación en la nube, los servicios administrados son gestionados totalmente por
el proveedor.
 Sistema de gestión de bases de datos. También conocido como motor de bases de
datos, es el servicio principal para almacenar, procesar y proteger datos
proporcionando acceso controlado y procesamiento de transacciones rápido.
 Virtualización. Consiste en que las aplicaciones ya no están sujetas a restricciones
físicas, es decir, que no es necesario que se encuentren en el mismo lugar que la
infraestructura informática. Este método permite equilibrar los recursos físicos entre
los servidores virtuales en función de la demanda de cada uno.
 Web 2.0. Es una forma de entender Internet donde el usuario de la red pasa de ser
un consumidor de contenidos a participar en la construcción y elaboración de los
mismos, donde la Web se convierte en plataforma.
 Wiki. Es una forma de sitio web en donde se acepta que usuarios, creen, editen,
borren o modifiquen el contenido de una página web, de una forma interactiva, fácil y
rápida.
 Zonas de disponibilidad. Son centros de proceso de datos, cada zona de
disponibilidad se ejecuta en su propia infraestructura, independiente y físicamente
diferente, y está diseñada para garantizar una elevada fiabilidad.
En este capítulo se revisado algunas investigaciones anteriores también se ha establecido
las bases teóricas, en ambos caso se ha tratado de poner mayor énfasis en el tema de
computación en la nube (o Cloud Computing) ya que como es una tecnología que se
encuentra en su fase inicial no se tiene claro algunas definiciones nuevas, adicionalmente se
consideró conceptos de espacios colaborativos, la metodología ha emplear ha sido
brevemente descrita y será desarrollada en próximos capítulos.

45
 CAPITULO III
INTERVENCIÓN METODOLÓGICA

En el presente capítulo se desarrollará las fases de la metodología sobre la migración a la

nube, como ya se mencionó la fase de documentación es una fase transversal en el tiempo
ya que contiene la documentación de las otras fases y sirve para la retroalimentación
posterior, pero se consideró al final para indicar que se debe de clasificar y organizar dichos
documentos. Las fases desde uno hasta el seis son teóricamente una posterior a la otra, sin
embargo dependiendo de los diferentes escenarios que se pueda encontrar, podría caber
que en algún momento se desarrollen algunas fases de manera paralela.

3.1 FASE UNO: PLANEAMIENTO GENERAL DE LA MIGRACIÓN

Esta fase corresponde a la planificación global, el éxito de esta fase dependerá del
compromiso general y apoyo de la alta dirección. Esta primera fase es más de gestión
que de carácter de análisis o técnico pues implica reuniones y coordinaciones, motivo
por el cual está poco desarrollada en la presente investigación.
En esta fase interviene más la interacción humana que el desarrollo o elaboración de
algún entregable físico, sin embargo se tiene identificado 2 actividades principales, la
primera es de sensibilización organizacional y la segunda es la actividad de organización
de grupos de trabajo y responsabilidades.

3.1.1 Sensibilización organizacional

La necesidad de mejora del sistema colaborativo integrado fue desde el primer
momento compartido y apoyado por la Unidad de Investigación Informática (RIU),
el área de RIU administra los servicios colaborativos de investigaciones y también
desarrolla herramienta de escritorio y web de apoyo a la investigación en el CIP,
sin embargo existe otra unidad, la Unidad de Tecnología de Investigación (ITU)
que es la encargada de proporcionar y administrar la infraestructura tecnológica
del CIP, es importante mencionar que en el caso de los sistemas y servidores
administrativos el área de ITU es el único responsable, en cambio en los

46
 servidores de investigación existe una función compartida, por una parte el área
de ITU administra el correcto funcionamiento del hardware de los servidores, así
como la administración de los backup, asegurar la conectividad a la red,
administra las políticas de seguridad, la administración y control de la sala de
servidores, etc. y el área de RIU se encarga desde la instalación y configuración
del sistema operativo además de la configuración, instalación y administración de
las aplicaciones y bases de datos de investigación.
Esta distribución responde básicamente a que la infraestructura que soporta los
procesos administrativos utiliza tecnología Microsoft, por ejemplo sus servidores
corren en Microsoft Server 2008, utilizan como motor de base de datos SQL
Server 2008 y sus aplicaciones se desarrollan en .Net, en cambio la
infraestructura de investigación es en gran parte open-source, los servidores
tienen Suse Enterprise, el motor de base de datos es MySQL Enterprise y la
programación web se realiza con PHP, esto debido a que casi toda la información
generada por la parte del área de investigación es compartida a múltiples socios,
investigadores y público en general a nivel mundial.
Como primer objetivo se necesitó contar con el respaldo del área de ITU para
poder migrar las aplicaciones colaborativas a la nube ya que el proveedor del
Cloud Computing es el encargado de la administración de los servidores virtuales
(función antes desempeñada por el área de ITU) otorgando la administración
desde la instalación del sistema operativo; esto origino en un inicio desconfianza
en el proyecto iniciado, sin embargo esto fue aprobado ya que los beneficios del
Cloud Computing sólo serían mediamente compensados con una fuerte inversión
en nueva infraestructura, para lo cual no había suficiente presupuesto.
Luego de contar con el apoyo del área de ITU, la aprobación por parte de la alta
dirección fue más sencilla ya que se hizo ver los beneficios que traería a los
colaboradores de otras regiones, lo cual en el contexto de integración y
acercamiento con todas las oficinas regionales podría tomarse como una
reorientación de la política del CIP hacia las regiones. Finalmente se comunicó a
las regiones que se estaba iniciando un proceso de mejora del servicio
colaborativo actual, teniendo como meta que tengan un experiencia de servicio
significativamente mejor a la actual.

3.1.2 Organización de grupos de trabajo y responsabilidades

Como se mencionó anteriormente el área de ITU era la encargada de la
administración de la infraestructura física de los servidores de investigación,
trabajo que en parte seria asumido por el proveedor del Cloud Computing, motivo
por el cual el trabajo desde la selección del sistema operativo, configuraciones y

47
 puesta en marcha recaería en el área de RIU, por lo cual se elaboró algunas
actividades y responsabilidades generales para la migración hacia la nube, las
cuales se pueden apreciar en la Tabla Nº 3.1.
Tabla Nº 3.1
Organización de grupos de trabajo y responsabilidades

Tarea General Encargado Dificultad

Evaluación y contacto con proveedores de Cloud Computing RIU Media

Selección del proveedor de Cloud Computing RIU/ITU Media

Instalación, configuración y pruebas en el servidor en la
RIU Alta
nube
Coordinación con el proveedor CGNET para cambio en el
ITU Baja
direccionamiento del sitio, autentificación LDAP.
Migración hacia el servidor de la nube RIU Alta

Soporte y monitoreo RIU Media

Documentación RIU Media

Fuente: Centro Internacional de la Papa

Elaboración: Propia

Las tareas descritas en la Tabla Nº 3.1 corresponden casi a cada fase descrita en
la metodología ya que su realización es de manera iterativa pues podrían
aparecer o agrupar algunas tareas y/o responsabilidades en el transcurso de la
investigación, también es necesario precisar que la tarea de selección de
proveedor y coordinación con el proveedor de CGNET son en realidad sub tareas,
pero que se muestra como tareas generales para precisar la participación
especifica del área de ITU ya que se entiende que todos los demás procesos de
migración son responsabilidades casi exclusivas del área de RIU.

3.2 FASE DOS: DIAGNÓSTICO DEL ESTADO ACTUAL

En esta fase se registra la situación actual de la infraestructura que se utiliza, es decir las
características físicas, configuraciones de seguridad, grado de seguridad, confiabilidad e
integridad tanto de los servidores, herramientas colaborativas integradas y de las bases
de datos donde se almacenan.
Las características generales de los servidores de investigación del CIP fueron descritos
en el planteamiento del problema, en esta sección nos centraremos solamente a los 2
servidores virtuales que soportan los sistemas colaborativos integrados. El desarrollo de
esta fase será sintetizada en tablas descriptivas dividida en 4 etapas: diagnóstico de la
infraestructura física, diagnóstico de configuraciones de los servidores, diagnóstico
general de la las aplicaciones colaborativas y diagnóstico de la base de datos.
48
3.2.1 Diagnóstico de la infraestructura física actual
Para los espacios colaborativos se tiene 2 servidores con sistema operativo Suse
Enterprise 10, estos servidores tienen una tecnología de hace casi 5 años, los
cuales fueron repotenciados en el tiempo con aumento de disco duro y memoria
RAM, ambos servidores tienen casi las mismas características técnicas (100 GB
de disco duro y 4 GB de memoria RAM).
Según reportes de la solución de red conocida como Cacti (es una herramienta
web que crea gráficos diseñados a partir del almacenamiento de datos de uso de
conexión a internet, status, uso de memoria, etc. de los servidores) mencionan
que se están presentando problemas imprevistos de error de funcionamiento
debido principalmente a la antigüedad de la infraestructura; se tiene conocimiento
que de fallar algún componente clave como memoria RAM o disco duro conseguir
un componente el reemplazo va ser muy difícil ya que son componentes
discontinuados y el reemplazo podría tomar varios días. Las principales
características técnicas se pueden apreciar en la tabla Nº 3.2.
Tabla Nº 3.2
Diagnóstico de la Infraestructura actual

VM – Java
Almacenamiento y procesamiento
Disco Duro: 100GB
Espacio libre disponible: 60GB
Procesador: AMD Opteron(tm) Processor 844
CPU MHz: 1802.834
Memoria
Total: 3801Mb
Usada: 3606Mb
Infraestructura Libre: 195Mb
Actual VM – MySQL
Almacenamiento y procesamiento
Disco Duro: 100GB
Espacio libre disponible: 97GB
Procesador: AMD Opteron(tm) Processor 844
CPU MHz: 1802.245

Memoria
Total: 3804Mb
Usada: 3629Mb
Libre: 175Mb
RP1. Infraestructura antigua mayor a 5 años.
Problema
RP2. Algunos componentes discontinuados.
Riesgo
RP3. Comparten infraestructura física con otros servidores que
Potencial
reportaron errores.
Fuente: Centro Internacional de la Papa
Elaboración: Propia

49
 En la Tabla Nº 3.2 se muestra la cantidad de memoria libre y usada en el sistema,
hay que tener en cuenta que el término “memoria usada” en Linux significa
memoria tomada por el sistema, de forma que pueda ser empleada por usuarios y
aplicaciones, así mientras más memoria usada se tenga es mejor. También se
puede ver los problemas actuales y/o riesgos potenciales, en este caso se
mencionan 3 riesgos potenciales debido principalmente a la antigüedad de la
misma de los cuales en el escenario de llegar a suceder alguno de los
mencionado podría representar corte en el servicio colaborativo de algunas horas
o incluso días lo cual supondría algo muy grave, ya que como alternativa más
práctica se deberá de habilitar algún servidor temporal.

3.2.2 Diagnóstico de la configuración actual de los servidores

El servidor Java in-house (VM-Java) es el servidor que tiene salida a internet a
través del subdominio http://research.cip.cgiar.org, incluso las aplicaciones hechas
en PHP tienen salida por el mismo subdominio. Confluence y JIRA están
desarrolladas en Java y trabajan con Tomcat Apache (ver Gráfico Nº 3.1) que
utiliza el puerto 8080 y tienen salida a través de Apache, para el caso de
Confluence https://research.cip.cgiar.org/confluence y para el caso de JIRA
https://research.cip.cgiar.org/JIRA, ambas direcciones se van a mantener ya que
existentes numerosas aplicaciones, páginas web, etc. que referencian a dichas
direcciones además como se mencionó anteriormente la idea es que el usuario no
tenga ningún cambio visual luego de la migración.
Gráfico Nº 3.1
Panel de administración de Tomcat Apache

Fuente: Centro Internacional de la Papa

Elaboración: Centro Internacional de la Papa
En el gráfico anterior vemos el panel de administración de Tomcat Apache que
utiliza el puerto 8000, para dar salida se utiliza una configuración en Apache
conocida como Apache reverse proxy que es utilizado para tener un servidor
HTTP como frontend, redirigiendo las peticiones hacia otros (uno o más) que se
encuentran detrás de él, no accesibles directamente.

50
 Las aplicaciones actuales de Confluence y JIRA están instaladas en el modo
EAR-WAR distribución que está diseñada para el despliegue en un servidor de
aplicaciones J2EE existentes, sin embargo Atlassian recomienda no desplegar
otras aplicaciones en el contenedor Tomcat que corre Confluencia o JIRA, sobre
todo si estas otras aplicaciones tienen grandes requisitos de memoria o que
requieren bibliotecas adicionales en el subdirectorio lib de Tomcat. En la tabla Nº
3.3 vemos un resumen del diagnóstico de la configuración general.
Tabla Nº 3.3
Diagnóstico de la configuración actual

URLs:
https://research.cip.cgiar.org/confluence
https://research.cip.cgiar.org/JIRA

Tomcat:
Configuración actual Utilizan Apache Tomcat/5.5.28. puerto 8000

Seguridad:
Utiliza certificado de seguridad HTTPS

Salida:
Uso de Apache reverse proxy

RP1. De existir algún problema en Confluence o en JIRA u

Problema / Riesgo
otra aplicación contenida en Tomcat podría llevar a se caiga el
Potencial servidor Tomcat Apache por lo cual se caerían todos los
servicios.

Fuente: Centro Internacional de la Papa

Elaboración: Propia
Como vemos en la Tabla Nº 3.3 existen riesgos por el uso de Tomcat Apache,
para esto Atlassian recomienda utilizar la instalación estándar de Confluence y
JIRA, sobre la configuración de proxy del Apache se piensa mantenerse ya que
tiene varios beneficios pues evitamos la necesitan de estar utilizando diferentes
direcciones y/o ingresando los puertos por los cuales se conecta el servidor.

3.2.3 Diagnóstico de las actuales aplicaciones colaborativas

Actualmente tenemos instalado la versión 3.1 de Confluence y la versión 4.3.3 de
JIRA, en caso de JIRA estamos 2 versiones desactualizadas y en el caso de
Confluence se encuentre 5 versiones desactualizadas. Hay que tener en cuenta
que las versiones posteriores a Confluencia 3.1 son lanzamientos de corrección
de errores que incluye revisiones para LDAP y la gestión de usuarios, con varias
mejoras para los clientes; en el caso de JIRA las últimas versiones tienen nuevas
características que proporcionan a los administradores la capacidad de
administrar los filtros de otros usuarios comunes y cuadros de mando compartido,

51
 además de varias actualizaciones y correcciones. En la Tabla Nº 3.4 se puede ver
algunas características de las aplicaciones colaborativas.
Tabla Nº 3.4
Diagnóstico de las aplicaciones colaborativas

Confluence v3.1:
Total Spaces 102
Global Spaces 96
Personal Spaces 6
Content (All Versions) 43986
Content (Current Versions) 6826
Local Users 863
Local Groups 490
Search Index Size 38315
Aplicaciones actuales
JIRA v 4.3.3:
Issues 3511
Projects 59
Custom Fields 24
Workflows 2
Attachments 415
Comments 1606
Users 981
Groups 340

Problema / Riesgo
P1. No se aprovecha las mejoras de las últimas versiones de
Potencial Confluence y JIRA.

Fuente: Centro Internacional de la Papa y Atlassian

Elaboración: Propia
Como se puede ver en la tabla 3.4 existe una gran actividad de los espacios
colaborativos, el número de usuarios, proyectos y espacios creados hablan del
buen funcionamiento a nivel local de los espacios colaborativos, el problema
radica en que no se aprovecha los beneficios de las últimas versiones de las
aplicaciones colaborativas, esto debido a que hasta versiones anteriores la
actualización de Confluence y JIRA eran muy tediosas, actualmente se realizan de
manera más fácil y ágil lo cual implica sólo un trabajo de 2 horas en promedio.

3.2.4 Diagnóstico del motor de base de datos actual

El motor de base de datos utilizado es MySQL Enterprise 5.0.6 la cual es una de
las últimas versiones disponibles, Confluence y JIRA utilizan bases de datos
independiente, pero forman parte de las 39 base de datos que administra este
servidores centralizado de base de datos. En la Tabla Nº 3.4 vemos algunas cifras
de las base de datos que utilizan Confluence y JIRA, si bien es cierto este servidor
es centralizado tiene una muy buena performance.
En la Tabla Nº 3.5 vemos algunas características de las bases de datos y se nota
claramente que se tratan de bases de datos con un considerable volumen, tanto
52
 en el número de registros y tablas, la cual hay que considerar ya que cuando se
migre las aplicaciones la comprobación de integridad a través de herramientas
como MySQL Compare puede tomar hasta 40 minutos por cada evaluación.
Tabla Nº 3.5
Diagnóstico del motor de base de datos

Version: 5.0.60sp1-enterprise MySQL Enterprise

Server (GPL)
Base de datos: 39

Confluencedb (422.5 MB):

Rows(promedio) 7276
Motor de base de Avg_row_length 512299
Data_length 385733380
datos actual Index_length 15916032

Jiradb (10.5 MB):

Rows(promedio) 705
Avg_row_length 11950
Data_length 6401389
Index_length 3180544

Problema /
I1. La comprobación de integridad de las bases de datos
Inconveniente consume muchos recursos ya que son pesadas.

Fuente: Centro Internacional de la Papa

Elaboración: Propia
En la tabla Nº 3.5 el término rows hace referencia al número de registro promedio
que tiene cada tabla de la base de datos, avg_row_length se refiere al promedio
de bytes usados por las filas de la tabla, data_length es el tamaño actual en bytes
de fichero de tabla e index_length es el tamaño actual en bytes del archivo de
índice. A partir del diagnóstico solo se encontró un inconveniente menor ya que la
comprobación de integridad a través de herramientas como MySQL Compare
puede tomar en promedio 40 minutos y cuando se hagan pruebas y se realice la
migración se debe de realizar este procedimiento varias veces.

3.3 FASE TRES: EVALUACIÓN DE ALTERNATIVAS DE MIGRACIÓN

En la evaluación de alternativas es necesario analizar una serie de elementos, entro los
cuales está la disponibilidad presupuestal, el Centro Internacional de la Papa ha
presupuestado en promedio $3000.00 anuales por cada servidor, monto que según
primeras estimaciones son acordes a lo que ofrecen los distintos proveedores de Cloud
Computing, ya que la facturación se realiza por el tiempo de uso.
En cuanto a la infraestructura necesaria, según especificaciones técnicas de Atlassian
para Confluence los requisitos de memoria dependerá del número de proyectos y
asuntos que se almacenan, sin embargo asignando 1.5 GB de memoria dedicada a cada
53
servicio es suficiente para la mayoría de los propósitos de evaluación, los requisitos de
almacenamiento variarán dependiendo del número de páginas y archivos adjuntos que
desee almacenar en el interior Confluence, por ejemplo un servicio con muy alto tráfico
necesitaría 9.4 GB de espacio.
El hardware necesario para ejecutar JIRA en producción depende principalmente de la
cantidad de temas y usuarios que la instalación tendrá, así como el número máximo de
solicitudes simultáneas que el sistema va a experimentar durante las horas pico, como
referencia, un sitio con muy alto contenido de 125.000 temas y más de 70.000 cuentas
de usuario utiliza sólo el 1,5 GB de memoria dedicada y en caso de almacenamiento en
promedio es 1 GB de espacio. En caso del servidor de MySQL, se trata de un servidor
dedicado por lo cual no existen problemas de falencias de infraestructura tecnológica.
Conociendo lo anterior se va evaluar los proveedores de Cloud Computing, en modelo
seleccionado es el conocido como IaaS o modelo de infraestructura ya que permite
obtener capacidad informática para las aplicaciones críticas sin tener que diseñar,
adquirir, construir y gestionar la infraestructura subyacente.
Como se vio en el marco teórico existen principalmente 3 proveedores de IaaS en el
Cloud Computing, los cuales son Cloudbuilder, RackSpace Cloud y Amazon Elastic
Compute Cloud, las cuales fueron evaluadas, mostrando a continuación los principales
beneficios e inconvenientes.

3.3.1 Evaluación general de Cloudbuilder

Arsys cloudbuilder es un servicio IaaS que ofrece Arsys con el centro de datos en
España (Logroño). Cloudbuilder utiliza tecnologías como VMware vSphere,
servidores IBM, cabinas de almacenamiento de HP 3PAR y su centro de datos
tiene capacidad para más de 15.000 servidores.
Cloudbuilder tiene dos categorías cloud público y cloud privado.
 Cloudbuilder público: Es una solución que permite desplegar infraestructuras
virtuales de hardware y software, sin necesidad de planificaciones previas, ni
inversiones iniciales y pagando exclusivamente por el uso de los recursos que
se utilicen. En esta solución hay dos características. Estándar y Premium.
La versión estándar permite crear hasta 10 servidores, límite de 4 CPU por
servidor, 8 GB de memoria RAM y un límite de 500 GB de espacio en disco
por servidor, la versión Premium permite crear ilimitados servidores, límite de
8 CPU por servidor, 128 GB de memoria RAM y un límite de 2000 GB de
espacio en disco por servidor.
 Cloudbuilder privado: Es una solución Cloud Computing que ofrece los
servicios para su uso dentro de un entorno exclusivo, reduciendo los costes
de mantenimiento e inversión en infraestructuras.
54
 La posibilidad evaluada es la versión estándar de Cloudbuilder público, se accedió
a la opción de prueba que ofrece la Compañía la cual se puede ver en el Gráfico
Nº 3.2.
Gráfico Nº 3.2
Panel de Control de Cloudbuilder

Fuente: Cloudbuilder
Elaboración: Propia
Como se puede apreciar en el Gráfico Nº 3.2 el panel de administración es muy
amigable e intuitivo, permite fácilmente crear servidores virtuales y también
realizar cambios de configuración en los servidores existentes, todo el panel y el
soporte en general está en español y tiene como un factor importante que se
encuentra basado en VmWare vSphere, tecnología muy extendida en las
compañías. Sin embargo tiene algunos puntos negativos que se pudieron
observar, uno es que existe un pago mínimo mensual y no existe una API para
poder gestionar los servicios, además a diferencia de otros proveedores no
contempla otras regiones de los datacenter, solamente se pueden crear los
servidores en España, y si en algún momento quisiéramos migrar a otra región
sería imposible. Finalmente un factor decisivo para no optar con este proveedor es
que se trata de una Empresa relativamente nueva en caso que no tenga éxito o no
sea viable a largo plazo nos veríamos desprotegidos, en resumen se trata de un
buen servicio que le falta madurez.

3.3.2 Evaluación general de RackSpace Cloud

RackSpace Cloud es un paquete de soluciones de hosting en la nube, que permite
tener acceso a los propios servidores virtuales, completamente configurable y con
planes de pago muy flexibles, desde tarifas por hora de uso a planes fijos
mensuales. El costo puede ser mayor que el de un servidor común, pero cuando
el proyecto tiene perspectivas de crecimiento, la escalabilidad que tiene este
servicio es ideal, ya que es muy fácil de ir acompañando los requerimientos de
transferencia adicionales. La característica de los servidores va desde 256MB de
55
memoria RAM y 10GB de disco duro a 30,720MB de memoria RAM y 1200GB de
disco, para la evaluación requerimos de un servidor con 8,192MB RAM y 320GB
de almacenamiento.
A primera vista, la estructura de precios del servicios luce similar, pero cuando
entramos se ve los detalles se hacen visibles diferencias sustanciales, sin
embargo el punto importante sobre el cual RackSpace lleva ventaja a otros
competidores es el soporte, ya que tienen una opción de chat en vivo con sus
especialistas, en el Gráfico Nº 3.3 se muestra el panel de administración de
RackSpace Cloud.
Gráfico Nº 3.3
Panel de Control de RackSpace Cloud

Fuente: RackSpace Cloud

Elaboración: Propia
Como se puede ver en el Gráfico Nº 3.3 el panel de control incluye la interface de
gestión para los sitios de la nube, Cloud Servers y servicios Cloud Files. La opción
de administración de archivos basado en web fue eliminado por razones no
reveladas, también permite a los usuarios gestionar múltiples clientes y lo mismo
los planes y los productos.
Los servidores de RackSpace Cloud se encuentran físicamente en cualquiera de
los cuatro centros de datos: Chicago, IL, Dallas, TX, en Londres, Reino Unido o
Hong Kong. Lo cual representa una limitante ya que actualmente el sistema
selecciona automáticamente un datacenter basado en la capacidad y la
proximidad a los servidores de la nube ya existentes, no existiendo la posibilidad

56
 de seleccionar qué centro de datos que desea crear sus servidores de nuevos
Cloud, por lo demás se perfila como una buena opción.

3.3.3 Evaluación general de Amazon Elastic Compute Cloud

Amazon Elastic Compute Cloud (Amazon EC2) es un servicio web que
proporciona capacidad informática con tamaño modificable en la nube, está
diseñado para facilitar a los desarrolladores recursos informáticos escalables y
basados en web.
La sencilla interfaz de servicios web de Amazon EC2 permite obtener y configurar
su capacidad con una fricción mínima y reduce el tiempo necesario para obtener y
arrancar nuevas instancias de servidor en minutos, lo que permite escalar
rápidamente la capacidad, ya sea aumentándola o reduciéndola, según cambien
las necesidades. La instancia evaluada es la “instancia grande” de 7.5 GB de
memoria, 4 unidades de sistemas EC2 (2 núcleos virtuales con 2 unidades de
sistemas EC2 cada uno), 850 GB de almacenamiento de instancias local con una
plataforma de 64 bits. Las regiones disponibles para la creación de los servidores
virtuales son 7 y están ubicados en 3 continentes, América, Europa y Asia (Ver
Gráfico Nº 3.4).
Gráfico Nº 3.4
Zonas de disponibilidad de Amazon Cloud Computing

Fuente: Amazon Cloud Computing

Elaboración: Propia
Es importante mencionar que cada región mostrada en el Gráfico Nº 3.4 tiene a su
vez zonas de disponibilidad, que son infraestructuras diferentes que están
diseñadas para estar aisladas de fallos que se produzcan en otras zonas de
disponibilidad y proporcionan conectividad de red de baja latencia a otras zonas
de disponibilidad de la misma región. Al iniciar instancias en zonas de
disponibilidad distintas, se puede proteger las aplicaciones en caso de error de
una única ubicación. Las regiones están compuestas por una o más zonas de
disponibilidad, están geográficamente dispersas y se encuentran en áreas
geográficas o países diferentes.

57
 Como se puede ver a diferencias de otros proveedores, se puede seleccionar la
región donde se creara la nueva instancia, la parte de administración es muy
parecida a las anteriores y se puede ver en el Gráfico Nº 3.5.
Gráfico Nº 3.5
Panel de Control de Amazon Cloud Computing

Fuente: Centro Internacional de la Papa

Elaboración: Centro Internacional de la Papa
El panel de administración visto en el gráfico anterior o conocida como AWS
Management Console proporciona una interfaz web fácil e intuitiva para Amazon
Web Services, los costos aproximados por la instancia seleccionada son casi
iguales a los ofrecidos por RackSpace Cloud y Cloudbuilder.

3.3.4 Selección del proveedor y capacidad informática en el Cloud Computing

Luego de haber evaluado los diferentes proveedores de Cloud Computing a nivel
de infraestructura se decidió optar por la solución de Amazon Web Services, los
principales motivos se detallan a continuación:
 Un factor importante es que Amazon Web Service es un proveedor con gran
experiencia en el sector, razón de ello existen numerosos casos de éxito.
 Tiene orientación hacia la empresa, ofreciendo acuerdos de nivel de servicio.
 Permite crear instancias en la región que nosotros queremos, así podemos
seleccionar estar en Sao Paulo - Brasil (cercana a la sede principal de Lima) o
podríamos estar en Dublín - Irlanda (cerca de las oficinas regionales de
África).
 Y finalmente, un motivo no tanto técnico sino más estratégico, existen otros
centros de investigación pertenecientes al consorcio CGIAR que ya utilizan
Amazon Web Services y de ser necesario podríamos compartir infraestructura
virtual y de comunicación.
Seleccionado el proveedor del Cloud, la capacidad informática dedicada
seleccionada es la Instancia grande, es la siguiente:
58
  7,5 GB de memoria RAM
 4 unidades informáticas EC2 (2 núcleos virtuales con 2 unidades informáticas
EC2 cada uno)
 850 GB de almacenamiento de instancias
 Plataforma de 64 bits
 Rendimiento de E/S: alto
 Nombre de API: m1.large
Donde una unidad de sistemas EC2 proporciona la capacidad de CPU equivalente
de un procesador Opteron 2007 o Xeon 2007 de 1,0 - 1,2 GHz. También es
equivalente a un procesador Xeon de principios de 2006 de 1,7 GHz.

3.4 FASE CUATRO: CONFIGURACIÓN Y PRUEBA DE LA NUEVA INFRAESTRUCTURA

En esta fase se creara la nueva instancia donde funcionaran los servidores virtuales en
la nube, considerando temas como la seguridad, rendimiento, integridad, etc. también
se debe realizar pruebas de funcionamiento y pruebas de accesos y restricciones, así
como pruebas de alta el servicio colaborativo, es importante además tratar aprovechar
todos los beneficios que nos ofrece la computación en la nube.
Esta fase se ha subdividido en 6 etapas principales.

3.4.1 Creación de las nuevas Instancias

Como primer paso se debe crear una cuenta en Amazon Web Service, esto
permite controlar de forma segura el acceso a servicios y recursos de AWS por
parte de los usuarios, además de poder crear y administrar usuarios en AWS, así
como otorgar acceso a los recursos de AWS a los usuarios gestionados en el
directorio corporativo y fuera de AWS.
Como primer paso se debe tener definido el tipo de instancia a utilizar, el sistema
operativo seleccionado es Ubuntu 11.10 (Oneiric Ocelot), Ubuntu tiene como
ventaja que tiene AMIs oficiales, cada AMI es una plantilla de máquina desde la
que puede crear instancias de servidores nuevos. Cada AMI tiene su propio ID
exclusivo, con el fin de poner en marcha una instancia en la nube EC2, la
instancia seleccionada fue AMI-61b28015, una vez hecho esto se procederá a
seleccionar la región donde se creara el nuevo servidor (Ver Gráfico Nº 3.6).
En el Gráfico 3.6 anterior vemos que se optó por la región de EU West (Irlanda) ya
que como zona más cercana a África deberá de ofrecer una mejor experiencia en
el servicio a los colaboradores de las sedes regionales más lejanas a Lima, por su
parte como la conexión de Lima es buena no debería significar de ninguna
manera una disminución en el servicio desde Lima, o las estaciones
experimentales de San Ramón y Huancayo o de la sede de Quito.
59
 Gráfico Nº 3.6
Selección de la región para creación de servidor virtual en AWS

Fuente: Propia
Elaboración: Propia
En el Gráfico Nº 3.7 se puede ver que se selecciona el AMI antes mencionada,
este AMI se busca en la sección de AMI de la comunidad, también tenemos las
otras opciones de seleccionar Linux básico y los propios AMIs que hubiéramos
creado anteriormente.
Gráfico Nº 3.7
Selección del AMI de la nueva instancia en AWS

Fuente: Propia
Elaboración: Propia
Lo que es importante comprobar en el tipo de instancia es que en Root Device
debe ser EBS, esto significa que dicha unidad de la instancia es permanente es
decir no volátil, así cualquier cambio o configuración que hagamos se mantendrán
almacenados por más que reiniciemos o detengamos la instancia.
Posteriormente se selecciona (ver Gráfico Nº 3.8) el número de instancias a crear
y se selecciona el tipo de instancia, que como se definió es una instancia larga
(Large) y también se selecciona la zona de disponibilidad, en este caso la zona
eu-west-1b.
En el Gráfico Nº 3.8 se puede ver que se escogió como zona eu-west-1b, esto
debido a que mediados del 2011 Amazon en Europa tuvo un problema con el
suministro eléctrico originado tras una tormenta en Dublín, provocando una caída
generalizada de su sistema en la zona 1a y posterior sobrecarga en los sistemas
de almacenamiento, motivo por el cual es recomendable utilizar la zona 2b ya que
no registra ningún problema ni caída durante todo su tiempo de funcionamiento.

60
 Gráfico Nº 3.8
Selección del tipo de instancia y zona de disponibilidad en AWS

Fuente: Propia
Elaboración: Propia
Luego se selecciona el comportamiento cuando la instancia se cierra desde el
interior de la instancia, es muy recomendable que este en la opción por defecto
“Stop”, ya que de estar seleccionado “Terminate” no se podrá detener la instancia
y solamente se podría eliminar la instancia. En el Gráfico Nº 3.9 se ve la opción de
crear y descargar la “Key Pair”, que es la clave pública/privada que permitirá
conectarse de forma segura a la instancia después de que se ponga en marcha.
Gráfico Nº 3.9
Creación y descarga de la clave pública/privada en AWS

Fuente: Propia
Elaboración: Propia
Es importante considerar que cuando se crea y descarga se debe guardar en un
lugar seguro, la clave pública/privada de las instancias no se podrá descargar
nuevamente si se guarda en las configuraciones, si se pierde este archivo no se
podrá acceder al servidor creado. En la opción de Grupo de Seguridad lo dejamos
por defecto ya que se puede hacer cambios a futuro y lo veremos en la siguiente
etapa de configuraciones de seguridad.
Finalmente hacemos clic en Launch (lanzar) para crear e iniciar nuestras
instancias, esto vemos en el Gráfico Nº 3.10.
En el Gráfico Nº 3.10 se ve un resumen de las principales características de las
nuevas instancias creadas, la mayoría de las opciones seleccionadas pueden
posteriormente modificarse, salvo como se mencionó la clave público/privada.

61
 Gráfico Nº 3.10
Creación de las instancias virtuales en AWS

Fuente: Propia
Elaboración: Propia

3.4.2 Configuraciones de seguridad

En la sección de “Security Group” podemos crear un conjunto de reglas de
firewall, es recomendable crear un grupo de seguridad para cada servidor, ya que
se habilita por cada servidor y que cada aplicación utiliza diferentes puertos. En
primer lugar configuraremos las reglas para el servidor de Java-Server-EU donde
se instalara las aplicaciones de Confluence y JIRA, como Confluence y JIRA ya no
se instalara con Apache Tomcat por separado, cada servicio utilizara un puerto
diferentes, así Confluence utilizara el puerto 8080 y JIRA el puerto 8090 pero no
es necesario darle acceso a dichos puerto ya que como se mencionó
anteriormente ambos tendrá salida por Apache.
Gráfico Nº 3.11
Configuración de seguridad de los servidores en AWS

Fuente: Propia
Elaboración: Propia
62
 En el Gráfico Nº 3.11 se ve que para el servidor MySQL-Server-EU se abrieron
los puertos 22 (para el acceso vía SSH), el puerto 443 para acceso HTTPS y el
puerto 3306 para el acceso a MySQL, en el caso del servidor de Java-Server-EU
se habilitaron el puerto 22 (SSH), el puerto 80 (HTTP–Apache), el puerto 443
(HTTPS) y el puerto 993, este último responde para este caso en particular ya que
JIRA necesita acceder vía IMAP para conectarse a una cuenta de correo en
específico. También es importante asignar una IP estática a los servidores para
poder conectarnos de manera más rápida y segura.

3.4.3 Instalación de los principales servicios

Una vez finalizado la etapa anterior se va a ingresar a los servidores en la nube,
en primer momento se va hacer vía SSH mediante PUTTY, PUTTY es un cliente
de Telnet y de SSH libre para la interpolación con OpenSSH desde sistemas
Windows y Linuxs, creado por Simon Tatham de Gran Bretaña es bastante
intuitivo de usar y, además, es libre, el acceso lo haremos mediante un servidor
interno en Linux (ver Gráfico Nº 3.12).
Gráfico Nº 3.12
Acceso al servidor Java-Server-EU

Fuente: Propia
Elaboración: Propia
Como se ve en el Gráfico 3.11 el acceso al servidor vía SSH es simple, se coloca
las palabras ssh –i, luego el nombre del archivo de donde está guardado la clave
pública/privada que anteriormente hemos generado y descargado y finalmente el
IP del servidor donde queremos acceder, de igual forma se accede al servidor
MySQL-Java-EU. Una vez dentro del servidor podemos ejecutar el comando vim
/proc/cpuinfo para ver información del CPU del servidor (ver Gráfico Nº 3.13).
Gráfico Nº 3.13
Características del CPU del servidor

Fuente: Propia
Elaboración: Propia

63
En la parte inferior del Gráfico Nº 3.13 podemos ver información adicional. Esta
información vienen en los servidores Ubuntu 11.10, donde menciona por ejemplo
la memoria total (7.2 GB) y la fecha actual de acceso.
La instalación de programas en Ubuntu se puede hacer mediante la instalación de
paquetes desde repositorios utilizando varias herramientas disponibles en Ubuntu
y Kubuntu. Esta es la forma más rápida, fácil y segura de instalar un programa en
Ubuntu de este modo instalamos aplicaciones comprobadas, estables y sin
problemas de dependencias, simplemente ha de buscarse el programa que se
desea instalar de entre las secciones (departamentos) que nos ofrece o bien usar
el buscador. El buscador se puede usar para buscar bien el nombre del programa
o bien alguna palabra que aparezca en su descripción si queremos buscar un
procesador de textos, por ejemplo, se puede escribir en el buscador la palabra
texto y aparecerán los programas relacionados.
Por ejemplo la instalación de java se puede realizar de la siguiente manera:
sudo add-apt-repository “deb http://archive.canonical.com/ lucid partner”
sudo apt-get update
sudo apt-get install sun-java6-jre sun-java6-jdk sun-java6-plugin sun-java6-fonts
export JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.26
export PATH=$JAVA_HOME/bin:$PATH
Para comprobar si se ha instalado correctamente Java ejecutamos el comando
java –versión (Ver Gráfico Nº 3.14)
Gráfico Nº 3.14
Verificando correcta instalación de Java

Fuente: Propia
Elaboración: Propia
En el gráfico anterior podemos ver que hemos instalado la última versión
disponible de Java, la versión 1.6.0_26, sin embargo para el correcto
funcionamiento de Java deberemos de Configura la variable global JAVA_HOME,
además como se mencionó se debe instalar Apache, la configuración proxy se
verá más adelante.
Para el caso de Confluence y JIRA es necesario descargar sus instaladores
disponibles gratuitamente desde su página web, ejecutando el comando wget
http://www.atlassian.com/software/confluence/downloads/.../confluence-3.5.13-
std.tar.gz por ejemplo se puede descargar el instalador de Confluence, de igual
forma funciona para JIRA, en la página web de Atlassian se encuentra
documentación detallada de como instalar Confluence y JIRA el Linux, es
64
 importante seleccionar la opción de instalador estándar (para evitar la instalación
previa del servidor Tomcat Apache y demás problemas derivados que ya
analizamos).
Para la instalación de MySQL en el servidor MySQL-Server-EU es igual de
sencilla, solo basta ejecutar los siguientes comandos:
sudo apt-get install mysql-server
sudo netstat -tap | grep mysql
sudo /etc/init.d/mysql restart
En el transcurso de la instalación tendremos que responder algunas preguntas e
ingresar la clave de acceso del root de la base de datos, hay que recordar este
clave para poder acceder a la base de datos.
Finalizado esto podemos ejecutar por ejemplo el comando netstat – lntp (Ver
Gráfico Nº 3.15) para comprobar si se tienen funcionando correctamente el motor
de base de datos MySQL.
Gráfico Nº 3.15
Comprobación de funcionamiento del servicio de MySQL

Fuente: Propia
Elaboración: Propia
Cómo se puede ver en el Gráfico Nº 3.15 se tienen 3 procesos que utilizan
diferentes puertos, el proceso que utiliza el puerto 22 es obviamente el proceso de
SSH, y el motor de base de datos MySQL utiliza en puerto 3306. Con lo cual
podemos ver que está correctamente instalado y funcionando.

3.4.4 Acceso al servidor virtual

El protocolo que nos permitirá comunicarnos a nuestro servidor en la nube es
SSH (Secure SHell, en español: intérprete de órdenes segura), este protocolo y el
programa que lo implementa sirve para acceder a máquinas remotas a través de
una red, permite manejar por completo la computadora mediante un intérprete de
comandos, y también puede redirigir el tráfico de X para poder ejecutar programas
gráficos si tenemos un servidor X (en sistemas Unix y Windows) corriendo.
Además de la conexión a otros dispositivos, SSH nos permite copiar datos de
forma segura (tanto ficheros sueltos como simular sesiones FTP cifradas),
gestionar claves RSA para no escribir claves al conectar a los dispositivos y pasar

65
los datos de cualquier otra aplicación por un canal seguro tunelizado mediante
SSH. Como hemos visto en la sección anterior podemos abrir una terminal remota
usando un cliente SSH en Windows, entre los clientes más populares, ligeros y
versátiles para este sistema operativo se encuentran PUTTY, que es un cliente
SSH, Telnet con licencia libre disponible originariamente sólo para Windows,
ahora también está disponible en varias plataformas Unix. En algunas ocasiones,
dado que la librería de encriptación no es del todo eficiente, puede ser un poco
lento, sin embargo PUTTY posee una excelente emulación de la terminal ANSI de
Linux.
Pero PUTTY no es el único medio para acceder a nuestros servidores, otra
aplicación muy conocida es WinSCP que es un cliente SFTP gráfico para
Windows que emplea SSH, WinSCP es una aplicación de Software Libre su
función principal es facilitar la transferencia segura de archivos entre dos sistemas
informáticos, el local y uno remoto que utilizando el protocolos SCP.
Para el acceso vía SSH en nuestros servidores en la nube es importante
configurar el archivo /etc/ssh/sshd_config y hacer el siguiente cambio:
PasswordAuthentication yes

Esto es debido a que en este AMI por defecto sólo permite el acceso utilizando la
clave pública/privada y no mediante el ingreso de usuario y clave, una vez hecho
esto reiniciamos el servicio de SSH.
También es una buena práctica la creación de usuarios con diferentes niveles de
seguridad de acceso al servidor, así debemos crear cuentas que tengan permisos
de administrador y cuentas con permisos básicos, por ejemplo para acceder vía
WinSCP utilizaremos la cuenta admin-riu (Ver Gráfico Nº 3.16).
Gráfico Nº 3.16
Acceso vía WinSCP al servidor Java-Server-EU

Fuente: Propia
Elaboración: Propia

66
 Las aplicaciones WinSCP y PUTTY son complementarias, ya que PUTTY permite
ejecutar comandos por command line y WinSCP sirve para ver de manera gráfico
y para transferir archivos de manera segura vía SCP.

3.4.5 Configuración, acceso y envío de la base de datos

Para esta etapa ya tenemos instalado nuestro motor de base de datos, pero es
necesario hacer algunos cambios en las configuraciones, en aplicaciones como
Confluence y JIRA es común que se adjunten archivos de gran tamaño a las
bases de datos, motivo por el cual el servidor MySQL debe soportar la carga de
archivo pesado, por lo cual es recomendable cambiar la configuración por defecto
de MySQL en el archivo de configuración my.cnf (ubicado en la carpeta de
instalación de MySQL) y reemplazar la siguiente línea de tal manera que
tengamos:
max_allowed_packet = 20M

También es importante crear usuarios en MySQL para las base de datos de

Confluence y JIRA, realizando todo esto nuestro servidor de base de datos actual
se encuentra operativa pero sin ninguna base de datos existente, la idea de
migración o transferencia requiere la transferencia de los archivos de las bases de
datos desde el servidor in-house (origen) al servidor en la nube (destino), la cual
necesita utilizar emplear las mejores prácticas de transferencia de grandes
archivos.
La idea es automatizar el proceso utilizando un script hecho en sh (shell de Linux,
equivalente al archivo bat en Windows) ejecutado periódicamente mediante la
herramienta Cron que sirve para automatizar tareas sobre sistemas Linux/Unix,
este script debe ser capaz de recoger las bases de datos y los archivos de
Confluence y JIRA, la estructura básica del script desarrollado se puede apreciar
en el Gráfico Nº 3.17.
En el gráfico anterior vemos que en caso de las transferencias de los archivos de
MySQL utilizamos mysqldump, que es un comando del sistema gestor de base de
datos MySQL que sirve para hacer copias de seguridad, luego se comprimente en
formato tar.gz que son empaquetados (fichero que contiene ficheros y/o
directorios) y pueden contener cualquier cosa (como backup de datos), luego se
envía los archivos mediante el protocolo SCP llamado también como Secure Copy
que es un medio de transferencia segura de archivos informáticos entre un host
local y otro remoto o entre dos hosts remotos, usando el protocolo Secure Shell
(SSH), luego se comprimen los archivos y finalmente los archivos sql de las bases
de datos se restauran desde la consola de MySQL.

67
 Gráfico Nº 3.17
Etapas del script de transferencia de archivos

Fuente: Propia
Elaboración: Propia
En caso de la base de datos MySQL se va realizar un proceso adicional más
minucioso que es la verificación de la integridad de la base de datos origen y la
base de datos destino, para esto utilizaremos la herramienta MySQL Compare
que sirve para comparar la estructura de las bases de datos, elimina errores de
migración de base de datos cambia generar secuencias de comandos SQL para
actualizar una base de datos para que coincida con el esquema de otro, además
de buscar y corregir errores causados por las diferencias entre bases de datos.
En el Gráfico Nº 3.18 vemos un reporte generado a partir de la comparación de 2
versiones diferentes de la base de datos de Confluence,
Gráfico Nº 3.18
Comparación de estructuras de las bases de datos origen y destino

Fuente: Propia
Elaboración: Propia

68
En el gráfico anterior se muestra que en algunas tablas se encontró diferencias en
la estructura de la base de datos (en este caso específico encontró diferencias en
el número de registros en 9 tablas) lo que supone que no estamos trabajando con
una versión actualizada de la base de datos ya que desde el backup realizado al
momento de comparación se produjeron cambios en los registros, esta
herramienta también funciona para encontrar problemas con el nombre de las
tablas, diferentes tipos de las columnas, etc.
Este reporte con diferencias fue intencionado ya que comprobamos que la
herramienta MySQL Compare hace las comparaciones de manera rigurosa, este
reporte necesita ser analizado por un conocedor de la base de datos ya que
podrían presentar diferencias en tablas donde se guarda información temporal o
cache que obviamente será distinto en la base de datos origen y destino, por lo
cual este paso necesita de una análisis más detallado.
Pero la herramienta MySQL Compare se complementa con la herramienta MySQL
Data Compare, ya que esta última herramienta no compara la estructura, sino
realiza comparaciones a nivel de los datos almacenados en la base de datos,
también generar secuencias de comandos SQL para actualizar una base de datos
con el contenido de otro, proporciona una rápida solución a algunos problemas
mediante la restauración de datos dañados o perdidos en una sola fila, además de
mantener una historia precisa de todos los registros de bases de datos anteriores.
En el Gráfico Nº 3.19 vemos la pantalla de configuración previa a la comparación
de la base de datos origen y la base de datos destino.
Gráfico Nº 3.19
Comparación a nivel de datos de las bases de datos origen y destino

Fuente: Propia
Elaboración: Propia
69
 Como se aprecia en el Gráfico Nº 3.19 MySQL Data Compare y MySQL Compare
soportan conexión directa al servidor y conexiones mediante el protocolo SSH.

3.4.6 Pruebas de funcionamiento

Teniendo restaurado y comprobado la integridad de las bases de datos e instalado
las aplicaciones de Confluence y JIRA, se va probar a realizar test de puesta en
marcha de las aplicaciones colaborativas integradas, para esto es importante
revisar la documentación de Atlassian, básicamente consiste en cambiar la
dirección de las bases de datos que utilizan Confluence y JIRA en sus respectivos
archivos de configuración y también en el mismo archivo de configuración se
debe cambiar la carpeta home de ambas aplicaciones. El proceso de actualización
no debería implicar muchos problemas.
Una vez iniciado las aplicaciones Confluence y JIRA es importante evaluar la
compatibilidad de los plugin que utilizan, ya que ambas aplicaciones utilizan
plugins de Atlassian y de otras Empresas desarrolladoras que sirve para aportar
funciones nuevas y específicas de mejora, estas aplicaciones son ejecutadas por
Confluence y JIRA e interactúan por medio de una API.

3.5 FASE CINCO: MIGRACIÓN DEL ESPACIO COLABORATIVO

En esta fase que debería durar en promedio 1 día, es la fase más crítica ya que se tiene
al tiempo como un factor en contra pues implica que el servicio colaborativo no esté
disponible o esté disponible solo de sólo lectura ya que se va migrar la información
almacenada en el último backup disponible de la base de datos. Esta fase está separada
en 6 fases o tareas principales, las cuales son:

3.5.1 Notificación a los colaboradores

Esta fase si bien es cierto solo implica el envío de un mail a los colaboradores en
general, es muy importante tenerlo en cuenta como una buena práctica, ya que
existen usuarios que acceder a nuestro espacio colaborativo y podrían tener algún
problemas en el acceso o en el mismo servicio y es importante brindar información
a los usuarios para que sepan que se están trabajados de mantenimiento y/o
mejora, es la primera fase dentro del proceso de migración y el envío de este mail
u otra forma de comunicación es el inicio oficial del proceso de migración
propiamente dicho, es recomendable que se inicie fuera del horario de trabajo
teniendo un margen de 1 o 2 horas posteriores a la hora de finalización de la
jornada laboral.
Es importante comunicar en este aviso la hora y fecha de restablecimiento del
servicio, en este caso es preferible considerar un tiempo extra al programado, por

70
 si se presentan problemas no esperados, al finalizar el proceso de migración
también es recomendable el envío de un mail de notificación de la disponibilidad
de los espacios colaborativos.

3.5.2 Ejecución de script de transferencia

Esta fase corresponde a la ejecución del script de generación de backup de la
base de datos de MySQL, comprensión de los archivos de backup y del home de
Confluence y JIRA, luego el envío de los comprimidos, este proceso ya se trabajó
en la fase de preparación o pruebas y es casi automático pero toma varias horas
dependiendo del volumen de información que se está transfiriendo desde el
servidor in-house (origen) al servidor en la nube (destino), dependiendo de la
velocidad de conexión el tiempo de transferencia de cada gigabyte de información
puede varias, para nuestro caso la transferencia desde el servidor con una
conexión de 4Gbps en una hora de poco tráfico demoro en promedio de 15 a 20
minutos transferir 1 gigabyte mediante el protocolo SCP (Secure Copy).

3.5.3 Comprobación de integridad de base de datos

Una vez restauradas las bases de datos de Confluence y JIRA se debe de
proceder a comprobar la integridad de las mismas, para lo cual se va a utilizar las
herramientas MySQL Compare y MySQL Data Compare.

3.5.3.1 A nivel de estructura

La herramienta que utilizaremos es MySQL Compare, que permite el
ahorro de tiempo eliminando errores de migración de base de datos
cuando las bases de datos de prueba pasan a producción, además acelera
el despliegue de nuevas actualizaciones de base de datos de esquema y
genera secuencias de comandos SQL para actualizar una base de datos
para que coincida con el esquema de otro
Como se vio en la fase de preparación y pruebas, con la herramienta
MySQL Compare podremos comparar las estructuras y corregir errores
causados por las diferencias entre bases de datos de 2 servidores
diferentes, en el Gráfico 3.20 se ha comparado la base de datos local de
JIRA con la base de datos en la nube de JIRA.
En el Gráfico 3.20 no se encontró ninguna diferencia en la estructura de las
bases de datos de Confluence, con lo cual podemos afirmar que las tablas
y columnas de ambas bases de datos son idénticas, de igual manera se
realizó con las bases de datos de JIRA encontrándose de igual manera
idénticas la base de datos origen y de destino.

71
 Gráfico Nº 3.20
Comprobación de integridad de estructura de BDs de Confluence

Fuente: Propia
Elaboración: Propia
3.5.3.2 A nivel de datos
Para esta comprobación utilizaremos la herramienta MySQL Data
Compare que permite comparar todo el contenido de todas las tablas de 2
bases de datos ubicados en servidores diferentes, para esto el programa
MySQL Data Compare utiliza las llaves primarias o las columnas índices
para comparar 2 tablas, de no encontrar ninguno de los 2 no las compara
hasta que se defina la columna de referencia, en el Gráfico Nº 3.21 se
observa la comparación de datos de las bases de datos de JIRA en ambos
servidores. El tiempo de demora de comparación a nivel de datos de 2
bases de datos depende del número de tablas, columnas y registros
existentes, ya que se tratan de 2 bases de datos de regular tamaño, podría
implicar varios minutos en el análisis, por ejemplo para las bases de datos
de Confluence que tiene en promedio 7000 registro en cada una de sus 58
tablas y un peso promedio de 422.5 MB demoro en promedio 60 minutos
en comparar todos los registros existentes y en el caso de JIRA demoró 15
minutos en comparar sus tablas 118 con 700 registros teniendo en
promedio un volumen de 10.5 MB.
En el Gráfico Nº 3.21 se ve que no existen diferencias en ninguna tabla, lo
cual comprueba que contamos con una base de datos idéntica al original y
que desde el momento del ultimo backup no se realizaron ningún cambio,
de existir diferencias en alguna tabla se necesita una evaluación de qué
tipo de información se tiene almacenada, ya que de ser información cache
o temporal podría omitirse la diferencia, al comprobar las bases de datos
72
 de Confluence comprobamos de igual manera que no existe diferencia
entre las bases de datos de ambos servidores.
Gráfico Nº 3.21
Comprobación de integridad de datos de BDs de JIRA

Fuente: Propia
Elaboración: Propia

3.5.4 Configuración de Confluence y JIRA

3.5.4.1 Configuraciones Generales
El proceso de configuración de Confluence y JIRA son parecidos por lo
cual las principales configuración que se mencionan son para ambos casos
de manera, el directorio de inicio que en Confluence y JIRA que están
definidos por defecto los reemplazaremos por otros, donde hemos
descomprimidos los archivos migrados desde el servidor in-house, se debe
especificar la ruta absoluta en vez de un enlace simbólico para especificar
la ruta y el nombre del archivo.
Confluence y JIRA vienen por defecto configurados para utilizar el puerto
8000, por lo cual es recomendable reemplazarlos, por lo cual para
estandarizar con lo que recomienda Atlassian, para Confluence
utilizaremos en puerto 8090 y para el caso de JIRA el puerto 8080, para
verificar la disponibilidad de estos puertos se puede utilizar el comando
netstat, que sirve para identificar los puertos libres en el equipo.
Para la configuración de la base de datos debemos que cambiar el archivo
de configuración en Confluence para que acceda a la base de datos
confluencedb, también debemos ingresar un nombre de usuario y
contraseña con acceso a la base de datos de modo de lectura y escritura

73
 (es una buena práctica crear un usuario específico para Confluence y dar
acceso solo sobre la base de datos confluencedb), de igual manera
debemos de cambiar el archivo de configuración de JIRA y conectar a la
base de datos JIRAdb, utilizando un usuario especial con permisos solo a
JIRAdb de lectura y escritura.

3.5.4.2 Configuraciones de certificado de seguridad SSL

Los certificados de seguridad son una medida de confianza adicional para
las personas que visitan y hacen transacciones en su página web, le
permite cifrar los datos entre el ordenador del cliente y el servidor que
representa a la página. El significado más preciso de un certificado de
seguridad es que con él logramos que los datos personales sean
encriptados y así imposibilitar que sean interceptados por otro usuario.
Ahora es muy común ver en nuestros exploradores el protocolo de
seguridad HTTPS (ver Gráfico Nº 3.22) mediante éste, básicamente nos
dice que la información que se envía a través de internet, entre el
navegador del cliente y el servidor donde está alojada la página, se
encripta de forma que es casi imposible que otra persona reciba, vea o
modifique los datos confidenciales del cliente.
Gráfico Nº 3.22
Certificado de seguridad otorgado por GoDaddy

Fuente: Propia
Elaboración: Propia

En el Gráfico 3.21 vemos por ejemplo el certificado otorgado por la

Empresa certificadora GoDaddy, al cual autentifica que se está navegando
en una página de cgiar.org. Para habilitar en las aplicaciones colaborativas
se necesitan copiar los archivos del certificado de seguridad que estaban
en el anterior servidor de producción y configurar en el Apache del servidor
en la nube, también se debe realizar algunos cambios tanto en Confluence
y JIRA, ya debemos agregar las siguientes líneas:
scheme="https"
proxyName="research.cip.cgiar.org"
proxyPort="443"

74
3.5.4.3 Configuración proxy Apache
Como se mencionó, el servidor Java-Server-EU es el que tendrá salida a
internet a través del subdominio research.cip.cgiar.org pero también hará
el rol de servidor Proxy, un reverse proxy es un servidor proxy instalado
para que todo el tráfico entrante de Internet pueda desviar a otro destino
de uno de esos servidores web que pasa a través del servidor proxy. Hay
varias razones para instalar un “reverse proxy” como son por seguridad ya
el servidor proxy es una capa adicional de defensa y por lo tanto protege
los servidores web, también por el cifrado/aceleración SSL ya que como se
vio en la etapa anterior cuando se crea un sitio web seguro, habitualmente
el cifrado SSL es realizado por el “reverse proxy”, el cual está equipado
con un hardware de aceleración SSL (Security Sockets Layer), también
ayuda en la distribución de carga debido a que el “reverse proxy” puede
distribuir la carga entre varios servidores web. En ese caso, el “reverse
proxy” puede necesitar reescribir las URL de cada página web (traducción
de la URL externa a la URL interna correspondiente, según en qué servidor
se encuentre la información solicitada).
Para poder utilizar el propio servidor web Apache como Proxy inverso,
debemos tener compilados una serie de módulos. Los módulos básicos
necesarios para este fin son los siguientes: mod_proxy, mod_proxy_http,
mod_proxy_ftp, mod_proxy_connect, mod_proxy_html, mod_xml2enc y
mod_headers. En el caso particular de Confluence y JIRA utilizamos para
dar salida a estas aplicaciones Java a través de Apache evitando de esta
manera que estén ingresando los puertos reales por los cuales funcionan,
la configuración que se debe hacer en Confluence es la siguiente:
SSLProxyEngine on
ProxyRequests Off
ProxyPreserveHost On

<Proxy *>
Order deny,allow
Allow from all
</Proxy>

ProxyPass /confluence http://localhost:8090/confluence

ProxyPassReverse /confluence http://localhost:8090/confluence
<Location /confluence>
Order allow,deny
Allow from all
</Location>

Para el caso de JIRA de igual forma debemos de realizar cambios en el

Apache.

75
 SSLProxyEngine on
ProxyRequests Off
ProxyPreserveHost On

<Proxy *>
Order deny,allow
Allow from all
</Proxy>

ProxyPass /JIRA http://localhost:8080/JIRA

ProxyPassReverse /JIRA http://localhost:8080/JIRA
<Location /JIRA>
Order allow,deny
Allow from all
</Location>

3.5.5 Inicializar los servicios colaborativos

Una vez completado los pasos anteriores ya estamos en condiciones de iniciar los
servicios de Confluence y Jira, ya que ambas aplicaciones se instalan como
proceso solo debemos utilizar los siguientes comandos:
service confluence start
service jira start

Utilizando el comando netstat –lntp podemos ver los puertos y procesos utilizados
por el servidor (ver Gráfico Nº 3.23)
Gráfico Nº 3.23
Procesos y puerto utilizados por el servidor

Fuente: Propia
Elaboración: Propia

Como se puede observar en el Gráfico anterior se utilizados los puertos 80 (puerto

utilizado por Apache), el puerto 22 (utilizado por SSH), el puerto 25 (utilizado para
envío de mail), los puertos 443 y 8443 (HTTPS/SSL usado para la transferencia
segura de páginas web) y finalmente el puerto 8080 de JIRA y el puerto 8090 de
76
Confluence, con lo cual vimos que se inicializaron correctamente las aplicaciones.
En el Gráfico Nº 3.24 vemos la página inicial de Confluence.
Gráfico Nº 3.24
Página inicial de Confluence

Fuente: Propia
Elaboración: Propia

En el Gráfico anterior vemos la página inicial de Confluence donde vemos además

el certificado de seguridad configurado y las últimas actualizaciones realizadas, en
el Gráfico Nº 2.25 vemos de igual manera la página inicial de JIRA.
Gráfico Nº 3.25
Página inicial de JIRA

Fuente: Propia
Elaboración: Propia

Aquí vemos la página inicial de JIRA, también configurado con el certificado de

seguridad, para acceder a ambos colaborativos debemos de utilizar la cuenta de
administrador, ya que falta configurar el acceso vía LDAP.

77
3.5.5.1 Actualización de plugin
Como se mencionó en la etapa de pruebas, Confluence y Jira utilizan
plugin que agregan funcionalidades específicas y es importante que dichos
pligins desarrollados por Atlassian y otras Empresas sean compatibles con
las nuevas versiones, en el Gráfico Nº 3.26 se hace la comprobación de
actualización de los plugins de JIRA.
Gráfico Nº 3.26
Comprobación de actualización de plugin en JIRA

Fuente: Propia
Elaboración: Propia

Como se ve en el Gráfico Nº 3.26 vemos que JIRA ha comprobado

correctamente la actualización de todos los plugin que utiliza, de igual
manera en Confluence se debe de comprobar que estemos trabajando con
las últimas versiones disponibles compatibles con las versiones de
Confluence y JIRA.

3.5.5.2 Configura la autentificación vía LDAP

LDAP son las siglas de Lightweight Directory Access Protocol (en español
Protocolo Ligero de Acceso a Directorios) que hacen referencia a un
protocolo a nivel de aplicación el cual permite el acceso a un servicio de
directorio ordenado y distribuido para buscar diversa información en un
entorno de red, LDAP también es considerado una base de datos (aunque
su sistema de almacenamiento puede ser diferente) a la que pueden
realizarse consultas.
Un directorio es un conjunto de objetos con atributos organizados en una
manera lógica y jerárquica, el ejemplo más común es el directorio
telefónico, que consiste en una serie de nombres (personas u
organizaciones) que están ordenados alfabéticamente, con cada nombre
teniendo una dirección y un número de teléfono adjuntos.

78
 Almacena la información de autenticación (usuario y contraseña) y es
utilizado para autenticarse aunque es posible almacenar otra información
(datos de contacto del usuario, ubicación de diversos recursos de la red,
permisos, certificados, etc). A manera de síntesis, LDAP es un protocolo de
acceso unificado a un conjunto de información sobre una red. Esto
permitirá que todos los colaboradores del CIP puedan ingresar utilizando
sus usuarios y password.
Gráfico Nº 3.27
Configuración de LDAP en Confluence

Fuente: Propia
Elaboración: Propia

En la gráfica anterior vemos la configuración del LDAP, Active Directory es

el nombre utilizado por Microsoft (desde Windows 2000) como almacén
centralizado de información de uno de sus dominios de administración.

3.5.5.3 Configuraciones finales

Finalmente por la naturaleza de Confluence y JIRA, es necesaria la
configuración de algunos servicios, como por ejemplo el envío de correos,
ya que esto sirve para notificación de tareas, actualizaciones en los
espacios de preferencia, notificación de asignación de alertas, etc. En el
Gráfico Nº 3.28 vemos la configuración para envío de mail en Confluence.
En el Gráfico Nº 3.28 vemos que la configuración y prueba de envío de
mail, esto se realiza mediante en protocolo SMTP o Simple Mail Transfer
Protocol (es español, Protocolo Simple de Transferencia de Correo), es un
protocolo de la capa de aplicación. Protocolo de red basado en textos
utilizados para el intercambio de mensajes de correo electrónico entre
computadoras u otros dispositivos.

79
 Gráfico Nº 3.28
Configuración y prueba de envío de mail

Fuente: Propia
Elaboración: Propia

3.5.5.4 Reindexamiento del contenido

El indexamiento tiene como propósito ejecutar la elaboración de un índice
que contenga de forma ordenada la información, esto con la finalidad de
obtener resultados de forma sustancialmente más rápida y relevante al
momento de realizar una búsqueda, es por ello que la indexación es un
elemento fundamental de elementos como los motores de búsqueda y las
bases de datos de esta forma, cuando se realiza una consulta, el motor de
búsqueda se dirige al índice para localizar los elementos deseados,
arrojando así resultados precisos y rápidos. Sin un índice, el motor de
búsqueda debería escanear el contenido de cada página web de forma
individual cada vez que se iniciara una búsqueda, lo cual, considerando el
volumen de la información existente en los espacios colaborativos, seria
excesivamente lento y demandaría equipos informáticos muy potentes.
En una base de datos, un índice es una estructura de datos mejora la
velocidad de las operaciones en las tablas de la misma. Los índices
pueden ser creados utilizando una o más columnas de la base de datos,
proporcionando las bases para un acceso rápido a los registros.
En el Gráfico Nº 3.29 vemos la indexación de Confluence y Jira
respectivamente.

80
 Gráfico Nº 3.29
Re-indexamiento en Confluence y Jira

Fuente: Propia
Elaboración: Propia

3.5.6 Comprobación de la migración

Finalizada la migración de los espacios colaborativos integrados a la nube,
teniendo como nuestro proveedor a Amazon Elastic Compute vamos a verificar
nuestro proveedor y la ubicación de nuestro servidor virtual, para esto existe la
aplicación web conocida como Whoishostingthis que nos permite conocer el
hosting de los sitios web (ver Gráfico Nº 3.30).
Gráfico Nº 3.30
Detección de nuestro proveedor en la nube

Fuente: Whoishostingthis
Elaboración: Propia

81
En el gráfico Nº 3.31 vemos que nuestro hosting sale DUB6 EC, lo que significa
que nuestro hosting es Amazon Elastic Compute Cloud (Amazon EC2) en la
región 6 (Irlanda), para verificar esto último utilizamos otra herramienta web
conocido como Getdomaininfo (ver Gráfico Nº 3.31).
Gráfico Nº 3.31
Ubicación de nuestro servidor virtual

Fuente: Getdomaininfo
Elaboración: Propia

En el último gráfico vemos que ha detectado el IP público del servidor virtual y a

partir de ello mediante consultas de geo-referenciación se pudo determinar la
ubicación exacta de nuestra aplicación colaborativa.
En el Gráfico Nº 3.32 se muestra las 4 instancias creadas y funcionando en la
consola de administración de Amazon, como se mencionó anteriormente los
servidores Java Server EU y MySQL Server EU son los necesarios para el
funcionamiento del espacio colaborativo integrado y las desarrolladas en la
presente investigación, las otras 2 instancias son las que completan los otros
servicios a la investigación en el CIP.
Gráfico Nº 3.32
Instancias de los servidores virtuales

Fuente: Amazon Web Service

Elaboración: Propia

82
En esta fase mostraremos la nueva infraestructura de los nuevos servidores
virtuales en la nube, como se mencionó el capítulos anteriores antes se tenía 4
servidores virtuales dentro del servidor físico de investigación del CIP, ahora estos
4 servidores (2 de los 4 sirven para el funcionamiento del espacio colaborativo
integrado) están en la nube, la estructura se ha mantenido, esto se puede ver en
el Gráfico Nº 3.33.
Gráfico Nº 3.33
Nueva infraestructura de los servidores en la nube

Fuente: centro Internacional de la Papa

Elaboración: Propia
En el Gráfico 3.33 vemos la nueva infraestructura de los servidores y los IP
públicos asignados, también se muestra gráficamente el funcionamiento de la
configuración del servidor Java en la nube que hace de servidor Proxy para las
aplicaciones Java y de PHP, el servidor MySQL como se menciono es un servidor
dedicado donde están todas las bases de datos de todas las aplicaciones,
incluidas la de datamart. Todos los servidores son instancia Large ya que es
suficiente para los fines (7,5 GB de memoria, 4 unidades de sistemas EC2 y 850
GB de almacenamiento volátil), el almacenamiento permanente no volátil depende
de cada instancia, en caso del servidor Java-Server-EU se tiene 100GB para
almacenar y de MySQL se tiene 30 GB de almacenamiento, este espacio es
fácilmente de redimensionar si en algún momento fuera necesario, proceso que
en un ambiente basado en la nube solo tomaría pocos minutos. De la
infraestructura original de 6 servidores virtuales, se tenía uno destinado al
monitoreo, lo cual no es necesario ya que Amazon Web Service tiene el servicio
de Amazon CloudWatch que proporciona la supervisión de los recursos de la nube

83
 de AWS y de las aplicaciones que los clientes ejecutan en AWS, de igual manera
el servidor de Backup es reemplazado por el servicio Amazon Simple Storage
Service que sirve para almacenar y recuperar la cantidad de datos que se desee,
cuando desee y desde cualquier parte maximizando las ventajas del escalado.

3.6 FASE SEIS: SOPORTE Y MONITOREO

Esta fase consiste en monitorear y gestionar los sistemas de manera efectiva para lograr
un rendimiento más eficiente del espacio colaborativo integrado, siendo necesario la
visibilidad del ambiente operativo y habilitando una planificación efectiva. Además, se
debe proporcionar una respuesta expeditiva ante inconvenientes de funcionamiento y
ayuda a los procesos que garantizan la estabilidad de los servidores y de los sistemas y
base de datos que en ella corren.
La etapa de soporte es un trabajo donde se proporcionan asistencia con las aplicaciones
colaborativas integradas, en general esta etapa consiste en tratan de ayudar a los
colaboradores a resolver determinados problemas con las aplicaciones colaborativas, el
nivel de soporte será de estar en contacto directo con el usuario y dar soluciones a las
incidencias de manera constante, no es una etapa de un plazo determinado sino más
bien es el inicio de esta etapa retroalimentadora, como en la migración se evitó realizar
mayores cambios visuales no deberían presentarse muchas incidencias de problemas ya
que se asume que el colaborador frecuentes ya está acostumbrado con la interfaz y
manejo, pero el hecho de migrar a la nube supone también la mejora del servicio y por
ente al ingreso de nuevos colaboradores de las regiones más alejadas que no están
familiarizados con estas aplicaciones colaborativas integradas, que es hacia los cuales
se enfocara el soporte.
La etapa de monitoreo es el proceso de recoger la información rutinariamente sobre
todos los aspectos de rendimiento de las aplicaciones colaborativas, para lo cual es
necesario contar con un plan de monitoreo, que es una herramienta de administración
básica y vital que información esencial para el diseño, implementación, administración, y
evaluación para acciones preventivas o correctivas, esta etapa también es constante y
permanente. En la presente investigación los resultados de esta etapa se mostrara,
compararan y discutirán en el Capítulo IV de Análisis y Discusión de Resultados, donde
se ve información de rendimiento y performance de las aplicaciones colaborativas en el
nuevo servidor en la nube.

3.7 FASE SIETE: DOCUMENTACIÓN

Esta fase es una fase de constante actualización, que se inicia desde el diagnóstico y va
hasta el soporte y monitoreo, se pone como fase final ya que es al final donde se puede
agrupar, ordenar y clasificar la documentación generada en cada fase, su importancia

84
 radica en que esto ayuda a otra persona entender el proceso de migración entendiendo
el propósito, configuraciones, evaluaciones y demás, esta fase nos servirá como
retroalimentación para futuros proyectos.
En la medida posible se debe tratar de utilizar un mismo formato para la documentación,
que deberá contener como mínimo la información sobre el nombre de la servidor/
aplicación evaluada, el propósito específico de la documentación, la persona que realiza
la documentación, el escenario y/o supuesto en la cual se basa la documentación y
finamente las especificaciones técnicas y/o de análisis realizadas.

En este capítulo se desarrolló la metodología propuesta por el autor para la migración de las
aplicaciones colaborativas integradas a la nube, debe entenderse que para cada caso
particular se puede otorgar a cada fase de la metodología el esfuerzo que se considere
necesario dependiendo del grado de automatización de los procesos estratégicos de cada
Organización, de la plataforma tecnológica y de la infraestructura existente, también es
flexible para que cada Organización pueda efectuar reajustes o realizar procesos con mayor
nivel de detalle dependiendo de la complejidad de su plataforma tecnológica y de los
recursos que se asignen.

85
 CAPITULO IV
ANALISIS y DISCUSIÓN DE RESULTADOS

Luego de haber realizado la investigación, se presentan a continuación el análisis y

discusión de los resultados, que consiste en explicar los resultados obtenidos y comparar
éstos con datos obtenidos previamente, es una evaluación critica de los resultados tomando
en consideración la situación inicial y final de las variables utilizadas en la metodología de la
investigación, el orden de los mismos está en dependencia lógica del modelo. En primer
lugar se aborda diferentes análisis de rendimiento de la migración de las aplicaciones
colaborativas integradas y posteriormente el servicio del espacio colaborativo integrado.

4.1 Análisis de resultados

El análisis de resultados parte de evaluaciones realizadas utilizando diferentes fuentes
de información como son los diferentes logs de los servidores, reportes de las
aplicaciones y también la información recogida a partir de cuestionarios.

4.1.1 Análisis del rendimiento del servidor de Java en la nube

El analisis de la evaluación del rendimiento del servidor Java en la nube toma
como información la proporcionada por Amazon CloudWatch que mantiene la
supervisión de los recursos de la nube de AWS y de las aplicaciones que los
clientes ejecutan, sirve para recopilar métricas y realizar su seguimiento, como se
menciono en capitulos anteriores el uso de la capacidad actual existente es de
una instancia Large para el servidor de Java lo que significa que se tiene un
procesador doble nucleo de Intel(R) Xeon(R) CPU E5507 de 2.27GHz, en el
Gráfico Nº 4.1 vemos el consumo máximo de CPU por minuto, donde en las
ultimas 2 semanas de mayor actividad registra en promedio un consumo de hasta
un máximo de 80% del CPU en horas picos de demanda, teniendo sin embargo
en general valor máximo de consumo de memoria menor del 60% en horas de alta
demanda, es importante mencionar que con la infraestructura anterior in-house
esto hubiera significado una considerable ralentización del servicio o en algunos

86
casos una caida momentanea del servidor integrado ya que se tenia una
capacidad de procesamiento menor a la actual.
Gráfico Nº 4.1
Monitoreo del consumo máximo de CPU

Fuente: Centro Internacional de la Papa

Elaboración: Propia
En el Gráfico Nº 4.2 se muestra el consumo promedio del CPU por minuto,
teniendo como máximo un valor del 54%, teniendo como promedio global un
consumo del 20% del CPU total disponible, esto refleja que en gran parte del
tiempo se tiene un consumo bajo de procesamiento pero que es necesario su
disponibilidad ya que en horas picos de demanda del servicio colaborativo
funciona sin problemas y no llega a colapsar por problemas de procesamiento.
Gráfico Nº 4.2
Monitoreo del consumo promedio de CPU

Fuente: Centro Internacional de la Papa

Elaboración: Propia

87
Ya que CloudWatch tiene informacion histórica de tan sólo las 2 ultimas semanas,
utilizaremos la herramienta JavaMelody, que es un monitoror Java de servidores o
aplicaciones Java en entornos de control de calidad y producción, a través de esta
herramienta podemos ver el uso del CPU en porcentajes durante los últimos 2
meses, viendo efectivamente que se puede alcanzar picos de hasta 76.3% de uso
de CPU pero también se registra mínimos de menos del 1% de consumo del
procesador, también se puede apreciar en la linea de tiempo que no existen cortes
o interrupciones del servicio.
Gráfico Nº 4.3
Consumo porcentual de CPU con JavaMelody

Fuente: Centro Internacional de la Papa

Elaboración: Propia
Para el análisis de uso de memoria RAM también utilizaremos la herramienta
JavaMelody ya que no se trata de una herramienta para simular solicitudes de los
usuarios, es una herramienta para medir y calcular las estadísticas sobre el
funcionamiento real de la aplicación en función del uso de la aplicación por los
usuarios, como se menciono anteriormente se tiene 7.5GB RAM disponibles, para
su buena perfomance se tiene asignado casi 2GB de memoria dedicado para
Confluence y para el caso de JIRA es poco menos de 2GB de memoria dedicada,
en la Figura Nº 4.4 podemos ver el uso máximo porcentual de memoria RAM en el
servidor Java en la nube.
Como se puede ver en la Gráfica Nº 4.4 la memoria RAM utilizada es casi la
totalidad de las 7.5 GB de RAM, estamos acostumbrados a la idea de que
“memoria usada” se refiere a memoria que ya se usó, por ende no podemos
usarla en el futuro, en Linux “memoria usada” significa memoria tomada por el
sistema, de forma que pueda ser empleada por usuarios y aplicaciones, este
resultado puede parecer aparentemente engañoso ya que hace suponer que se
esta utilizando el máximo de memoria disponible, pero en realidad refleja que se

88
tiene asignado casi toda la memoria actual del servidor, existiendo muy poca
memoria RAM no utilizada u ociosa.
Gráfico Nº 4.4
Consumo utilizada de memoria RAM del servidor con JavaMelody

Fuente: Centro Internacional de la Papa

Elaboración: Propia
En el caso del uso de la memoria RAM tenemos un indicador de memoria
disponible a utilizar más no un indicador de memoria realmente utilizada, motivo
por el cual evaluaremos para Confluence y JIRA el uso de real de memoria RAM
en ambos casos específicos, para este paso utilizaremos el plugin de JavaMelody
que como se mencionó calcula las estadísticas sobre el funcionamiento real de
una aplicación, en el Gráfico Nº 4.5 vemos el uso de memoria de Confluence en la
nube, donde muestra toda la información histórica recogida por este plugin.
Gráfico Nº 4.5
Consumo real de memoria RAM de Confluence con JavaMelody

Fuente: Centro Internacional de la Papa

Elaboración: Propia
En el Gráfico Nº 4.5 vemos que el historial de consumo de memoria RAM de
Confluence es de 1GB, llegando por momento a estar cerca del 1.5GB de
89
consumo de memoria, se tiene asignado casi 2GB existiendo un margen cuando a
futuro se requiera usar más capacidad por parte de Confluence.
Dentro de las opciones administrativas de Confluence hay una sección donde
brinda información del uso de memoria memorial, pero no información histórica
sino sólo información actual del uso de memoria (ver Gráfico Nº 4.6).
Gráfico Nº 4.6
Consumo de memoria RAM actual de Confluence

Fuente: Centro Internacional de la Papa

Elaboración: Propia
Como se puede ver en el gráfico anterior, el uso de memoria real asignado es de
exactamente 1822 MB, dedicado exclusivamente para el funcionamiento de
Confluence, teniendo un 25% libre, este porcentaje representa la memoria libre en
el momento actual pudiendo cambiar cuando exista cambios en el volumen de
transacciones y accesos por los usuarios.
Para el caso de JIRA de igual manera vamos a evaluar en un primer momento
utilizando el plugin JavaMelody, los resultados se muestran en la Gráfica Nº 4.7.
Gráfico Nº 4.7
Consumo de memoria RAM de JIRA con JavaMelody

Fuente: Centro Internacional de la Papa

Elaboración: Propia
Como se puede ver se tiene asignado casi 1 GB de memoria pero se utiliza
efectivamente casi 600MB de memoria.

90
 En el Gráfico 4.8 vemos la información brindara por JIRA del uso de memoria
RAM.
Gráfico Nº 4.8
Consumo de memoria RAM actual de JIRA

Fuente: Centro Internacional de la Papa

Elaboración: Propia
Como se aprecia en el gráfico anterior de los 1365 MB de memoria RAM asignada
a JIRA es utilizada un 60%, para el caso de Confluence y JIRA en el servidor
anterior tenían una asignación de memoria casi igual, pero la ventaja de la
computación en la nube es que de existir cambios considerables en el
requerimiento (necesidad de aumento de memoria RAM) se puede reasignar la
memoria del servidor en cuestión de minutos.

4.1.2 Análisis del rendimiento del servidor de MySQL en la nube

La experiencia previa del uso de procesamiento y memoria RAM en servidores
dedicados de sistemas de administración de base de datos nos muestra que la
mejor manera de evaluar ambos indicadores es a través del comportamiento del
motor de base de datos, para lo cual pondremos especial énfasis en la
performance obtenida por MySQL, para lo cual utilizaremos el módulo
mod_log_sql desarrollada por Chris Powell, que es un módulo de Apache que
registra todos los hits en una base de datos MySQL, a partir de lo cual obtuvimos
que el tráfico del servidor desde el inicio registra la información vista en la Tabla
Nº 4.1.
Tabla Nº 4.1
Estadísticas de tráfico en la red del servidor MySQL

Fuente: Centro Internacional de la Papa

Elaboración: Propia

91
 La tabla anterior muestran las estadísticas de tráfico en la red de este servidor
MySQL desde su inicio, habiéndose registrado un máximo de 152 conexiones
concurrentes y un 3.75% de intentos fallidos que son debido a que intento ingresar
un usuario y password incorrectos (por ejemplo al intentar acceder vía
phpMyAdmin) o puede ser resultado de un número simultáneo de conexiones
superior a las permitidas, mientras que las conexiones abortadas son las
peticiones enviadas al servidor y luego canceladas.
En la parte de consultas vemos que el servidor desde el inicio ha recibido
295’775,636 consultas en total, en la Tabla 4.2 se puede ver el número de
consultas y los principales tipo de consultas de la gran actividad del servidor
durante los casi 100 días de funcionamiento ininterrumpido.
Tabla Nº 4.2
Estadísticas de consultas del servidor MySQL

Fuente: Centro Internacional de la Papa

Elaboración: Propia
Del total de consultas un 40% son del tipo “set option” lo cual sirve para inicializar
o asignar distintos tipos de variables de usuario o de sistema, el tipo de consulta
“select” es para recuperar filas seleccionadas a partir de una o más tablas, la
consulta “commit” compromete la transacción actual por lo que sus cambios serán
permanentes, “rollback” deshace la transacción actual y realiza la cancelación.
La capacidad del anterior servidor in-house es casi a la par del servidor en la
nube, sin embargo en la nube durante 3 meses de funcionamiento sólo se han
registrado 68 consultas que han tomado más segundos que 10s (Slow_queries),
mientras que en el servidor anterior durante casi 5 años registra en total 39’500
consultas que han tomado más de 10 segundos, lo cual significa que el nivel de
procesamiento del nuevo servidor de la base de datos es significativamente mejor
al obtenido en el servidor anterior.

4.1.3 Análisis del rendimiento del espacio colaborativo integrado

El rendimiento del espacio colaborativo integrado en la nube es determinado por
la performance en conjunto de los servidores, servicios y motor de base de datos,
92
para lo cual se utilizó las herramientas web WebPagetest, Pingdom y Page Speed
Online, éstas herramientas en conjunto analizan globalmente el contenido,
velocidad, calidad técnica de construcción de un sitio web.
Para el caso de la evaluación con la herramienta web Pingdom se repitió el mismo
ejercicio que se hizo en la parte de problemática, simulando conexiones de
usuarios ubicado en Ámsterdam – Países Bajos (como la más cerca a África) y
testeando la página principal de nuestra sitio colaborativo, la página principal de
Google como uno de los sitios más veloces e optimizados, el Portal de
conocimiento de Camote (SKP) y finalmente la página web del CIP (Ver Tabla Nº
4.3).
Tabla Nº 4.3
Comparación de ‘grados’ y tiempos de descarga desde Ámsterdam
Tiempo
Sitio Grado
(segundos)
Portal Principal del CIP 65 6.50s
Portal de Conocimientos de Camote (SKP) 76 3.27s
Espacio Colaborativo (Confluence) 81 1.40s
Espacio Colaborativo (JIRA) 80 941ms
Google 88 410ms
Fuente: Herramienta online “Pingdom”
Elaboración: Propia

El sitio colaborativo de Confluence paso de tomar un tiempo de carga total de 60

segundos (evaluación realizada en el servidor in-house) a 1.40 segundos después
de la migración hacia la nube y JIRA registro un tiempo de carga de 941ms, el
acceso desde Ámsterdam es notablemente más rápido teniendo una mejora en
casi 40 veces y ahora es más rápido que el portal principal del CIP y que el Portal
de conocimiento de Camote. En el Gráfico Nº 4.9 vemos el resumen de la
evaluación del espacio colaborativo Confluence del CIP.
Gráfico Nº 4.9
Resumen de evaluación de Confluence desde Ámsterdam

Fuente: Herramienta online “Pingdom”

Elaboración: Propia
93
Como se observa en el gráfico anterior Confluence carga 521 KB en 1.40
segundos, la página principal de Google pera 224 KB motivo por el cual carga
más rápido que Confluence, aunque por calidad de diseño Google supera
ampliamente con un 88% sobre 81% de Confluence, hay que tener en cuenta que
la página de Google es un referente en mejores prácticas de desarrollo web a
nivel mundial. En el caso de JIRA (ver Gráfico Nº 4.10) vemos el resumen de
carga de la página.
Gráfico Nº 4.10
Resumen de evaluación de JIRA desde Ámsterdam

Fuente: Herramienta online “Pingdom”

Elaboración: Propia
La página inicial de JIRA carga menor contenido que Confluence y toma 941ms
en la carga completa, siendo más rápido que el 90% de sitios a nivel mundial y
Confluence está ubicado entre los 81% de sitios más rápidos de todo el orbe. Este
ejercicio sirvió para ver la mejora del rendimiento del espacio colaborativo antes y
después de la migración hacia la nube y la mejora en el rendimiento en
comparación a otros sitios relacionados.
Las evaluaciones realizadas con la herramienta web WebPagetest servirán para
evaluar el tiempo de carga, velocidad de acceso, velocidad de respuesta, además
de otros parámetros con los que conocer del rendimiento del sitio colaborativo
integrado. Lamentablemente esta herramienta ya no dispone la simulación de
conexiones desde ningún punto de África, por ello se utilizó Israel como lugar más
cercano a África y para el caso de las conexiones desde Lima se reemplazó por
conexiones simulada desde Buenos Aires, las conexiones se realizaron utilizando
el navegador Internet Explorer 8 para poder homogenizar la evaluación en todas
las regiones de disponibilidad, en la Tabla Nº 4.4 vemos los resultados de la
evaluación desde varios países.
Como se puede ver en la Tabla Nº 4.4 se realizó evaluaciones desde 4
continentes, tomando como referentes ciudades relativamente más significativas,
los resultados varían de acuerdo a las velocidades de conexiones reales de
conexión doméstica y la distancia física hacia el servidor, la evaluación considero

94
el tiempo de carga (y recarga desde archivos desde la cache del navegador), y el
tiempo de respuesta (tiempo de envío del primer byte) y la reconexión de la
misma.
Tabla Nº 4.4
Evaluación tiempo de carga y respuesta desde varios países
Tiempo de carga Tiempo de respuesta
Localidad Servicio (primera vista / (primera vista /
repetición) repetición)
New York, Confluence 7.439s / 3.956s 2.184s / 2.004s
EEUU JIRA 6.439s / 2.387s 1.793s / 1.766s

Buenos Aires, Confluence 9.837s / 3.673s 2.620s / 2.235s

Argentina JIRA 7.919s / 2.624s 2.158s / 2.168s

Londres, Reino Confluence 5.382s / 2.802s 1.069s / 0.901s

Unido JIRA 4.274s / 2.342s 0.822s / 0.977s

Jerusalén, Confluence 9.848s / 3.331s 4.887s / 1.444s

Israel JIRA 6.796s / 2.294s 1.485s / 1.375s

Shanghái, Confluence 10.621s / 3.588s 2.580s / 2.595s

China JIRA 11.109s / 5.141s 5.141s / 2.513s

Sidney, Confluence 10.110s / 4.548s 2.857s / 2.866s

Australia JIRA 9.946s / 3.454s 3.042s / 2.798s
Fuente: Herramienta online “WebPagetest”
Elaboración: Propia

Como se mencionó anteriormente los servidores virtuales en la nube se ubican

físicamente en Irlanda, motivo por el cual no debe extrañar que las conexiones
más rápidas sean desde Londres con un tiempo promedio de 5 segundos para la
carga completa de Confluence y JIRA y una repetición de tan sólo 2.5 segundos y
siendo el tiempo de primera respuesta de tan sólo 1 segundo. Las conexiones
realizadas desde New York son las que sigue en la lista de velocidad más rápido,
luego están prácticamente igualadas las conexiones desde Buenos Aires y
Jerusalén (zonas más cercanas a la sede principal de Lima y las oficinas
regionales del África subsahariano) con un tiempo de menos de 10 segundos
para el caso de Confluence y menos de 8 segundos en el caso de JIRA para la
carga completa del sitio, y en ambos casos menos de 4 segundos la recarga de la
página completa, lo cual es significativamente menor a los resultados
anteriormente obtenidos con los servidores in-house que eran por encima del
minuto de tiempo de carga.
Como zonas de conexiones relativamente más lentas figura la conexión desde
Shanghái y Sídney que para el caso de Confluence en ligeramente mayor a los 10

95
 segundos y en el caso de China se muestra un caso atípico ya que figura JIRA
relativamente más lento que Confluence.
La evaluación de Page Speed fue principalmente para verificar la calidad técnica
de construcción y configuración de los sitios colaborativos integrados, en la
Gráfica Nº 4.11 vemos los resultados de Confluence y JIRA en la página de
ShowSlow que es una herramienta de código abierto y además un servicio online
para obtener información estadística en lo que a rendimiento se refiere.
Gráfico Nº 4.11
Rendimiento de páginas de Confluence y JIRA
Confluence

JIRA

Fuente: Herramienta online “Page Speed” y “ShowSlow”

Elaboración: Propia

La puntuación de Page Speed indica cuánto más rápido es una página, una
puntuación alta indica poco margen de mejora, mientras que un puntaje más bajo
indica mayor margen de mejora. La puntuación de Page Speed no mide el tiempo
necesario para que una página se cargue sino la calidad técnica de desarrollo y
configuración, la cual en el caso de JIRA es mejor que Confluence estando en la
categoría A mientras que Confluence está en la categoría B, existiendo hasta la
categoría F, esto es principalmente porque tenemos instalado la última versión de
JIRA 5.0 en cambio en Confluence debemos esperar algunos plugin para utilizar a
la última versión 4.1 disponible, pero sin embargo ambas calificaciones son
bastantes buenas.

4.1.4 Análisis de los resultados de la actividad del espacio colaborativo

Para el análisis del resultado de tráfico se utilizó la herramienta WebLog Expert
que es un software que analiza de forma rápida y precisa los ficheros log
generados por el servidor Web Apache, generando un completo informe en

96
formato HTML, con datos sobre los visitantes de un sitio web, estadísticas de
actividad, secciones más visitadas, ficheros más descargados y otros.
Para esta evaluación se necesitó los logs de acceso del servidor Apache, los
cuales se dispone del servidor anterior in-house lo cual sirvió para contrastar y
comparar la información del tráfico al espacio colaborativo. Para el caso del
servidor in-house se dispone de información histórica del último año, en caso del
servidor en la nube tenemos información de los 3 meses de evaluación.
En el último año de funcionamiento el servidor in-house registró 209,608 visitas en
total siendo 175,572 visitas hechas por usuarios reales (no robots o analizadores
web) realizados por 48,796 visitantes (Ver Tabla Nº 4.5).
Tabla Nº 4.5
Informe de actividad de servidor in-house (anterior)

Fuente: Centro Internacional de la Papa

Elaboración: Propia
En la tabla anterior vemos que un visitante regresaba en promedio entre 3 y 4
veces luego de la primera visita llegando a visitar en promedio 2.66 páginas en
total, otro indicador importante es que en promedio por día se tenía 133 visitantes.
En el Gráfico Nº 4.12 vemos el Gráfico de visitantes diarios donde se puede ver
picos de hasta 228 visitantes diarios, y valores mínimos de cero visitantes.
Gráfico Nº 4.12
Visitantes diarios al servidor Java in-house

Fuente: Centro Internacional de la Papa

Elaboración: Propia
En el Gráfico Nº 4.13 vemos la evolución de visitantes por mes, durante los
últimos 12 meses de funcionamiento del servidor in-house vemos una notable

97
disminución de la actividad pasando de tener visitas mensuales entre 4000 y 5000
a visitas mensuales de 3000 y 4000, vale decir que en los últimos 9 meses se
registraron menos de 1000 visitantes mensuales comparados a los registrados a
inicios del periodo evaluado.
Gráfico Nº 4.13
Visitantes mensuales al servidor Java in-house

Fuente: Centro Internacional de la Papa

Elaboración: Propia
La información analizada del servidor Java en la nube es de 3 meses de
rendimiento, en la Tabla Nº 4.6 vemos que el número de visitas en total es de
216,065 siendo 136,559 visitas hechas por visitantes reales esto significa que en
tan sólo 3 meses se logró superar el número de visitas que lo registrado durante
todo el último año de funcionamiento del servidor in-house, sin embargo el número
de visitantes es de 16,341 (más de la tercera parte de los 48,796 visitantes en el
servidor in-house), otra mejora importante es el promedio de páginas visitadas se
cuadruplico, pasando de 2.66 a 10.62, el promedio de visitantes por día paso de
133 a 179 y el promedio de visitas por visitante es ahora de 13.22, esto último
muestra que se ha cuadruplicado el número de retornos a nuestro espacio
colaborativo, ya que antes un visitantes regresaba 3 veces luego de su primera
visita, ahora retorna 12 veces.
Tabla Nº 4.6
Informe de actividad de servidor en la nube

Fuente: Centro Internacional de la Papa

Elaboración: Propia

98
El número de visitantes diarios puede verse en el Gráfico Nº 4.14, registrándose
un pico de 432 visitantes diarios, fecha que se comunicó oficialmente el fin del
proceso de migración hacia la nube, registrándose un mínimo de 111 visitas al
día, estos valores se han mantenido más o menos estables llegando a tener 179
visitas diarias en promedio.
Gráfico Nº 4.14
Visitantes diarios al servidor Java en la nube

Fuente: Centro Internacional de la Papa

Elaboración: Propia
En el Gráfico Nº 4.15 se puede ver las visitantes durante los 3 meses de
funcionamiento, estos valores son en líneas generales estables, pasando de una
alza de accesos por la novedad de tener el servidor en la nube del primer mes a
ya niveles de desempeño promedios, en el último mes se tuvo 6330 visitas (más
que el máximo nivel registrado en el último año de funcionamiento del servidor in-
house).
Gráfico Nº 4.15
Visitantes mensuales al servidor Java en la nube

Fuente: Centro Internacional de la Papa

Elaboración: Propia

Como se pueden apreciar en las comparaciones entre la actividad del servidor in-
house y el servidor en la nube, existe una mejora en cuanto el número de accesos
y actividad, en el Gráfico Nº 4.16 se aprecia la curva de rendimiento de los últimos
15 meses, siendo los últimos 3 los meses de funcionamiento del espacio

99
colaborativo en el servidor en la nube, como se puede ver en el gráfico la
tendencia de visitas, páginas visitadas y visitantes es positiva, después de la
migración el segundo mes hubo una tendencia decreciente llegando a 32,650
visitas, sin embargo este valor es aun superior al mayor valor registrado cuando
se utilizaba el servidor de in-house donde se alcanzó 30,386 visitas.
Gráfico Nº 4.16
Visitas y visitantes mensuales totales al espacio colaborativo

Fuente: Centro Internacional de la Papa

Elaboración: Propia

La evolución del número de visitantes se puede apreciar en mayor detalle en el

Gráfico Nº 4.17, donde se muestra el número de visitantes, después de la
migración a la nube se tuvo como mínimo valor 4,967 visitantes que es casi los
mismos resultados máximos visitantes que se registraban en el servidor in-house.
Gráfico Nº 4.17
Visitantes mensuales al espacio colaborativo

Fuente: Centro Internacional de la Papa

Elaboración: Propia
100
 Como se vio la actividad ha aumentado en los meses post-migración, es
importante el incremento del número de visitantes, visitas y páginas visitadas,
pero un indicador más importante aún es la tasa de retorno que como se
mencionó prácticamente se cuadruplico pasando de 3.30 a 12.22.

4.1.5 Análisis de los resultados de los accesos del espacio colaborativo

Para en análisis de acceso al espacio colaborativo también se utilizó el análisis del
log de acceso de Apache, el análisis de realizo por algunos espacios colaborativos
principales para ver el nivel de desempeño.
Una vez evaluado cuantitativamente el número de accesos es importante ver
información sobre los visitantes, como principal factor a tener en cuenta es el
origen de donde se realizan los accesos a los servidores colaborativos, en el
Gráfico Nº 4.18 vemos la distribución en el mapa del acceso a los servidores antes
de la migración.
Gráfico Nº 4.18
Visitantes por país de origen al servidor Java in-house

Fuente: Centro Internacional de la Papa

Elaboración: Propia
En la Figura Nº 4.17 el mapa muestra los mayores porcentajes de accesos de los
usuarios, cuanto mayor es el número de accesos, mayor es la tonalidad azul que
tiene el país, así se registraron mayores conexiones desde Estados Unidos,
China, Perú y Canadá representando en conjunto el 58% del total de las
conexiones durante el último año en el servidor in-house, se tiene registrado
accesos desde 168 diferentes países, en 59 países existe menos de un acceso
mensual y en 21 países se registró solo un acceso durante todo el año.

101
De las conexiones desde África, Egipto es él tiene mayor número de accesos con
615 (1.26% del total), seguido de Kenia con 167 conexiones (0.34% del total),
Argelia con 145 conexiones (0.30% del total) y Túnez con 139 conexiones (0.28%
del total). A nivel de ciudades Lima es la ciudad que registra mayor número de
conexiones con 4,288 visitantes (ver tabla Nº 4.7)
Tabla Nº 4.7
Principales ciudades de conexión al servidor Java in-house

Fuente: Centro Internacional de la Papa

Elaboración: Propia
Como se puede apreciar en la Tabla Nº 4.7 Lima es la ciudad que tiene mayor
número de visitas y visitantes, en esta lista el primer país africano es Cairo con
296 visitantes mientras que Nairobi tiene 92 conexiones.
De igual manera se evaluó los accesos al servidor en la nube, durante 3 meses
para ver cuál es la tendencia de las conexione, en el Gráfico 4.19 se tiene el mapa
de accesos.
Gráfico Nº 4.19
Visitantes por país de origen al servidor Java en la nube

Fuente: Centro Internacional de la Papa

Elaboración: Propia

102
En el mapa las tonalidades más azules representan un mayor porcentaje de
visitantes de los diferentes países, de igual manera que antes de la migración está
encabezado por Estados unidos, China, Perú y Canadá haciendo en conjunto
64% del total de conexiones, Egipto es el país africano con mayor número de
conexiones con 149 visitantes (0.91% del total), Kenia tiene 55 visitas (0.34% del
total), Argelia tiene 42 visitantes (0.26% del total) en total son 145 que registran
visitantes durante los 3 meses de funcionamiento con 27 países con menos de
una conexión por mes y 18 países con una sola conexión.
Para la evaluación por regiones se ha consolidado la información de visitas y
visitantes por continente (Ver tabla Nº 4.8) donde se tiene información diaria del
servidor anterior in-house (durante el último año de funcionamiento), información
del servidor actual en la nube (de los 3 meses de funcionamiento) y se agregó
información del número de visitas estimado, que es un valor estimado obtenido del
valor proporcional para el hipotético escenario de funcionamiento para los
próximos 3 meses de funcionamiento del servidor in-house, considerando un valor
adicional de incremento del número de visitantes y de visitas del 10%.
Tabla Nº 4.8
Número de visitas y visitantes por continente

Fuente: Centro Internacional de la Papa

Elaboración: Propia

103
 En la tabla Nº 4.8 se puede ver el número de visitas totales en el servidor en la
nube es cuatro veces a lo estimado de haber seguido utilizando el servidor in-
house, el número de visitas mensuales es casi de 1000 más que al estimado. El
número de visitas y visitantes por continentes se han mantenido casi en la misma
proporción, en el caso de visitas desde África la proporción ha disminuido pero
muestra aumento en 10 el número de visitantes promedio mensual con casi 100
visitas, adicionalmente antes de la migración un visitante desde África visitaba en
promedio 2.67 veces y ahora visita más de 3.05 veces.
En líneas generales se ha mantenido la proporción de visitas por continentes en el
caso de América, Europa, Asia y África se ha registrado aumentos en el número
de visitas y visitantes al estimado, siendo en el caso de América la que presento
un mayor incremento en el número de visitas y visitantes, Oceanía es el
continente que tiene hasta el momento un número de visitas y visitantes menor al
esperado, pero sin embargo no es significativa la diferencia.

4.1.6 Análisis de los resultados de la satisfacción de los usuarios

El análisis de satisfacción de los usuarios parte de una encuesta realizada luego
de tres meses de funcionamiento del servidor en la nube, se muestra información
sintetizada en preguntas que se consideran clave para tener un panorama amplio
sobre la percepción y nivel de satisfacción de los usuarios del espacio
colaborativo integrado. En el Gráfico 4.20 se ve los resultados de percepción de
rapidez del servicio integrado.
Gráfico Nº 4.20
Percepción de velocidad del espacio colaborativo

Fuente: Centro Internacional de la Papa

Elaboración: Propia

La percepción de que se cuenta con un servicio rápido y muy rápido es del 65%,
una cuarta parte considera como normal y un 10% considera como lento, nadie
104
respondió que el servicio sea muy lento. Para la calificación de lento es importante
ver que otros factores externos hacen que se considere lento el servicio, ya que
como se vio en evaluaciones de velocidad no debería demorar más de 15
segundos en acceder al espacio colaborativo desde cualquier parte del mundo,
claro esto en condiciones normales de conexión a internet.
Luego de estudios posteriores se determinó que este porcentaje se presenta en
colabores desde África y partes de Asia, los colaboradores de África cuentan con
una conexión a Internet muy lento lo que hace que el servicio en general lento, ya
que el servidor debe conectarse a otros servicios, como por ejemplo para la
autentificación mediante LDAP se debe conectar a servidores del proveedor
CGNET que está ubicado en Estados Unidos. Los colabores de determinadas
zonas de Asia que cuentan con una buena conexión a internet mencionan que el
servicio es normal debido a que sus respuestas están en base a sus experiencias
con servicios de páginas hospedadas en el mismo continente y donde las
velocidades de conexiones son muy rápidas.
Sobre el nivel de percepción de mejora o deterioro del servicio en los últimos 3
meses, se ha visto que existe una clara percepción de mejora, los usuarios de
África, Europa y Asia en ese orden son los que perciben una mejora del servicio,
los usuarios de África ya que como se vio en evaluaciones anteriores presentan
un conexión casi 40 veces más rápida, para los usuarios de Europa la conexión es
también muy rápida ya que el servidor físicamente se encuentra en este
continente, para Asia también mejora el nivel de velocidad y para los usuarios de
América y de Lima mencionan que experimentan una ligera mejora.
En el Gráfico Nº 4.21 vemos la apreciación general de los colaboradores sobre el
servicio colaborativo integrado, para un amplio 85% se encuentra satisfecho y
muy satisfecho, un 10% manifiesta que el servicio le parece bueno o normal y un
5% se manifestó poco satisfecho.
Gráfico Nº 4.21
Satisfacción del servicio del espacio colaborativo

Fuente: Centro Internacional de la Papa

Elaboración: Propia
105
 Para entender mejor se hizo preguntas sobre los temas que recomiendan mejorar,
donde se menciona desde capacitación del uso, difusión de la importancia del
espacio colaborativo y otros que se deberían considerar posteriormente, en suma
la migración trajo mejoras significativas de navegación y performance pero para
mejorar aún más se necesita realizar una eficiente gestión del sitio, difusión y
apoyo corporativo.

4.2 Prueba de hipótesis

Para poder realizar las pruebas de hipótesis, se considerará las variables utilizadas en la
presente investigación, partiendo de los indicadores medidos en el capítulo de
problemática, cuando se tenía el servicio colaborativo integrado en el servidor in-house,
estos valores son comparados con los valores medidos luego de la migración a la nube,
para poder evaluar y validar la hipótesis planteada (ver tabla Nº 4.9).
Tabla Nº 4.9
Comparación de variables antes y después de la migración
ANTES DE LA DESPUES DE LA
VARIABLE INDICADOR
MIGRACIÓN MIGRACIÓN
Percepción de servicio Percepción de servicio
lento - muy lento: lento - muy lento:
1.Nivel de percepción de
45% 10%
mejora.
Percepción de servicio Percepción de servicio
rápido - muy rápido: rápido - muy rápido:
35% 65%
Migración de las 2.Tasa de retorno de los
aplicaciones 3.5 veces 12 veces
visitantes
colaborativas 3.Número de páginas
2.66 10.62
visitadas por visitante
4.Uso de memoria RAM 1 GB / 4GB 2 GB / 7.5GB

5.Slow queries (consulta

660 mensuales 10 mensuales
a la BD mayor a 10s.)
Nivel satisfacción alto Nivel satisfacción alto y
y muy alto: muy alto:
1.Nivel de satisfacción 40% 85%
de los usuarios Nivel de insatisfacción: Nivel de insatisfacción:
25% 5%

Servicio del 2.Visitantes diarios 133 179

espacio
colaborativo de 3.Número de visitas
17467 72022
investigación mensuales
4.Visitantes locales
2216 3066
(América)-mensuales
5.Visitantes otros
1850 2381
continentes-mensuales
6.Tiempo de carga del
60s. – 100s. 1s. – 10s.
espacio colaborativo
Fuente: Centro Internacional de la Papa
Elaboración: Propia

106
 Esta información como se mencionó se obtuvieron desde las encuestas realizadas y los
archivos de registro de actividad (log del sistema y de acceso), en la Tabla Nº 4.9 se
puede ver las variables e indicadores con los valores medidos antes y después de la
migración, las cifras mostradas muestran mejoras en ambas variables, todos los
indicadores medidos registran mejora, algunos variables presentan mejorar abrumadoras
en los tres meses de funcionamiento, como la reducción en 66 veces el número de
consultas que demoran más de 10 segundos en procesarse (slow queries), o que se
haya quintuplicado el número de visitas mensuales, o que el tiempo de carga se haya
reducido en algunos casos en más de 20 veces, otros indicadores reflejan ligera mejora,
pero constante y permanente como en el caso del número de visitantes, donde se tiene
un incremento de 46 nuevos visitantes por mes, dicho esto se puede afirmar que la
hipótesis planteada es verdadera, para un mayor entendimiento se realizar la discusión
de resultados en la siguiente sección.

4.3 Discusión de resultados

4.3.1 Rendimiento del servidor de Java en la nube
El uso de CPU del servidor en la nube es fluctuante, pudiendo pasar a consumo
de menos del 10% a valores cercanos del 80%, esto depende en gran medida del
número de usuarios concurrentes y las transacciones que procesa, en tanto la
memoria RAM también tiene fluctuaciones utilizando en promedio hasta un 75%
de las memorias dedicadas para Confluence y JIRA. Las últimas versiones de los
servidores de aplicaciones y entornos de ejecución Java suelen estar mejor
optimizados para el rendimiento llegando a tener un 20% de aceleración.
Dentro de la planificación de hardware del servidor para la implementación del
espacio colaborativo integrado se estimó la escalabilidad del servidor basado en
los visitantes de pico, transacciones y el contenido total, el actual servidor cumple
estos requisitos y muestra de ellos es que durante los meses de funcionamiento
no se registró ningún problema debido a la ralentización o caída del servicio
debido al uso del CPU o memoria, mencionado esto se puede afirmar que el
rendimiento en el actual servidor en la nube supera al servidor in-house
actualmente y tiene la misma tendencia de comportamiento en el mediano y largo
plazo por los beneficios intrínsecos de la computación en la nube.

4.3.2 Rendimiento del servidor de MySQL en la nube

El número de procesamiento del servidor en la nube se ha incrementado
significativamente en comparación del servidor in-house, el número de consultas
que han tomado más de 10 segundos ha disminuido pasando de 39,500 en 5
años (650 por mes) a 68 consultas en 3 meses (23 por mes) lo cual muestra que

107
 la capacidad de procesamiento del nuevo servidor en la nube ha mejorado, si a
esto agregamos que el procesamiento ha sido mayor las mejores son mayores,
esto se explica que el CPU y la memoria RAM son muchos mayores a la del
servidor in-house ya que paso de tener 4GB a 7.5GB de memoria dedicada.
La latencia de base de datos actual de la base de datos es de pocos
milisegundos, la latencia es el tiempo de envío de una petición trivial para la base
de datos, consultando una tabla que se sabe que tiene sólo una columna y fila
uno, esto garantiza que no existen problemas de baja velocidad entre servidores,
base de datos lenta, connection pool (agrupamiento de conexiones) u otros.
De igual manera que el servidor Java en la nube el rendimiento del servidor
MySQL en la nube obtiene los beneficios de la computación en la nube, alcanzar
el nivel de rendimiento al actual hubiera significado una importante inversión de
dinero, pero gracias a la migración a la nube es posible de obtener.

4.3.3 Rendimiento del espacio colaborativo integrado

El rendimiento del espacio colaborativo es determinado por la performance en
conjunto de los servidores, servicios y motor de base de datos, Confluence paso
de tomar un tiempo de carga de 60 segundos a 1.40 segundos para conexiones
de test desde Países Bajos representando una disminución de 43 veces menos,
mientras tanto que JIRA registro un tiempo de carga de 941 ms.
En las evaluaciones de diferentes continentes se tiene como valores máximos de
carga de 10 segundos para el caso de Confluence y 11 segundos para el caso de
JIRA, y como tiempo de respuesta máximo de 5 segundos para ambos servicios,
esto a nivel de velocidad significa un alto rendimiento en todas las pruebas de
conexión que se realizó, no en vano los espacios colaborativos de Confluence y
JIRA del Centro Internacional de la Papa están entre los 19% y 10% sitios más
rápidos a nivel mundial según la prestigiosa herramienta web Page Speed Online
desarrollado por Google. El nivel de construcción de JIRA y Confluence es de
igual de óptima, ya que obtuvieron calificaciones de A y B respectivamente, la
calidad técnica de ambos espacios colaborativos son altos, por lo cual se puede
afirmar que el rendimiento del espacio colaborativo integrado es del más alto nivel.

4.3.4 Evaluación de la actividad del espacio colaborativo

El número de visitas en el último año de funcionamiento del servidor in-house fue
de 175,572 visitas de usuarios reales, mientras que en el servidor en la nube se
registró 136,559 en tan solo 3 meses, valor que supera ampliamente a lo estimado
inicialmente, de igual manera se pasó de tener 48,796 visitantes anuales (4066

108
 visitantes mensuales) a registrar 16,341 visitantes trimestrales (5447 visitantes
mensuales) representando un incremento en un 33% del número de visitantes.
Este incremento significa que en la práctica cada día ingresan 46 personas que
antes no ingresaban al espacio colaborativo, el número de páginas visitadas son
también mayores y el número de actividad de Confluence y JIRA es mucho mayor
antes de la migración. Sin embargo hay un indicador que se considera más
importante que es la tasa de retorno por visitante, antes un visitaba regresaba en
promedio 3 veces luego de su primera visita, ahora regresa 12 veces luego de la
primera visita, lo cual nos da un claro indicio que la experiencia del servicio
colaborativo integrado es mucho mejor, lo que hace que los visitantes hayan
cuadruplicado su número de retornos al espacio colaborativo, el tiempo de
permanencia en el sitio de igual manera ha tenido un incremento considerable.

4.3.5 Evaluación de los accesos al espacio colaborativo

El porcentaje de accesos por país no se ha visto alterado, siendo los que registran
mayores accesos los países de Estados unidos, China, Perú y Canadá pasando
de representar de un 58% (en el servidor in-house) a un 64% (en la nube) del total
de visitantes. Numéricamente hablando el número de visitas mensuales es casi de
1000 más que al estimado, el número de visitas y visitantes por continentes se
han mantenido casi en la misma proporción, en el caso de visitas desde África la
proporción ha disminuido pero muestra aumento en 10 el número de visitantes
con casi 100 visitas mensuales, adicionalmente antes de la migración un visitante
desde África visitaba en promedio 2.67 veces y ahora visita más de 3.05 veces.
Las visitas desde todo el continente americano es que ha registrado un mayor
incremento registrando un aumento de un 25.74% del número de visitantes
comparado a las estimaciones realizadas, Asia registra un incremento del 24.06%,
Europa tiene 10.89% de aumento y África registra hasta el momento un aumento
del 6.32% del número de visitantes y un 21.63% del número de visitantes, en
general los accesos desde otros continentes se incrementó en un 44% al valor
estimado.
El nivel retorno de los usuarios desde el África también ha aumentado, esto
muestra que si bien la performance y rendimiento del espacio colaborativo es
notablemente mejor desde África esto no se está reflejando en igual magnitud en
el número de conexiones desde este continente, existe 2 motivos para esto, uno
es que 3 meses es aún poco tiempo para poder evaluar el verdadero impacto para
la mejora de las conexiones desde este continente y segundo que no se está
difundiendo completamente las mejoras realizadas, estas medidas debería ayudar
a conseguir resultados muchísimos más ambiciosos a los actuales.

109
 4.3.6 Resultados de la satisfacción de los usuarios
El análisis de satisfacción de los usuarios en general tiene grandes mejoras, la
percepción de que se cuenta con un servicio que no es del más óptimo es de tan
sólo el 10%, esto debido principalmente a factores externos de conectividad ya
que la conexión a los servidores toma algunos minutos. La percepción de mejora
se parecía también en todas las regiones, sin embargo son los usuarios que
tenían antes una lenta conexión los que perciben en mayor magnitud la mejora de
conexión al servicio de colaboración integrado, mientras que los usuarios desde la
sede central de Lima perciben poca variación en la conexión.
Se aprecia que la migración hacia la nube es la piedra angular de desarrollo del espacio
colaborativo integrado, que trajo consigo resultados inmediatos de los beneficios intrínsecos
de la computación en la nube, también trajo beneficios por el proceso de implementación en
los primeros 3 meses de funcionamiento siendo en algunos casos plenamente identificados
por los colaboradores, pero que para hacer extensa los beneficios de la misma se necesita
desarrollar metodología de integración de todos los colaboradores para poder pasar de un
nivel de beneficio de utilidad a un nivel de beneficio de innovación del modelo de negocio.

110
 CONCLUSIONES

1. Se ha demostrado que los beneficios de la migración del espacio colaborativo integrado a

un ambiente virtual basado en la nube es real y los resultados se reflejan a los pocos
meses después de la migración, se ha conseguido reducir el tiempo de carga a menos de
12 segundos desde cualquier parte del mundo con velocidades normales de conexión y
se ha logrado duplicar la percepción de satisfacción del servicio, llegando a un 85% de
usuarios satisfechos y altamente satisfechos con el espacio colaborativo integrado.
2. Se ha identificado la rápida adaptación y dinamismo del espacio colaborativo integrado,
ya que una vez percibido cierto grado de mejora del servicio, se ha cambiado los
patrones de comportamiento obteniéndose mayor actividad de los colaboradores,
logrando un aumento de hasta cinco veces el número de visitas diarias y registrándose
un 34% de incremento en el número de visitantes, generando el incremento del contenido
colectivo del mismo, búsqueda en el historial y propiciando la interacción dinámica entre
los mismos, convirtiéndose el espacio en un gran recolector de conocimiento.
3. El modelo aplicativo propuesto por el autor ha sido exitoso para la presente investigación,
ya que se redujo en lo posible el tiempo total del proceso de migración y el tiempo de
paralización del servicio colaborativo, sin embargo se trata de un metodología flexible,
que puede ser adaptada para cada realidad dependiendo de la complejidad de su
plataforma tecnológica, de la infraestructura existente y de los recursos asignados para
cada organización.
4. Se ha demostrado la validez de las diferentes pruebas o testing de rendimiento realizadas
antes de la migración, éstos constituyen en conjunto una gran herramienta para la
evaluación durante el periodo de prueba de las aplicaciones online colaborativas y de
cualquier otra índole, gracias a estas evaluaciones del tiempo carga, del tiempo de
respuesta y del grado de construcción técnica de las aplicaciones se ha logrado superar a
más del 86% de páginas web en general a nivel mundial.
5. Como se menciona la computación en la nube en una tecnología reciente, encontrándose
en la etapa inicial de desarrollo, lo que genera que el proceso de migración hacia la nube
sea percibido como una amenaza latente por las áreas de administración física de los
servidores frente a los proveedores externos, y constituye una primera barrera a vencer
ya que existe el riego latente de la mala gestión de la privacidad de la información.

111
 RECOMENDACIONES

1. La migración del espacio colaborativo integrado constituye una fase inicial y fundamental
de mejora del servicio integrado, sin embargo es importante que esto esté acompañado
por políticas institucionales que favorezcan el espíritu colaborativo a fin de poder mejorar
la comunicación y la capacidad de colaboración, aprovechando de una manera más
eficiente los recursos escalables y el potencial de colaboración existente en la nube, para
mejorar el despliegue de recursos humanos, hardware, software y la energía de la
Organización.
2. Es recomendable continuar la medición de la actividad, los accesos y nivel de percepción
del espacio colaborativo integrado, para entender la real dimensión del impacto en
mediano y largo plazo, esto para poder identificar y anticiparse si se presentan caídas en
la tendencia de la actividad del espacio colaborativo, ya que esto aseguraría que se
mantenga el gran nivel de percepción de mejora y favorecería la colaboración entre los
usuarios de todas las regiones.
3. Antes de implementarse soluciones tecnológicas utilizando ambientes virtuales basados
en la nube, es recomendable hacer un análisis particular, ya que por sí misma no es una
solución para todos los problemas ni para todas las realidades, ya que el nivel de
dependencia con el proveedor del Cloud Computing hace que la necesidad de pasar a
ambientes basados en la nube sean recomendable para proyectos que tengan entre
mediado y largo plazo, también se recomiendo estudiar detenidamente los costos ya que
para cada caso particular no siempre resulta ser la propuesta más económica y viable.
4. Se sugiere que la metodología propuesta por el autor en la presente investigación sea
estudiada y evaluada antes de su utilización, ya que por su naturaleza podría no ser
necesariamente la que mejor se ajuste a otros proyectos de migración ya que se generó
a partir de un caso en particular y podría no ser tan efectiva cuando se trate de utilizar en
Organizaciones y en contextos diferentes a las descritas en la presente investigación.
5. En futuras investigaciones se recomienda siempre utilizar bibliografía reciente sobre
ambientes virtuales en la nube, ya que por ser una tecnología en fase actual de
desarrollo, algunas características y limitaciones descritas en la presente investigación
podrían quedar poco válidas, ya que como se mencionó el dinamismo de la Empresas
líderes que ofrecen servicios de computación en la nube hace que se mejore la propuesta
tecnología, interoperabilidad, políticas de seguridad en muy corto tiempo.

112
 REFERENCIAS

REFERENCIAS BIBLIOGRÁFICAS:
1. Aguilera, Guillermo. El cómputo en la nube. 2010 feb, Issue 560: 28-28.
2. Areitio, Javier. Protección del Cloud Computing en seguridad y privacidad. Universidad
de Deusto. España. 2010 mayo.
3. Ávila, Oscar. Computación en la nube. Universidad Autónoma de Madrid. España. 2011.
4. Dean, David y Saleh, Tamim. Captar el verdadero valor del “Cloud Computing”. The
Boston Consulting Group. 2010 marzo.
5. European Climate Action Commissioner Connie Hedegaard. Greening IT. How Greener
IT can form a solid foundation for low-carbon society. 2009.
6. Faha, Jabbar y Ramírez, Raúl. Herramientas Web 2.0 para el Aprendizaje Colaborativo.
Ciencia y Tecnología para el desarrollo. 2009.
7. Fernández, Froilán. Del “cómputo en la nube” a la Empresa 2.0. Revista Debates IESA.
2009 ene-mar; Vol. 14, Issue 1: 70-75.
8. Fernández, Froilán. Un salto a la nube: La computación en los cielos virtuales. Revista
Debates IESA. 2010 ene-mar; Vol. 15, Issue 1: 42-45.
9. Fernando, Luis. Virtualización de redes como elemento clave para Cloud Computing.
Instituto Tecnológico de Costa Rica. 2009.
10. Fundación de la Innovación Bankinter. Cloud Computing: La tercera ola de las
Tecnologías de la Información. España. 2010.
11. Instituto Nacional de Estadística e Informática. Guía para la migración de software libre
en las Entidades Públicas. Colección metodología informática.2002.
12. López, Jorge, Lee, Francisco y Torricella, Raúl. Aplicación de la computación en nube
en la gestión de la Biblioteca Virtual de la EcuRed ver. 2.0. Ciencias de la Información.
2011 sep.-dic.; Vol. 42, No.3.
13. Parrino, Marcelo. Análisis de Rendimiento para soluciones de Cloud Computing.
Universidad de Palermo. Argentina. 2009.
14. Rodríguez, Marlís. Uso didáctico de los wikis: Un estudio de su estado actual.
Universidad de Sevilla. España. 2008.
15. Ruiz, Francisco. Conocimiento en la nube: características socio comunicativas del Cloud
Computing. Universidad de Málaga. 2010 oct.
16. Sun Microsystems Inc. Take your business to a higher level: Sun cloud-computing
technology scales your infraestructure to take advantage of new business opportunities.
2009.
17. Verizon. Estudio Informativo. Cloud Computing: ¿Exageraciones publicitarias o buena
estrategia comercial?. Estados Unidos. 2010.

113
REFERENCIAS ELECTRÓNICAS:
1. Juan Manuel Fernández. Informe de tecnologías emergentes 2012 (2012). Mercados &
tendencias.
Disponible en:
http://www.revistamyt.com/myt/informes/3443-informe-de-tecnologias-emergentes-
elusuario-manda?format=pdf
Accesado el: [01 Marzo 2012]
2. IBM Smart Business. Informe sobre liderazgo expert (2010). Disipando la niebla
alrededor del Cloud Computing.
Disponible en:
ftp://ftp.software.ibm.com/common/ssi/ecm/es/ciw03062eses/CIW03062ESES.PDF
Accesado el: [01 Marzo 2012]
3. Centro Internacional de la Papa. Annual Report (2010). Putting Strategy into Action:
Implementing the CIP corporate and strategic plan to enhance pro-poor research
impacts.
Disponible en:
http://cipotato.org/cipotato/publications/pdf/005719.pdf
Accesado el: [01 Marzo 2012]

114
 ANEXOS

ANEXO Nº 01
SERVIDOR IN – HOUSE
¿Cuál es su satisfacción sobre el servicio?

Muy satisfecho Satisfecho Neutral Insatisfecho Muy insatisfecho

35%
30%

20%

10%
5%

Muy satisfecho Satisfecho Neutral Insatisfecho Muy

insatisfecho

Muy satisfecho 10%

Satisfecho 30%
Neutral 35%
Insatisfecho 20%
Muy insatisfecho 5%
Total 100%

¿Cómo calificaría su acceso al servicio?

Muy rápida Rápida Normal Lento Muy lento

Muy lento 15%

Lento 30%

Normal 20%

Rápida 25%

Muy rápida 10%

Muy rápida 10%

Rápida 25%
Normal 20%
Lento 30%
Muy lento 15%
Total 100%
115
¿Cuál es el principal motivo porque no accede al servicio?

Falta de tiempo
Otros
Demora en el acceso al espacio
Tiene copia local de los principales documentos

Tiene copia local de los principales documentos 20%

Demora en el acceso al espacio 60%

Otros 5%

Falta de tiempo 15%

Falta de tiempo 15%

Otros 5%
Demora en el acceso al espacio 60%
Tiene copia local de los principales documentos 20%
Total 100%

SERVIDOR EN LA NUBE
¿Cuál es su satisfacción sobre el servicio?

Muy satisfecho Satisfecho Neutral Poco satisfecho Muy insatisfecho

50%

35%

10%
5%
0%

Muy Satisfecho Neutral Poco Muy

satisfecho satisfecho insatisfecho

Muy satisfecho 35%

Satisfecho 50%
Neutral 10%
Poco satisfecho 5%
Muy insatisfecho 0%
Total 100%

116
¿Cómo calificaría su acceso al servicio?

Muy rápida Rápida Normal Lento Muy lento

Muy lento 0%

Lento 10%

Normal 25%

Rápida 45%

Muy rápida 20%

Muy rápida 20%

Rápida 45%
Normal 25%
Lento 10%
Muy lento 0%
Total 100%

¿Cuál es el principal motivo porque no accede al servicio?

Falta de tiempo
Otros
Demora en el acceso al espacio
Tiene copia local de los principales documentos

Tiene copia local de los principales 20%

documentos

Demora en el acceso al espacio 10%

Otros 60%

Falta de tiempo 10%

Falta de tiempo 10%

Otros 60%
Demora en el acceso al espacio 10%
Tiene copia local de los principales documentos 20%
Total 100%

117