Estrategias de Migración A Un Entorno de Computación en La Nube PDF

U NIVERSIDAD N ACIONAL DE A SUNCIÓN FACULTAD
P OLITÉCNICA
T ESIS DE M AESTRÍA EN T ECNOLOGÍA DE LA I NFORMACIÓN Y

C OMUNICACIÓN CON É NFASIS EN R EDES DE D ATOS
ESTRATEGIA DE MIGRACIÓN A UN
ENTORNO DE COMPUTACIÓN EN LA
NUBE
Autor: Tutores:
Ing. Alberto Capli Dr. Carlos Núñez
Dr. Fabio López
S AN L ORENZO - PARAGUAY
2020
i
Resumen
Las últimas tendencias de investigación muestran un desequilibrio cada vez mayor entre
las demandas de las aplicaciones de software (SW) y el aprovisionamiento de recursos
hardware. La desalineación de la oferta y la demanda dificulta gradualmente que las
cargas de trabajos se mapeen eficientemente a nodos de servidores de tamaños fijos en
los centros de datos tradicionales.
Esta investigación presenta una estrategia y planificación para la migración de un cen-
tro de datos tradicional a un entorno de computación en la nube. La estrategia presentada
permitirá disponer una hoja de ruta para la migración de la infraestructura tradicional,
respondiendo así a los nuevos requerimientos de la sociedad que están soportado bajo el
modelo de servicio en la nube.
En el análisis realizado para el caso de estudio se encontraron, 147 servicios, de los
cuales, el 40.1 % están apagados y deben ser retirados, el 12,9 % deben ser apagados (en-
cendido y sin uso) y retirados, el 7.5 % deben ser retenidos (no deben ser migrados) den-
tro de la institución, el 19 % debe ser migrado a IaaS (Infrastructure as a Service) y pos-
teriormente a SaaS (Software as a Service), el 18.4 % deben ser migrados directamente a
IaaS, y el 2.1 % deben ser migrados directamente a SaaS.
Como principal aporte de este trabajo se puede mencionar la estrategia específica
presentada para la institución. Los pasos presentados para llevar a cabo esta innovación
permitirán implementar nuevas metodologías de trabajo y tener nuevos enfoques para
la educación.
Palabras Claves: Centro de Datos, Migración, Computación en la Nube.
ii
Índice general
Resumen i
1 Introducción 1
1.1 Fundamentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.1 Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Organización de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Computación en la Nube 3
2.1 Características Principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Modelos de Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Tipos de Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Características que necesita un aplicativo para ser considerado poseedor
de una arquitectura nativa de la nube . . . . . . . . . . . . . . . . . . . . . 5
2.5 Economía informática en la nube . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Centro de Datos Convencional vs Centro de Datos en la Nube . . . . . . . 8
2.7 Conclusiones del Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Migración a la Nube 10
3.1 Fundamentos de la estrategia de migración . . . . . . . . . . . . . . . . . . 10
3.2 Tipos de Migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Comparaciones de Tipos Migración . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Estrategias de Migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.1 Estrategia 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.2 Estrategia 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.3 Estrategia 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.4 Estrategia 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Estrategia de Migración Propuesta . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Análisis Financiero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Ambiente de Experimentación 33
4.1 Plantilla sobre Diseño de Red . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Plantilla sobre Detalles de Servidores . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Plantilla sobre Detalles de Sistemas . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Plantilla sobre Orden de Migración . . . . . . . . . . . . . . . . . . . . . . . 39
5 Caso de Estudio 42
5.1 Planeación de Migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Estado Actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.1 Detalle de la Capa Física . . . . . . . . . . . . . . . . . . . . . . . . . 43
iii
5.2.2 Detalle de Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2.3 Detalles de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.4 Diagramas de uso y consumo de las aplicaciones críticas . . . . . . 56
5.3 Orden de migración a entorno de computación en la nube . . . . . . . . . 58
6 Resultados 59
6.1 Estadística de Migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2 Estimación de Inversión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2.1 Metodología de Cálculo . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2.2 Suposiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7 Conclusiones y Trabajo Futuros 72

7.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.2 Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.3 Presentación de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8 Anexo 74
iv
Índice de figuras
2.1 Tipos de Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Aprovisionamiento en la Nube . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Uso de recursos en Centro de Datos Tradicionales . . . . . . . . . . . . . . 7
3.1 Tipos de Migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Proceso de Migración de Aplicaciones . . . . . . . . . . . . . . . . . . . . . 15
3.3 Albol de Dependencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Pasos para la Migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Estrategia de Migración Propuesta . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Plantilla de Diseño Físico y Lógico de la Red . . . . . . . . . . . . . . . . . 34
5.1 Interconexión de Servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 Diseño Físico de Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3 Diseño Lógico de Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4 Enrutadores virtuales con Balanceador de Carga . . . . . . . . . . . . . . . 52
5.5 Controlador Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.6 Estadística de uso del Sistema Educa . . . . . . . . . . . . . . . . . . . . . . 56
5.7 Estadística de uso del Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.8 Estadística del Sistema de Inscripción . . . . . . . . . . . . . . . . . . . . . 57
6.1 Dependencias de Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2 Criticidad de Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3 Gráfica de Tipo de Migración . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.4 AWS - Total Cost of Ownership (TCO) Comparison . . . . . . . . . . . . . 65
6.5 Calculo de Costo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.6 Calculo de costos de On-premises . . . . . . . . . . . . . . . . . . . . . . . . 67
6.7 Comparación de AWS y Vendedores de HW . . . . . . . . . . . . . . . . . 67
v
Índice de cuadros
2.1 Virtualización vs Computación en la Nube . . . . . . . . . . . . . . . . . . 9
3.1 Resumen de Tipos de Migraciones de la Literatura . . . . . . . . . . . . . . 12

3.2 Tipos y Soluciones de Migración . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Comparaciones de Tipo de Migración . . . . . . . . . . . . . . . . . . . . . 18
3.4 Estrategias de Migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5 Clasificación de Tipo de Organización . . . . . . . . . . . . . . . . . . . . . 22
3.6 Resumen de Estrategias de Migración Aplicadas al Caso de Estudio . . . . 28
3.7 Extracción de la Estrategias de Migración Propuesta . . . . . . . . . . . . . 29
3.8 Estrategia de Migración Propuesta para el Caso de Estudio . . . . . . . . . 30
4.1 Plantilla para detalles de Switches . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Plantilla para detalles de WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Plantilla para detalles de Enrutadores . . . . . . . . . . . . . . . . . . . . . 36
4.4 Plantilla para detalles de Servidores . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Plantilla para detalles de Servidores Públicos y Privados . . . . . . . . . . 38
4.6 Plantilla para detalles de Servidores Físicos . . . . . . . . . . . . . . . . . . 38
4.7 Plantilla para detalles de Storage . . . . . . . . . . . . . . . . . . . . . . . . 38
4.8 Clasificación de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.9 Plantilla Orden de Migración . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1 Proveedores de Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 Servidor 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3 Servidor 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4 Enrutadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.6 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.8 Clasificación de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.9 Sistemas Operativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.1 Estadística de Tipo de Migración . . . . . . . . . . . . . . . . . . . . . . . . 60

vi
Abreviaciones
NIST National Institute of Standards and Technology

FP-UNA Facultad Politécnica - Universidad Nacional de Asunción
TIC Tecnología de la Información y Comunicación
TI Tecnología de la Información
VPN Virtual Private Network
IaaS Infraestructure as a Service
PaaS Platform as a Service
SaaS Software as a Service
CPU Central Processing Unit
GPU Graphics Processing Unit
VM Máquina Virtual
HW Hardware
SW Software
SLA Service Level Agreement
RAM Random Access Memory
CNC Centro Nacional de Computación
CAPEX Capital Expenditure
VLAN Virtual LAN
WAN Wide Área Network
AWS Amazon Web Services
TCO Total Cost of Ownership
KVM Kernel-based Virtual Machine
SSD Solid State Drive
IOPS Input/Output Operations Per Second
RAID Redundant Array of Independent Disks
EC2 Elastic Compute Cloud
EBS Elastic Block Store
1
Capítulo 1
Introducción
1.1 Fundamentación
En la actualidad, las TIC (Tecnología de Información y las Comunicaciones) juegan un
papel protagónico en el día tras día del desarrollo de la sociedad, hasta el punto de con-
vertirse en el área contemporánea de mayor dinamismo económico, técnico y jurídico;
debido a esto, la dependencia de las redes de comunicaciones es cada vez más fuerte,
creando la necesidad de acceder a la información desde cualquier punto, desde cualquier
dispositivo, en cualquier momento y de manera segura. Las soluciones a estas necesi-
dades se están soportando bajo el modelo de servicio en la nube, lo cual ha llevado a
una revolución respecto a cómo los proveedores de infraestructura tecnológica deben
responder a estos requerimientos de la sociedad, para hacer más fácil y provechosa la
interacción con el resto del mundo [22].
La utilización promedio de muchos servidores en los centros de datos distribuidos
está muy por debajo de los máximos aceptables, desperdiciando recursos costosos [14].
Las últimas tendencias de investigación muestran un desequilibrio cada vez mayor
entre las demandas de las aplicaciones de software (SW) y el aprovisionamiento de re-
cursos hardware. La desalineación de la oferta y la demanda dificulta gradualmente que
las cargas de trabajos se mapeen eficientemente a nodos de servidores de tamaños fijos
en los centros de datos tradicionales [23].
Este proyecto presenta una estrategia y planificación para la migración del centro
de datos tradicional a un entorno de computación en la nube, para brindar una posible
solución a la falta de escalabilidad masiva y rápida, problema de eficiencia, flexibilidad
en la gestión de recursos, entre otros, tomando como escenario particular, la FP-UNA.
1.2 Objetivos
1.2.1 Objetivo General
Realizar un estudio para la migración del Centro de Datos de la FP-UNA a un entorno
de computación en la nube.
1.2.2 Objetivos Específicos

• Realizar un estudio de la infraestructura de comunicación actual.
• Realizar un estudio de la infraestructura de sistema.
• Estudiar el uso los recursos en el Centro de Datos local.
• Proponer una estrategia de migración del Centro de Datos a un ambiente de compu-

tación en la nube.
Capítulo 1. Introducción 2
1.3 Organización de la Tesis

El trabajo está organizado como sigue:
En el Capítulo 2 (Computación en la Nube), se realiza una descripción de lo que es
la computación en la nube, se presenta las características principales, los modelos de
implementación, los tipos de servicios y cuestiones relacionadas a la economía en la nube.
En el Capítulo 3 (Migración a la Nube), se presenta los tipos de migración, algunas
estrategias de migración según la literatura y la migración propuesta.
En el Capítulo 4 (Ambiente de Experimentación), se presenta las plantillas que se
debería usar para realizar el estudio de migración.
En el Capítulo 5 (Caso de Estudio), se presenta la estrategia de migración propuesta
para la FP-UNA.
En el Capítulo 6 (Resultados), se muestran los resultados después de aplicar los pro-
cesos de migración para la FP-UNA.
En el Capítulo 7 (Conclusiones y Trabajos Futuros) se presentan las conclusiones a las
que se llegó luego de realizar el trabajo y algunas ideas para trabajos futuros que podrían
continuar la propuesta presentada en esta tesis.
En el Capítulo 8 (Anexo) se anexa los detalles de los cálculos realizados para realizar
la comparación de costos entre los sistemas de un Centro de Datos tradicional y en un
entorno de computación en la nube.
3
Capítulo 2
Computación en la Nube
Según la definición del Instituto Nacional de Estándares y Tecnología (NIST), la compu-

tación en la nube es un modelo de servicio que permite a los usuarios acceder a servicios
de internet de forma ubicua y configurar sus propios recursos informáticos compartidos,
como redes, servidores, dispositivos de almacenamiento, aplicaciones y otros [12].
El avance notable de tecnologías como la computación distribuida, internet y grid
computing, han posibilitado que la Computación en la Nube forme parte de un nuevo
modelo de la computación y de los negocios. La Computación en la Nube está trans-
formando los modos tradicionales de cómo las organizaciones utilizan y adquieren los
recursos de Tecnología de la Información (TI). Ésta, entrega mayor eficiencia, permite
una escalabilidad masiva de forma rápida, y facilita el desarrollo de software [30].
En este capítulo se presenta las principales características de la nube, cuatro modelos
de implementaciones, los tipos de servicios ofrecidos, la economía informática en la nube
y finalmente una comparación de un centro de datos tradicional y un centro de datos en
la nube.
2.1 Características Principales

A continuación se presenta algunas de las características principales de la computación
en la nube [3, 30]:
• El servicio al usuario de diferentes modelos de infraestructura se ajusta a los reque-

rimientos de la aplicación, la cual se realiza mediante interfaces de simple interac-
ción.
• La independencia de las complicaciones en la gestión de los recursos. De esta ma-

nera se puede contar con una infraestructura tecnológica capaz de adaptarse evo-
lutivamente al proceso de negocio, apoyando las estrategias de forma flexible y
efectiva, a costos manejables.
• La aparición de recursos de computación “infinitos”, disponibles bajo demanda, lo

suficientemente rápido como para seguir las sobrecargas, eliminando así la necesi-
dad de que los usuarios planifiquen mucho para el aprovisionamiento.
• La eliminación de un compromiso inicial por parte de los usuarios de la nube, lo

que permite a las empresas comenzar de manera pequeña y aumentar los recursos
de hardware solo en caso de necesidad.
• La capacidad de pagar por el uso de los recursos informáticos a corto plazo según
la necesidad (por ejemplo, procesadores por hora y almacenamiento por día) y li-
berarlos cuando ya no son necesarios.
Capítulo 2. Computación en la Nube 4
2.2 Modelos de Implementación

La computación en nube tiene 4 modelos de implementación y varios tipos de servicios
divididos de la siguiente manera [24]:
• Nube Pública: los servicios son ofrecidos vía internet y a cualquier usuario, tanto
persona física como jurídica tienen acceso a estos servicios. El usuario paga por el
tiempo de uso y/o capacidad de procesamiento.
• Nube Privada: el acceso a los servicios está limitado a una única organización y sólo
para los usuarios autorizados. El acceso se realiza a través de la red privada virtual
(VPN) o la intranet de la organización.
• Nube Comunitaria: estructura de nube que sirve a dos o más organizaciones que
comparten sus recursos.
• Nube Híbrida: es una estructura que utiliza dos o más de los modelos citados ante-
riormente.
2.3 Tipos de Servicios

Son varios los servicios ofrecidos en la nube, pero todos son derivaciones de tres servicios
básicos que se observa en la Figura 2.1 y se describen a continuación [22].
F IGURA 2.1: Tipos de Servicios [22].
• Software como servicio (SaaS): se encuentra en la capa más alta y caracteriza una
aplicación completa ofrecida como un servicio, por demanda y vía multitenencia
(una sola instancia del software que corre en la infraestructura del proveedor y sirve
a múltiples organizaciones de clientes). Un ejemplo de SaaS son las aplicaciones
de Google (Google Apps), que brindan servicios primordiales de negocio como el
correo electrónico.
• Plataforma como servicio (PaaS): es la encapsulación de una abstracción de un am-
biente de desarrollo y el empaquetamiento de una serie de módulos o complemen-
tos que proporcionan, normalmente, una funcionalidad horizontal (persistencia de
datos, autenticación, mensajería, etc.). De esta forma, un arquetipo de plataforma
como servicio podría consistir en un entorno conteniendo una pila básica de siste-
mas, componentes o APIs pre-configuradas y listas para integrarse sobre una tec-
nología concreta de desarrollo.
• Infraestructura como servicio (IaaS): se encuentra en la capa inferior y es un me-

dio de entregar almacenamiento básico y capacidades de cómputo como servicios
estandarizados en la red. Servidores, sistemas de almacenamiento, conexiones, en-
rutadores y otros sistemas se concentran (por ejemplo a través de la tecnología de
virtualización) para manejar tipos específicos de cargas de trabajo (desde proce-
samiento en lotes hasta aumento de servidor/almacenamiento durante las cargas
pico). La oferta comercial más conocida es Amazon Web Services, por sus servicios
EC2 para cómputo, y S3 para almacenamiento.
2.4 Características que necesita un aplicativo para ser considera-

do poseedor de una arquitectura nativa de la nube
A continuación se presenta las principales características de un aplicativo para ser consi-
derado poseedor de una arquitectura nativa de la nube [15], estos principios se elabora-
ron a partir de una serie de artículos y estudios [1, 4, 5, 17, 21, 27, 32, 34].
1. No escribir la aplicación para una topología específica. No suponer la existencia fija
de nodos [5, 17, 21].
2. No asumir que el sistema de archivos local es permanente. No suponer el ciclo de
vida de los archivos en el sistema de archivos [17, 21].
3. No mantener una sesión en la aplicación. Una aplicación del tipo stateful limita la
escalabilidad, se sugiere que sea stateless [17, 21, 32].
4. No escribir logs en el sistema de archivos. Con logs escritos localmente, se pierde
información y trazabilidad si la máquina falla [1, 5, 17, 21, 32].
5. No utilizar APIs de infraestructura ni características propias del sistema operativo.
Evitar utilizar “APIs de la infraestructura o de SO” ya que dificultan el monitoreo por
parte del proveedor de nube [5, 21].
6. No utilizar protocolos oscuros. Evitar protocolos que requieran de alguna configu-
ración especial que pueda afectar la escalabilidad [1, 17, 21, 32].
7. No instalar manualmente la aplicación. La instalación sencilla permite adoptar di-
ferentes técnicas de automatización [1, 4, 5, 17, 21, 27, 32].
8. Código base. Cada aplicación desplegable se debe mantener en un código único
bajo un control de revisión [1, 17, 32].
9. Servicios de soporte. Los servicios de soporte deben tratarse como recursos adjun-
tos, de consumo idéntico en los entornos de despliegue [1, 32].
10. Concurrencia. Dos o más procesos son concurrentes cuando se ejecutan al mismo
tiempo y no existen dependencias entre los mismos [1, 32].
11. Desechabilidad y robustez. Es el manejo de entradas inválidas, permitiendo así
confiabilidad y recuperación frente a accidentes [1, 4, 17, 27, 32].
12. Procesos administrativos. Procesos de “una sola vez” deberían ejecutarse en en-
tornos idénticos a los procesos regulares de larga duración [1, 17, 32].
13. Escalabilidad. Los sistemas que se espera que crezcan con el tiempo necesitan ser
construidos sobre una arquitectura escalable [4, 5, 27, 34].
14. Procesos stateless. Se debe tener componentes débilmente acoplados, que ideal-
mente no compartan nada [17, 27, 34].
15. Paralelización. Busca analizar cómo superponer operaciones para mejorar el ren-
dimiento y el uso de infraestructura al realizar una tarea concreta [34].
16. Técnicas y estrategias de tolerancia a fallos. Describe un sistema diseñado de modo
a que en caso de fallo puede restablecerse y alertar sin la pérdida del servicio [4, 5, 17, 34].
17. Evitar adivinar la necesidad de capacidad. Una aplicación orientada a la compu-
tación en la nube debe prepararse para usar recursos bajo demanda [5, 17, 34].
18. Aplicar seguridad en todas las capas. Se debe proteger la integridad y privacidad
de la información almacenada en un sistema [4, 5, 17].
2.5 Economía informática en la nube
F IGURA 2.2: Uso de recursos en un ambiente de computación en la nube

[3].
A continuación se presenta tres casos de uso particularmente convincentes que favo-

recen a la informática en la nube sobre el alojamiento convencional [3].
• Cuando la demanda de un servicio varía con el tiempo. Por ejemplo, el aprovisio-

namiento de un centro de datos para la carga pico que se genera por unos pocos
días al mes conduce a la infrautilización en otros momentos. En cambio, la compu-
tación en la nube permite que las organizaciones paguen por horas, los recursos
informáticos utilizados, lo que puede generar ahorros en los costos.
• Cuando la demanda se desconoce de antemano. Por ejemplo, el inicio de un ser-

vicio web, deberá soportar un aumento en la demanda cuando se vuelva popular,
seguido de una reducción una vez que algunos visitantes se alejen.
• Cuando las organizaciones que realizan análisis por lotes pueden usar la “asocia-
tividad de costos"de la computación en la nube para terminar los cálculos más rá-
pido: el uso de 1000 máquinas durante una hora cuesta lo mismo que usar una
máquina durante 1000 horas.
Las horas compradas a través de la computación en la nube pueden distribuirse de

manera no uniforme en el tiempo (por ejemplo, si se usa cien horas de servidor en un día,
cero horas de servidor al día siguiente, y aún se pague solo por cien); en la comunidad de
redes, esta forma de vender ancho de banda se conoce como precios basados en el uso.
Además, la ausencia de gastos de capital iniciales permite que el capital se redirija a la
inversión empresarial principal [3].
F IGURA 2.3: Uso de recursos en Centro de Datos Tradicionales [3].

En la Figura 2.3 (a) se puede observar que incluso si la carga máxima se puede antici-
par correctamente, sin elasticidad se desperdicia recursos (área sombreada) durante tiem-
pos de no pico. (b) Caso de sub-provisionamiento 1: los ingresos potenciales de los usua-
rios no atendidos (área sombreada) se sacrifican. (c) Caso 2 de sub-provisionamiento:
algunos usuarios abandonan el sitio permanentemente después de experimentar un ser-
vicio deficiente; este resultado, posiblemente generará una pérdida permanente de una
porción de la corriente de ingresos.
En caso de un entorno de computación en la nube, la carga de trabajo se aprovisiona
de acuerdo a la necesidad, como se observa en la Figura 2.2, de esta forma se reduce el
exceso de capacidad y evita el abandono de los clientes por servicios deficientes, además
de permitir reducir las inversiones iniciales.
2.6 Centro de Datos Convencional vs Centro de Datos en la Nu-

be
Un centro de datos tradicional a menudo consiste en varios tipos de nodos de cálculo,
donde cada uno de los nodos funciona como un servidor independiente. Los nodos del
mismo tipo se configuran con una capacidad o tamaño específico en términos del número
de núcleos de CPU, tamaño de memoria, almacenamiento, número de GPU y el ancho
de banda de red. La capacidad física de un nodo es relativamente constante ya que la
reconfiguración dinámica de la capacidad física en la escala del centro de datos implica
esfuerzos humanos sustanciales [23].
La adopción de Computación en la Nube por parte de las empresas ha estado crecien-
do constantemente en los últimos años. A pesar de esto, la migración a Computación en
la Nube, o cualquier otro tipo de solución de TI, debe ser cuidadosamente estudiada [24].
La virtualización es una tecnología que le permite crear múltiples entornos simula-
dos o recursos dedicados desde un solo sistema de hardware físico. El software llamado
hipervisor se conecta directamente a dicho hardware y le permite dividir en entornos se-
parados, distintos y seguros conocidos como máquinas virtuales (VM). Estas máquinas
virtuales se basan en la capacidad del hipervisor para separar los recursos de la máquina
del hardware y distribuirlos de manera adecuada [31].
La computación en la nube es un conjunto de principios y enfoques para ofrecer re-
cursos, servicios, plataformas y aplicaciones de infraestructura de computación, red y
almacenamiento a los usuarios bajo demanda a través de cualquier red. Estos recursos
de infraestructura, servicios y aplicaciones provienen de nubes, que son conjuntos de re-
cursos virtuales orquestados por software de administración y automatización para que
los usuarios puedan acceder a ellos a través de portales de autoservicio soportados por
escalamiento automático y asignación dinámica de recursos [31].
TABLA 2.1: Virtualización vs Computacion en la Nube [3, 31]
Virtualización Computación en la Nube

Definición Tecnología Metodología
Crear múltiples entornos Asigna un conjunto de recursos
Propósito simulados a partir de 1 sistema virtuales de forma automática para
de hardware físico el uso bajo demanda
Entregar recursos empaquetados Entregar recursos variables a grupos
Uso a usuarios específicos para de usuarios para una variedad de
un propósito específico propósitos
Configuración Basada en imagen Basada en plantilla
Duración Años (a largo plazo) Horas a meses (corto plazo)
Altos gastos de capital (CAPEX), Nube privada: alto CAPEX, bajo OPEX
Costo
bajos gastos operativos (OPEX) Nube pública: bajo CAPEX, alto OPEX
Escalabilidad Vertical (Ampliar) Horizontal (Escalar)
Tenancy Single tenant Multiple tenants
En la Tabla 2.1 se puede observar una comparación entre la virtualización y el entorno

de computación en la nube. La virtualización es una tecnología y la nube es una meto-
dología de computación. Cuando una aplicación exige más de una VM, se puede asignar
a dicha VM más recursos para que pueda manejar la demanda por sí misma (ampliar),
o puede generar más máquinas virtuales y dispersar la demanda entre ellas (escalar). Si
la aplicación se encuentra en un entorno en la nube, puede aumentar la escala aprovisio-
nando más recursos físicos, virtualizando, enrutando a los grupos de recursos existentes
y administrando a través de los controles de la nube existente.
2.7 Conclusiones del Capítulo

Las aplicaciones que brindan servicios en la nube deben cumplir con una serie de caracte-
rísticas para considerarse nativa de la nube, pueden implementarse en cuatro modelo de
implementación (Nube pública, privada, Comunitaria e Híbrida) y tres tipos de servicios
en la nube (IaaS, PaaS y SaaS). Cada modelo de implementación y cada tipo de servicios
tiene sus ventajas y desventajas.
En un entorno de Centro de Datos tradicional existe un máximo fijo de capacidad, lo
que implica una falta o desperdicio de los recursos a lo largo del tiempo, sin embargo, en
un entorno de computación en la nube, la carga de trabajo se aprovisiona de acuerdo a
la necesidad, de esta forma se reduce el exceso de capacidad y evita el abandono de los
clientes por servicios deficientes, además de permitir reducir las inversiones iniciales.
10
Capítulo 3
Migración a la Nube
El proceso de migración a la nube se refiere a una serie de tareas realizadas para migrar
una aplicación al entorno de computación en la nube. Las aplicaciones heredadas han
presentado importantes desafíos para las empresas que realizan este tipo de migración.
Esto se debe principalmente a la falta de voluntad de las organizaciones para invertir en
el desarrollo de aplicaciones completamente nuevas o en la compra de más equipos [12].
Al igual que con todas las tecnologías disruptivas, cualquier iniciativa de migración a
la nube debe enfocarse con precaución y basarse en una estrategia que incluya una visión
global y atención rigurosa a los problemas de seguridad [19].
Hay numerosas opciones por hacer que pueden transformar las complejidades del
proceso de migración en una transición relativamente suave, especialmente con respecto
a la seguridad de aplicaciones y datos [19].
En la actualidad, no existe una metodología definida o un estándar internacional
aceptado para que las organizaciones adopten el modelo de computación en la nube pa-
ra la operación de sus infraestructuras de TI [26]. Sin embargo, algunos autores plantean
recomendaciones para que las empresas lleguen inicialmente al modelo de nube privada
o híbrida, y potencialmente, pasen luego a la nube pública [9].
Cada organización define los requerimientos de integración y estandarización de sus
plataformas y servicios de TI según la visión que tengan sobre su crecimiento [35]. Así,
para la migración de servicios al modelo de nube, existen las llamadas “estrategias de mi-
gración”, métodos que son específicos para cada solución, ya que en muchas ocasiones
cada migración utiliza una metodología propia basada en unos requerimientos específi-
cos, que difícilmente se pueden utilizar en otra migración.
La migración que consiste en la transferencia de los sistemas a la nube utilizando
IaaS es relativamente fácil de implementar y tiene un buen costo beneficio [36], ésta es a
menudo la ruta que las organizaciones toman cuando son nuevas en la computación en
la nube [18, 19].
En este capítulo se presenta algunos fundamentos de la estrategia de migración, tipos
de migración, una comparación de migración, estrategias de migración según la literatu-
ra, estrategia de migración propuesta, y finalmente un análisis financiero.
3.1 Fundamentos de la estrategia de migración

Al igual que con la Metodología Agile, siempre se debe estar atento a los objetivos de la
organización al desarrollar la estrategia de migración. La estrategia requerirá conformi-
dad con la misión específica de la organización, pero existen componentes fundamentales
que son esenciales para todas las iniciativas de migración a la nube, las mismas se descri-
ben a continuación [19].
Capítulo 3. Migración a la Nube 11
• Se debe definir una estrategia de extremo a extremo que tenga en cuenta los ob-
jetivos de la organización, así como el impacto de la migración a la nube en las
operaciones de TI.
• Se debe aprovechar la oportunidad para descubrir y evaluar las aplicaciones de

la organización para ver dónde existen ineficiencias y dónde pueden corregirse y
optimizarse con los servicios en la nube disponibles.
• Se debe rediseñar las aplicaciones para integrarse de manera efectiva con los mo-
delos de servicios específicos ofrecidos en la nube.
• Se debe comprender el modelo de responsabilidad compartida en lo que se refiere

a la política de seguridad y mitigación de riesgos, y desarrollar políticas y controles
en consecuencia.
3.2 Tipos de Migración
F IGURA 3.1: Tipos de Migración
Existen varios tipos de migraciones mencionados por distintos autores, algunos de

ellos se mencionan en la Tabla 3.1, y se detallan a continuación.
Según [12], las aplicaciones existentes se pueden dividir aproximadamente en tres
categorías para la migración, las mismas se presenta a continuación:
• La primera categoría incluye aplicaciones que, debido a sus restricciones o requi-

sitos específicos, deberían permanecer en el entorno informático tradicional y no
serían adecuadas para el entorno de la nube. Por ejemplo, los sistemas de alta pri-
vacidad y otros sistemas integrados pueden no beneficiarse del entorno de nube.
• La segunda categoría de aplicaciones son aquellas especialmente desarrolladas pa-

ra funcionar en un ambiente de computación en la nube.
• La tercera categoría de aplicaciones se puede adaptar al entorno de la nube.

TABLA 3.1: Resumen de Tipos de Migraciones de la Literatura
Autor Retain Retire IaaS PaaS SaaS

Aplicaciones que debido
a sus restricciones o
requisitos específicos,
Aplicaciones especialmente
deberían permanecer
desarrolladas para
en el entorno
[12] - - - funcionar en un
informático tradicional
ambiente de nube
y no serían adecuadas
para el entorno
de la nube
Aplicaciones que se
pueden adaptar
al entorno de la nube.
Cloud Hosting: alojar
componentes de aplicación
[25] - - - - potencialmente
modificados para la nube
Cloudification: reemplazar
los componentes por
servicios apropiados para
la nube.
Aplicaciones
Aplicaciones que, especialmente desarrolladas
[12] - - -
debido a sus para un entorno de nube
restricciones o Aplicaciones adaptables
requisitos específicos, al entorno de nube
deben permanecer (Tipo I: reemplazar,
en el entorno Tipo II: migrar
informático tradicional parcialmente,
y no serían adecuadas Tipo III: migrar toda
para el entorno la pila de software, y
de nube Tipo IV: cloudify)
Reti- Rehos- Replat- Repurchasing
[6] -
ring ting forming Refactoring
Migración de Formato
Estandarizado
[8] - - - -
Migración de Formato de
Componente
Migración Holística
Autor Retain Retire IaaS PaaS SaaS

El primer tipo reemplaza componentes
con ofertas en la nube, que es el
tipo de migración menos invasivo
[2] - - -
El segundo describe el caso que migra
parte de la funcionalidad de la
aplicación a la nube
El tercero es el caso de migración en el
que toda la pila de software de la
aplicación se migra a la nube
El último es la migración completa
de la aplicación, que requiere la
migración de datos y la lógica de negocios
para la nube
Rehos- Refactor
[16] - - ting Rebuild Replace
Revise
[13] - - IaaS PaaS SaaS
En [25] se menciona dos estrategias y siete soluciones de migración al entorno de nu-

be, que se detallan en la Tabla 3.2. Las estrategias de migración consisten básicamente en
alojar componentes de aplicación potencialmente modificados en la nube o reemplazar-
los con servicios en la nube apropiados, como Cloud Hosting y Cloudification.
Según [12], las aplicaciones existentes se pueden dividir aproximadamente en tres ca-
tegorías, y existe cinco tipos diferentes de rutas para la migración, las mismas de detallan
a continuación.
• La primera categoría incluye aplicaciones que, debido a sus restricciones o requisi-

tos específicos, deben permanecer en el entorno informático tradicional y no serían
adecuadas para el entorno de nube. Por ejemplo, los sistemas de alta privacidad y
otros sistemas integrados pueden no beneficiarse del entorno de la nube.
• La segunda categoría de aplicaciones son aquellas especialmente desarrolladas pa-
ra realizar en un entorno de nube.
• La tercera categoría de aplicaciones es adaptable al entorno de nube.
Existen varios tipos diferentes de rutas de migración a través de las cuales las aplica-
ciones pueden adaptarse al entorno de la nube. Tipo I: reemplazar, Tipo II: migrar par-
cialmente, Tipo III: migrar toda la pila de software, y Tipo IV: cloudify.
Según [6, 18, 19, 29], existen seis tipos de migración que son: Rehosting, Replatfor-
ming, Repurchasing, Refactoring, Retain y Retiring.
Cada uno de estos métodos presentados se resume en la Figura 3.2 y se detallan a
continuación, los mismos tienen sus propios beneficios, pero algunos métodos tienen
costos diferentes asociados a ellos.
• Rehosting
Es el proceso de mover los servidores físicos y virtuales existentes a una solución
basada en Infraestructura como Servicio (IaaS). También conocido como elevación
y desplazamiento, el beneficio clave de este enfoque es que los sistemas se pueden
migrar rápidamente sin modificar su arquitectura. Esta es a menudo la ruta que las
organizaciones toman cuando son nuevas en la computación en la nube.
TABLA 3.2: Tipos y Soluciones de Migración [25]
Contexto de Escenario
Tipos Solución
migración de ejemplo
El componente de destino Migración de una aplicación
es totalmente compatible Cloud JEE a un contenedor JEE
Rebinding
con el entorno hosting que se ejecuta en una nube
operativo de la nube. pública de IaaS.
Migración de una aplicación
Una o más de las de escritorio a una nube
dependencias de servicios pública de IaaS con usuarios
externos del componente de Cloud Service que acceden de forma remota
destino son incompatibles, hosting Adaptation a la GUI de la aplicación a
pero pueden adaptarse través de un servicio de
para operar en la nube. escritorio virtual basado
en la web.
Una o más de las Convertir una aplicación de
dependencias de servicios proceso por lotes basada en
externos del componente de Cloud Service archivos en un servicio web
destino son incompatibles, hosting Conversion completo para permitir su
pero se pueden convertir migración a una nube
para operar en la nube. pública de IaaS
Deshabilitar o volver a
Una o más de las implementar las funciones
dependencias de servicios de creación de subprocesos
Cloud Compensa-
externos del componente de en una aplicación Java
hosting tion
destino son incompatibles multihilo para permitir
con la nube. su migración a una nube
pública de PaaS
El estado del componente
Reemplazo de un servidor
de destino es transferible
de base de datos relacional
a la nube, y hay un servicio Cloudifica- Replace-
local con un servicio de
en la nube candidato con tion ment
datos relacionales basado
una interfaz totalmente
en la nube
compatible.
Uso de un controlador de
sistema de archivos
de destino es transferible
personalizado para redirigir
a la nube, y hay un servicio Cloudifica- Interface
todos los accesos de disco
de nube candidato con una tion adaptation
locales a un servicio
interfaz incompatible pero
de almacenamiento de
adaptable.
archivos basado en la nube
Convertir una aplicación
de destino es transferible a
basada en archivos para
la nube, y existe un servicio Cloudifica- Interface
que pueda acceder un
de nube candidato con una tion conversion
servicio de almacenamiento
interfaz incompatible pero
basado en la nube
convertible.
F IGURA 3.2: Proceso de Migración de Aplicaciones [6]
Este tipo de migración puede proporcionar una solución de migración en la nube,

rápida y fácil. Existen ventajas y desventajas para esta estrategia, ya que los be-
neficios de elasticidad y escalabilidad basados en IaaS no están disponibles con la
implementación de redireccionamiento.
Es una forma de preservar las costosas inversiones en lógica de negocios y datos
comerciales atrapados en hardware y software patentados. Es particularmente efec-
tivo para una migración a gran escala, algunas organizaciones se han dado cuenta
de un ahorro de costos de hasta un 30 por ciento, sin tener que implementar opti-
mizaciones específicas de la nube.
Volver a alojar una aplicación sin realizar cambios en su arquitectura puede pro-
porcionar una solución rápida de migración en la nube. Sin embargo, la principal
ventaja de IaaS es que los equipos pueden migrar sistemas rápidamente, sin modi-
ficar su arquitectura. La principal desventaja es que se perderán los beneficios de
las características de la infraestructura en la nube, como la escalabilidad.
• Replatforming
Consiste en alojar las aplicaciones en una Plataforma como Servicio (PaaS). Esta
estrategia implica ejecutar aplicaciones en la infraestructura del proveedor de la
nube. Se puede realizar algunas optimizaciones relacionadas con la nube para ob-
tener algún beneficio tangible con relativa facilidad, pero no se invierte ciclos de
desarrollador para cambiar la arquitectura central de una aplicación.
Las ventajas de replatforming incluyen su compatibilidad hacia atrás que permite a
los desarrolladores reutilizar los recursos familiares, incluidos los lenguajes de pro-
gramación heredados, los marcos de desarrollo y los caches existentes del código
vital de una organización.
Una desventaja de esta estrategia es el estado incipiente del mercado PaaS, que no
siempre brinda algunas de las capacidades familiares que las plataformas existentes
ofrecen a los desarrolladores.
• Repurchasing/Replace
Con frecuencia, esta solución significa descartar una aplicación heredada o una pla-
taforma de aplicaciones, y desplegar un software disponible comercialmente entre-
gado como un servicio. La solución reduce la necesidad de un equipo de desarrollo
cuando los requisitos cambian rápidamente. La opción de Repurchasing a menu-
do se manifiesta como un cambio a una plataforma SaaS. Las desventajas pueden
incluir convenciones de nomenclatura inconsistentes, problemas de interoperabili-
dad y bloqueo de proveedor.
• Refactoring/Re-architecting/Rebuild
Esta solución implica volver a imaginar cómo se diseña y se desarrolla una apli-
cación, normalmente utilizando las características nativas de la nube de PaaS. Esto
generalmente es impulsado por una fuerte necesidad de agregar características, es-
cala o rendimiento que de otra manera sería difícil de lograr en el entorno existente
de la aplicación. Desafortunadamente, esto significa la pérdida de código hereda-
do y marcos de desarrollo familiar. Por otro lado, también significa el acceso a las
herramientas de desarrollador de clase mundial disponibles a través de la platafor-
ma del proveedor. Los ejemplos de herramientas de productividad proporcionadas
por los proveedores de PaaS incluyen plantillas de aplicaciones y modelos de da-
tos que se pueden personalizar, y comunidades de desarrolladores que suministran
componentes pre-construidos.
La principal desventaja de un acuerdo PaaS es que el cliente se vuelve extrema-
damente dependiente del proveedor. Las consecuencias de una desconexión con el
proveedor sobre las políticas o los precios pueden ser bastante perjudiciales. Un
cambio en los proveedores puede significar el abandono de la mayoría, si no todas,
de las aplicaciones rediseñadas de un cliente.
La Refactorización parcial modifica solo partes específicas de la aplicación para
aprovechar la plataforma en la nube, mientras que una refactorización completa
cambia la mayor parte de la aplicación.
• Retain
Conservar partes de la cartera de TI porque hay algunas aplicaciones que aún no
está listo para migrar y se siente más cómodo manteniéndolas on-premises, o no
está listo para priorizar una aplicación que se actualizó recientemente y volver a
cambiarla.
• Retiring
El paso inicial en el proceso de migración a la nube es el descubrimiento de toda
la cartera de TI. A menudo, este proceso de descubrimiento implica la medición de
aplicaciones para determinar el uso real de las aplicaciones implementadas. No es
inusual encontrar que entre el 10 y el 20 por ciento de una propiedad informática
organizacional ya no se usa. Retirar estas aplicaciones no utilizadas puede tener un
impacto positivo en los resultados de la organización; no solo con los ahorros de
costos que se obtienen al dejar de mantener las aplicaciones, sino al permitir que
los recursos de TI se dediquen a otros sitios, y al minimizar las preocupaciones de
seguridad por las aplicaciones obsoletas.
En [8] se clasificó la migración en tres tipos: Migración de Formato Estandarizado,

Migración de Formato de Componente y Migración Holística. Las mismas se detallan a
continuación.
• En la Migración de Formato Estandarizado, se migra un componente implemen-

tado en un formato estandarizado e independiente. Los componentes se mueven
entre instancias del mismo software u otras soluciones de software que admiten es-
te formato. Por ejemplo, la migración de VMware, imágenes de Open Virtualization
Format (OVF), Java define componente estandarizado como framework Enterprise
Java (EJB) y aplicación portátil como Java Web Archives (WAR).
• En la Migración de Formato de Componente, el formato del componente respectivo
se transforma en otro formato, por ejemplo, se transforma una imagen de máquina
virtual o habilitando la ejecución de lenguajes de scripting en PaaS.
• La Migración Holística consiste en la migración de una aplicación completa cons-
truida a partir de múltiples componentes, la migración se realiza por cada compo-
nente en forma separada. Este tipo de migración aborda aplicaciones compuestas
que constan de componentes en el software, la plataforma y el nivel de infraestruc-
tura.
En [2] se identificó cuatro tipos de migración que podrían habilitar las aplicaciones en
la nube por adaptación.
• El primer tipo reemplaza componentes con ofertas en la nube, que es el tipo de

migración menos invasivo.
• El segundo tipo migra parte de la funcionalidad de la aplicación a la nube.
• El tercer tipo migra toda la pila de software de la aplicación a la nube.
• El cuarto tipo migra la aplicación completa, que requiere la migración de datos y la
lógica de negocios para la nube.
Gartner [16, 29] sugiere que las organizaciones de tecnología de la información (TI)
consideren las siguientes cinco opciones cuando se busca trasladar los sistemas hereda-
dos a la nube: redestinar en la infraestructura como un servicio, refactorizar la plataforma
como servicio, revisar para IaaS o PaaS, reconstruir en PaaS y reemplazar con software
como servicio.
La compañía Cisco [13] considera tres opciones de migración de aplicaciones que

incluyen SaaS, PaaS y IaaS en el documento técnico para la migración de la aplicación
empresarial a la nube. Consideran que la migración a SaaS ya no es una migración de
aplicaciones, sino más bien un reemplazo de la aplicación existente con un SaaS. La mi-
gración a PaaS es una opción para migrar aplicaciones comerciales basadas en software
de servidor de aplicaciones estándar, como las plataformas JavaEE o .NET. La migración
a IaaS implica la implementación de la aplicación en el proveedor de servicios en la nube.
3.3 Comparaciones de Tipos Migración

EL tipo de estrategia ideal para una migración a la nube se basa en las necesidades indivi-
duales de cada organización y la condición del sistema heredado para elegir la estrategia
más racional antes de la migración [36].
Con la estrategia de PaaS, las organizaciones deben determinar el alcance de las modi-
ficaciones necesarias para que la aplicación sea compatible con la plataforma en la nube.
Si se requieren modificaciones extensas para PaaS, la estrategia de IaaS puede ser una
mejor opción. Como un mecanismo efectivo de entrega de software, SaaS podría ser una
opción ideal para los proveedores de software independientes, pero el desafío para la
reingeniería a SaaS es obvio. En la Tabla 3.3 se presenta una comparación de las caracte-
rísticas de cinco estrategias de migración [36].
TABLA 3.3: Comparaciones de Tipo Migración [36]
Migración Migración Remplazar Revisar basa- Reingeniería

a IaaS a PaaS por SaaS do en SaaS en SaaS
Carga de
trabajo de Baja Moderada Baja Moderada Alta
migración
Compleji-
dad de la Baja Moderada Baja Moderada Alta
migración
Modificar la Servicio e
Ingeniería
aplicación integración
Inversa,
Adaptacion No necesita para que No necesita de datos,
rediseño de
sea compati- composición
estructura.
ble con PaaS. del servicio
Mecanismo
de precios
Mecanismo Mecanismo
flexibles,
Ahorro en de precios de precios fle-
Libertad en fácil
gastos de flexibles, xibles, fácil
Efecto la gestión manteni-
equipamien- y fácil manteni-
de recursos miento,
tos mantenimiento,
reutiliza-,
miento y reutilización
ción y esca-
labilidad
Teniendo en cuenta los tipos de migración (IaaS, PaaS y SaaS) [13, 16, 29], a continua-
ción se presenta las ventajas desventajas de los mismos.
• El primer tipo implementa la migración transfiriendo el sistema heredado a la nube

utilizando IaaS.
Ventajas:
– Realoja la aplicación sin cambiar su arquitectura, agiliza la migración.
Inconvenientes:
– La aplicación no aprovecha beneficios de la infraestructura en la nube, como

la escalabilidad.
– El alojamiento o la virtualización de sistemas muy específicos o antiguos no
siempre es posible.
• El sistema heredado se migra a la nube mediante la refactorización del sistema se-

gún la plataforma de PaaS en la segunda estrategia.
Ventajas:
– Alarga la vida de las aplicaciones heredadas.

– Combina innovación y familiaridad, ya que las PaaS permiten el uso de len-
guajes y entornos que los desarrolladores conocen y dominan.
Inconvenientes:
– Algunas herramientas de desarrollo muy antiguas pueden plantear problemas

de compatibilidad y reducir la funcionalidad de las aplicaciones migradas.
– No explota todas las capacidades de PaaS
– Marco cerrado
• Migración a SaaS
Ventajas:
– Acceso a nuevas características que ofrece PaaS, que mejoran la productividad

de los desarrolladores, como herramientas para la personalización de planti-
llas de aplicaciones o modelos de datos.
Inconvenientes:
– Menor familiaridad con las herramientas que ofrece SaaS.

– Si el proveedor introduce cambios técnicos o de precio que el cliente no puede
aceptar, si viola el CNS o si desaparece, el cliente se verá obligado a cambiar, o
incluso a renunciar a algunas o a todas sus aplicaciones heredadas.
Las empresas a menudo migran sus sistemas a la plataforma en la nube adoptando la

migración IaaS. Para esta estrategia, la migración es relativamente fácil de implementar
y tiene un buen costo beneficio. Pero la migración no puede aprovechar al máximo la
plataforma en la nube. Para la segunda estrategia (PaaS), los sistemas deben adaptarse de
acuerdo con la plataforma de destino, lo que puede traer desventajas como capacidades
faltantes, riesgo transitivo y bloqueo de marcos. Para la estrategia relacionada con SaaS, si
el sistema es reemplazado por software comercial entregado como un servicio, el esfuerzo
de migración se reducirá en gran medida y la reingeniería es innecesaria. Al reemplazar
alguna lógica comercial con el servicio en la nube existente, es necesaria la adaptación
al sistema heredado. Pero para rediseñar el sistema heredado al servicio en la nube, el
trabajo relacionado será muy desafiante y puede requerir ingeniería inversa, rediseño de
la estructura, generación de servicios, etc [13, 16, 29].
La estrategia ideal para migrar a la nube no sólo depende de las necesidades de cada
empresa, sino también de las condiciones del antiguo sistema. Cada estrategia tiene sus
propios objetivos [29]:
• Con PaaS, las empresas tienen que determinar los cambios necesarios para que la
aplicación sea compatible con la plataforma en la nube.
• En los casos en que las empresas necesitan hacer más cambios para migrar a PaaS,
puede ser más apropiada la estrategia IaaS.
• Como mecanismo eficaz para la distribución de software, SaaS podría ser una op-
ción ideal, pero el reto para la reingeniería SaaS es evidente.
3.4 Estrategias de Migración

En esta investigación se analizaron cuatro estrategias de migración existentes, cada una
enfoca la migración desde distintas perspectivas.
En la Estrategia 1 se plantea la migración desde el punto de vista del tamaño de la
compañía y si la misma está relacionada con nuevas tecnologías. A medida que aumenta
el tamaño de las compañías, las exigencias en la migración aumentan, y por ende, la
cantidad de fases. El hecho de que la compañía esté relacionada con nuevas tecnologías,
facilita el proceso de migración.
En la Estrategia 2 se plantea la migración desde el punto de vista de las aplicaciones.
Se tiene en cuenta las dependencias entre aplicaciones y la criticidad de las mismas. Las
primeras aplicaciones que se debe migrar son las de menor dependencia y criticidad,
posteriormente las de mayor dependencia y prioridad.
En la Estrategia 3 se tiene en cuenta las consideraciones generales, técnicas y políti-
cas de la compañía, sin ahondar en detalles. Tiene en cuenta inicialmente la planificación,
como los aspectos de la viabilidad, posteriormente la ejecución, que consta en la migra-
ción, seguidamente las evaluaciones de la migración y finalmente las consideraciones
transversales, como la seguridad, elasticidad, multitenant, etc.
En la Estrategia 4 se tiene en cuenta las consideraciones generales, técnicas y políticas
de la compañía, con los detalles de dichas consideraciones. Inicialmente analiza los obje-
tivos de negocio, el sector financiero y el apoyo de la gerencia, y posteriormente se trata
los aspectos técnicos a tener en cuenta, como la planeación, diseño, ejecución y monitoreo
de la migración.
A continuación se detallan cada una de las estrategias de migración.
3.4.1 Estrategia 1
La compañía Google proporciona un método que permite elegir entre diferentes estrate-
gias de migración [28]. Las diferencias están en el alcance del enfoque, es decir, que las
diferentes estrategias incluyen más o menos pasos dependiendo del tipo de organización.
Las estrategias son cinco, y las mismas se resume en la Tabla 3.4.
Las cinco estrategias se clasifican de la más simple a la más compleja. Cada una de-
fine qué tareas deben planificarse: estudio preliminar, proyecto piloto, configuración del
soporte al usuario, migración en sí e integración avanzada con el sistema de información.
La cantidad de usuarios está relacionada con el tamaño de la compañía, es el pará-
metro fundamental en la elección de una estrategia de migración. Migrar sistemas que
utilizan 50 usuarios es bastante diferente de migrar varios sistemas con miles de usua-
rios.
Así, las empresas se clasifican en lo siguiente:
• Empresas muy pequeñas, que tienen menos de 10 usuarios.
• Pequeñas empresas, que tienen entre 10 y 250 usuarios.
• Empresas medianas con 250 a 2.000 usuarios.
• Grandes empresas con más de 2.000 usuarios.
Contrariamente a la creencia popular, la duración y la complejidad de una migración

y un proyecto piloto no están necesariamente vinculados a la cantidad de usuarios a mi-
grar. Pero los pasos del proyecto de migración, sin embargo, están relacionados con este
parámetro. Por ejemplo, es muy probable que una gran empresa solicite asistencia de
TABLA 3.4: Estrategias de Migración [28]
Tipo de
Fases Público Interesado
Estrategia
Este tipo de migración se aplica a las pequeñas
Estrategia 1. Estudio compañías con un bajo nivel de dependencia
“Flash” 2. Migración del SI y que tienen recursos humanos
autónomos desde el punto de vista técnico.
Este tipo de estrategia también es apropiado
1. Estudio para pequeñas compañías. Pero la diferencia
Estrategia “Do
2. Formación es que es necesario asegurar la formación
it yourself”
3. Migración de algunos de sus actores para que ellos
mismos realicen la migración.
Esta estrategia se adapta a las pequeñas y
1. Estudio
medianas compañías a las que se puede
2. Prueba
Estrategia proporcionar formación en materia de
piloto
“Light” migración. Si existe una gran dependencia
3. Formación
respecto de un sistema informático, puede
4. Migración
merecer la pena hacer una prueba piloto.
Esta estrategia es la que mejor se adapta a
1. Estudio
medianas y grandes compañías. Además de
2. Prueba piloto
Estrategia la realización de una prueba piloto, puede
3. Soporte
“Estándar” resultar necesario organizar un soporte
4. Formación
dedicado debido al nivel técnico de los
5. Migración
usuarios y a su importancia numérica.
1. Estudio En este caso se trata de grandes compañías.
2. Plan de La dependencia del sistema de información
reversibilidad es importante. Requiere no sólo la
3. Prueba piloto realización de una prueba piloto, sino una
Estrategia
4. Soporte fase específica con un plan de
“Advanced”
5. Formación reversibilidad que permita minimizar el
6. Migración riesgo de fracaso de la migración. Suele ser
7. Integración necesaria la implementación de un soporte
avanzada dedicado.
gestión de cambios para sus usuarios, mientras que una pequeña empresa de alta tecno-
logía probablemente pueda prescindir de dicha asistencia. Antes de pensar en migrar, la
primera tarea es evaluar con precisión las herramientas y necesidades existentes.
El perfil de una organización se define por su tamaño, su dispersión geográfica y el
tipo de población afectada por la migración.
Para cada uno de estos tipos de organización, la Tabla 3.5 resume las estrategias más
usuales que se pueden aplicar para una migración a Google, y la misma se detalla a
continuación.
TABLA 3.5: Clasificación de Tipo de Organización [28]
A continuación se describe qué tipo de estrategia se debe utilizar para cada tipo de
organización.
Organización de Tipo 1 (OT1)
• Organizaciones muy pequeñas de no más de 10 usuarios.
• Un solo sitio geográfico.
• Servidor de correo de fuente abierta, alojado fuera del sitio.
• La población objetivo está orientada técnicamente.
• No hay necesidades avanzadas.
En su mayoría son pequeñas empresas que se especializan en nuevas tecnologías, la

migración flash está particularmente bien adaptada porque la población es técnicamente
autónoma. La formación y el apoyo son en este caso innecesarios. Además, el pequeño
número de usuarios favorece una delegación completa de toda la migración a los propios
usuarios, desde la transferencia de datos hasta la configuración de las diversas herra-
mientas.
• Organizaciones muy pequeñas de no más de 10 usuarios.

• La población objetivo tiene un perfil no técnico.
Estas son pequeñas organizaciones cuyo negocio no está relacionado con las nuevas
tecnologías. Aquí nuevamente, la pequeña cantidad de usuarios les permite hacerse car-
go de la migración ellos mismos. Sin embargo, debe planearse una fase de entrenamiento.
• Pequeñas y medianas empresas con hasta 50 usuarios.
• Sistema de correo propietario (Exchange / Lotus notes), alojado fuera del sitio.
• Población objetivo no técnica.
Estas son empresas medianas cuyo negocio no tiene relación con las nuevas tecnolo-
gías (por ejemplo, pequeñas industrias, obras de construcción e ingeniería civil y autori-
dades locales). El pequeño tamaño de la población permite la delegación de la migración
a los propios usuarios, siempre que se ofrezca alguna capacitación inicial. Pasa a la es-
trategia Light, la misma suele estar motivado por la necesidad de una fase piloto. Esta
fase hace que la migración a la nueva solución sea más fluida, gracias a una política de
gestión de cambios.
• Empresas pequeñas a medianas con hasta 50 usuarios.
• Sistema de correo propietario (Exchange / Lotus Notes) alojado en las instalaciones.
• La mayoría de los usuarios tienen un perfil técnico.
Estas son organizaciones de tamaño mediano con usuarios que, en su mayor parte,
tienen cierta autonomía técnica. En principio, se podría realizar una migración Flash con
un entrenamiento y preparación mínimo. Lo que podría llevar a elegir la estrategia Light
en cambio es la necesidad de una estrategia piloto necesaria para validar la viabilidad
técnica de algunas tareas.
• Empresas medianas de hasta 500 usuarios.
• Hasta tres sitios geográficos.
• Sistema de correo propietario (Exchange / Lotus), alojado en las instalaciones.

Estas son organizaciones de tamaño mediano sin especialización en computación. Tie-

nen varias ubicaciones geográficas y tienen su propio sistema de correo. La ausencia de
habilidades técnicas y el número de usuarios favorecerían en principio el enfoque Light,
lo que implica prepararse para la migración a través de un proyecto piloto y la capacita-
ción de los usuarios. Sin embargo, la adopción de la estrategia Estándar es más probable
porque agrega un servicio de asistencia. La utilización de soporte dedicado en la estra-
tegia standard sigue siendo opcional, sin embargo, porque el número de usuario no es lo
suficientemente grande.
• Empresa mediana con hasta 2.000 usuarios.
• Diez sitios geográficos.
• La población objetivo tiene habilidades técnicas.
Estas son organizaciones de tamaño medio cuya población tiene una buena autono-
mía técnica. Tienen varias ubicaciones geográficas y ejecutan sus propios servidores de
correo. En tal escala, este es el único caso en el que la estrategia DIY todavía es posible,
lo que significa que la capacitación y el soporte al usuario pueden omitirse. Sin embargo,
agregar la fase piloto tiene sentido para validar la viabilidad técnica de algunas tareas
(conexión a un directorio empresarial, por ejemplo).
• Empresa mediana con hasta 2.000 usuarios.
• Diez sitios geográficos.
• Sistema de correo propietario (Exchange / Lotus notes), alojado fuera del sitio.
• La población objetivo no tiene habilidades técnicas.
Estas son organizaciones medianas sin especialización técnica. Tienen varias ubica-
ciones geográficas y tienen sus servidores de correo subcontratados. La estrategia más
razonable es la standard.
• Organizaciones muy grandes con más de 10.000 usuarios.
• Al menos 10 localidades internacionales.
• Servidores de correo propietarios (Exchange / Lotus), alojados en las instalaciones.
• Población objetivo sin habilidades técnicas, en su mayor parte.
• Necesidades avanzadas de integración: SSO, CRM, informes.

Tienen varias ubicaciones y poseen sus servidores de correo. A menudo tienen nece-
sidades avanzadas de integración de las aplicaciones. El enfoque avanzado es la mejor
solución. Sin las necesidades avanzadas de integración, el enfoque standard podría ser
suficiente.
3.4.2 Estrategia 2
La compañía Amazon [29, 33] presenta una planificación y diseño detallado del orden en
que se debe migrar las aplicaciones. Esta fase se divide en 4 partes:
1. Creación de un árbol de dependencias y de una tabla de clasificación.
2. Identificación de buenos “candidatos"para la nube.
3. Mapeo.
4. Creación de una hoja de ruta y de un plan.

1. Creación de un árbol de dependencias y de una tabla de clasificación
Amazon Web Services [33] recomienda empezar con una revisión exhaustiva de las
estructuras lógicas de las aplicaciones, y clasificar dichas aplicaciones de acuerdo con sus
dependencias, riesgos y requisitos de seguridad y conformidad. Para ello, los pasos a
seguir son:
• Identificar las aplicaciones y su dependencia respecto de otros componentes y ser-

vicios.
• Crear un árbol de dependencias que permita visualizar las diferentes partes de las
aplicaciones y sus dependencias hacia arriba y hacia abajo.
• Crear una hoja de cálculo que enumere todas las aplicaciones y las dependencias
o simplemente hacer un árbol de dependencias que refleje los diferentes niveles de
interconexión de los componentes. Este esquema debe proporcionar una imagen
clara de las aplicaciones activas, como se observa en la Figura 3.3.
En esta etapa, se puede clasificar las aplicaciones en diferentes categorías:
– Aplicaciones con acoplamiento fuerte o débil.

– Aplicaciones sensibles / secretas.
– Datos públicos o privados.
2. Identificación de buenos ”candidatos” para la nube

Es aconsejable examinar las dependencias ascendentes y descendentes de cada apli-
cación con el fin de determinar cuáles podrían ser trasladadas a la nube rápidamente.
En la mayoría de los casos, los mejores candidatos para la nube son servicios o com-
ponentes que tienen pocas dependencias ascendentes y descendientes. También se puede
buscar las aplicaciones más infrautilizadas que tengan una necesidad inmediata de esca-
labilidad y poca capacidad, las aplicaciones más flexibles en cuanto a su arquitectura,
etc.
No se debe priorizar las aplicaciones que requieren equipos especializados (por ejem-
plo, la unidad central o equipos especializados en cifrado).
3. Mapeo
Aunque no se suele mencionar, el mapeo es una buena práctica. Para configurar una
plataforma de informática en la nube mediante la adaptación del software existente, es
F IGURA 3.3: Albol de Dependencia [33]
necesario un estudio previo para mapear el SI e identificar los vínculos existentes entre
los servidores, las aplicaciones de back-office, las aplicaciones de front-office, el nivel de
privacidad de los datos, las aplicaciones utilizadas en los escritorios y sus usuarios.
Después de definir lo que va a ser migrado y lo que va a seguir funcionando local-
mente, se puede definir formatos de mensajes entre aplicaciones, y predecir el desarrollo
de los traductores. A continuación hay que asignar los diferentes entornos y sus interac-
ciones, y luego organizar las dependencias [10].
4. Creación de una hoja de ruta y de un plan
Las soluciones a considerar para determinar cómo se deberá construir la plataforma
en la nube serán analizadas con ayuda de una hoja de ruta de migración a la nube. Las
metodologías académicas recomiendan planificar en detalle la migración [20].
3.4.3 Estrategia 3
Los procesos centrales de migración con tareas específicas para definir el modelo de refe-
rencia de migración a la nube son [20]:
• Planificación: estudio de viabilidad, análisis de requisitos de migración, decisión

sobre proveedores, subsistemas que se migrarán, decisión sobre servicios en la nube
y desarrollo de estrategias de migración.
• Ejecución: modificación de código, recuperación de arquitectura, extracción de da-

tos, transformación y adaptación de arquitectura.
• Evaluación: prueba, validación de migración e implementación.
• Consideraciones transversales: gobernanza, análisis de seguridad, entrenamiento,

estimación del esfuerzo, cambio organizacional, análisis de elasticidad y multite-
nancy.
3.4.4 Estrategia 4
En la actualidad, no existe una metodología definida o un estándar internacional acep-
tado para que las organizaciones adopten el modelo de computación en la nube para la
operación de sus infraestructuras de TI.
Cada organización define los requerimientos de integración y estandarización de sus
plataformas y servicios de TI según la visión que tengan sobre su crecimiento. Así, para
la migración de servicios al modelo de nube, las estrategias de migración son específicas
para cada solución, ya que en muchas ocasiones cada migración utiliza una metodología
propia basada en unos requerimientos específicos, que difícilmente se pueden utilizar en
otra migración.
La estrategia propuesta por [11] se construyó de la siguiente manera :
• Análisis
– Determinar cómo la computación en la nube ha de servir para lograr los obje-

tivos de negocio y los objetivos estratégicos.
– Examinar cómo las oportunidades de la computación en la nube se pueden
implementar para incrementar el valor del negocio.
– Socialización del proyecto con la alta gerencia.
– Capacitación al personal del área de TI en el modelo de Nube.
– Análisis financiero.
• Planeación
– Revisión de Infraestructura de HW y SW del centro de datos.

– Análisis de la conectividad de la empresa.
– Determinar cuáles cargas de trabajo (aplicaciones) resultan más adecuadas pa-
ra el despliegue en la nube según su nivel de criticidad.
– Construir la estrategia de migración.
– Selección del tipo de servicio a utilizar (SaaS, PaaS, IaaS).
– Selección del tipo de modelo a usar (Nube Pública, Privada o Hibrida).
• Diseño
– Selección del Data Center.

– Construcción de Acuerdo SLA.
– Diseño de cronograma de migración.
– Diseño de red de datos y conectividad propuesta.
– Diseño del entorno virtualización y recursos requeridos en el Centro de Datos.
• Ejecución
– Adecuación de la red de datos y conectividad.

– Migración de las cargas de trabajo según estrategias de migración.
• Monitoreo
– Pruebas de eficiencia.
– Gestión y medición de servicios recibidos.
3.5 Estrategia de Migración Propuesta

Teniendo en cuenta las estrategias de migración de Google (Estrategia 1) mencionada en
la Sección 3.4, el tipo de estrategia que se adapta al caso de estudio es la Estrategia Light,
ya que el mismo está dentro de lo que es una mediana institución con aproximadamente
500 funcionarios, más de una ubicación geográfica, dispone de personales con dedica-
ción a implementación a nuevas tecnologías y tiene mucha dependencia de los sistemas
informáticos.
Para determinar el orden de migración de las aplicaciones, se tuvo en cuenta lo reco-
mendado por Ámazon Web Services (Estrategia 2), donde se especifica algunos pasos a
seguir, que consiste en la creación de un árbol de dependencias y/o una tabla de clasifi-
cación, posteriormente se debe identificar los buenos “candidatos"para la nube, se realiza
un trabajo de mapeo, y finalmente se crea una hoja de ruta y un plan.
De la Estrategia 3 y Estrategia 4 se tuvo en cuenta las consideraciones generales, téc-
nicas y políticas de las instituciones. Por cada aplicación migrada, se debe considerar la
modificación de código, recuperación de arquitectura, extracción de datos, transforma-
ción y adaptación de arquitectura. Lo que respecta a la Planeación, que consiste en la
revisión de infraestructura de HW y SW, análisis de la conectividad de la empresa, deter-
minar cuáles cargas de trabajo (aplicaciones) resultan más adecuadas para el despliegue
Cloud, selección del tipo de servicio a utilizar (SaaS, PaaS, IaaS), entre otros.
TABLA 3.6: Resumen de Estrategias de Migración Aplicadas al Caso de

Estudio
Estrategia 1 Estrategia 2 Estrategia 3 Estrategia 4

1. Creación de un árbol
de dependencias y de una tabla
de clasificación. 1. Planificación 1. Análisis
1. Estudio
2. Identificación de buenos 2. Ejecución 2. Planeación
2. Prueba piloto
“candidatos"para 3. Evaluación 3. Diseño
3. Formación
la nube 4. Consideraciones 4. Ejecución
4. Migración
3. Mapeo transversales 5. Monitoreo
4. Creación de una
hoja de ruta y de un plan
TABLA 3.7: Extracción de la Estrategias de Migración Propuesta
Estrategia
Estrategia 1 Estrategia 2 Estrategia 3 Estrategia 4
Propuesta
Análisis Estudio - - Análisis
1. Creación de un árbol
de dependencias y de
una tabla de
clasificación
2. Identificación de
Planeación Estudio buenos “candidatos" Planificación Planeación
para la nube
3. Mapeo
4. Creación de una
hoja de ruta y de
un plan
Diseño Estudio - - Diseño
Prueba piloto Prueba piloto - - -
Formación Formación - - -
Migración Migración - Ejecución Ejecución
Evaluación - - Evaluación Monitoreo
Considera- Considera-
ciones - - ciones -
transversales transversales
TABLA 3.8: Estrategia de Migración Propuesta para el Caso de Estudio
Fases Detalles
- Determinar cómo la Computación en la Nube ha de servir para
lograr los objetivos de negocio y los objetivos estratégicos.
- Examinar cómo las oportunidades de la Computación en la Nube
Análisis se pueden implementar para incrementar el valor del negocio.
- Socialización del proyecto con la alta gerencia.
- Capacitación personal del área de TI en el modelo de Nube.
- Análisis financiero.
- Revisión de Infraestructura de HW y SW del centro de datos.
- Análisis de la conectividad de la institución.
- Determinar cuáles cargas de trabajo (aplicaciones) resultan más
adecuadas para el despliegue en la nube.
1. Creación de un árbol de dependencias y de una tabla
de clasificación.
Planeación
2. Identificación de buenos “candidatos"para la nube.
3. Mapeo.
4. Creación de una hoja de ruta y de un plan.
- Selección del tipo de servicio a utilizar (SaaS, PaaS, IaaS).
- Selección del tipo de modelo a usar (Nube Pública, Privada
o Hibrida).
- Selección del Data Center.
- Construcción de Acuerdo SLA.
- Diseño de cronograma de migración.
Diseño
- Diseño de red de datos y conectividad propuesta.
- Diseño del entorno virtualización y recursos requeridos en
el Data Center.
Prueba piloto Prueba piloto para validar la viabilidad técnica.
Formación Formación en materias de migración.
- Adecuación de la red de datos y conectividad.
- Migración de las cargas de trabajo según estrategias
de migración.
Migración 1 - Modificación de código.
2 - Recuperación de arquitectura.
3 - Extracción de datos
4 - Transformación y adaptación de arquitectura.
- Pruebas de eficiencia.
Evaluación
- Gestión y medición de servicios recibidos.
- Gobernanza.
- Análisis de seguridad.
- Entrenamiento.
Consideraciones
- Estimación del esfuerzo.
transversales
- Cambio organizacional.
- Análisis de elasticidad.
- Multitenancy.
En la Tabla 3.8 se presenta la estrategia de migración propuesta para el Caso de Es-

tudio, el mismo se basó en la recopilación y agrupamiento de las cuatros estrategias pre-
sentadas en la Sección 3.4, resumida en la Tabla 3.6 y detallada en la Tabla 3.7.
La estrategia propuesta tiene 8 fases que son: Análisis, Planeación, Diseño, Prueba
F IGURA 3.4: Pasos para la Migración
F IGURA 3.5: Estrategia de Migración Propuesta

Piloto, Formación, Migración, Evaluación y Consideraciones Transversales. Cada una de

estas fases tiene una o varias etapas.
En la Figura 3.4 se observa los pasos a seguir para la migración y en la Figura 3.5
se observa un resumen de dichos pasos. La primera fase consiste en realizar análisis a
nivel gerencial donde se tiene en cuenta los objetivos de negocios y la parte financiera,
en la segunda fase se realiza una planeación técnica para la migración, en la tercera fase
se realiza un diseño de como debería quedar todo el sistema de redes y servidores una
vez migrado, la fase número cuatro consiste en realizar una prueba piloto para validar la
viabilidad técnica de la migración, la quinta fase consiste la la formación de los profesio-
nales TIC de la institución en materias de migración, la sexta fase trata sobre llevar acabo
la tarea de la migración de los sistemas, la septima fase consiste en evaluar la eficiencia
y de los servicios recibidos, y finalmente la octava fase consiste en la consideraciones
transversales en cuanto a la seguridad, estimación de esfuerzo, elasticidad, multitenancy,
etc
3.6 Análisis Financiero

En cuanto a estudio de costes, es difícil de estimar ya que actualmente no existe ningún
método de cálculo estándar, los proyectos de migración varían mucho en función de los
componentes a migrar, de las arquitecturas, de las tecnologías, de los objetivos de la mi-
gración, etc. Esto hace que sea difícil hacer estimaciones empíricas de costes sobre la base
de proyectos parecidos [29].
No existe una vía única para la adopción de la computación en la nube. Las empresas
deben considerar su propia ecuación de costes y beneficios para decidir cuál es el mejor
modelo. Cada aplicación y proceso necesario es una carga de trabajo, y las empresas que
han decidido realizar la transición a la computación en la nube normalmente llevan a
cabo una evaluación exhaustiva de las cargas de trabajo [7].

Para la migración a la nube se debe definir una estrategia de extremo a extremo que tenga
en cuenta los objetivos de la organización. Las migraciones se pueden hacer en SaaS, PaaS
o IaaS, también puede ser que se deba retener o retirar de la infraestructura local.
Las aplicaciones se pueden dividir aproximadamente en tres categorías para la mi-
gración: las aplicaciones que deben permanecer en un entorno informático tradicional, o
aplicaciones especialmente desarrolladas para funcionar en un ambiente de computación
en la nube, y las aplicaciones que se deben adaptar a la nube.
En cuanto a la estrategia de migración, se analizaron cuatro existentes y se notó que
existe enfoques distintos en las estrategias, es decir cada una de las estrategias tienen en
cuenta aspectos que las otras no la tiene.
Se presentó una Estrategia Específica de Migración que consistió en la integración de
las cuatro estrategias estudiadas. La estrategia presentada se adapta al caso de estudio y
la misma está compuesta por ocho fases, cada fase dispone de varios puntos a tener en
cuenta para la migración.
En cuanto a lo financiero, no existe método de calculo estándar para la migración,
cada compañía debe considerar su propia ecuación de costo beneficio.
33
Capítulo 4
Ambiente de Experimentación
En esta sección se presenta las plantillas que deben ser completadas como parte del pro-
ceso de revisión de infraestructura de HW y SW de la institución, mencionada como parte
de las estrategias de migración.
Si bien, en ninguna de las estrategias estudiadas presenta explícitamente las planti-
llas para el uso durante el relevamiento de infraestructura de HW y SW, este trabajo lo
presenta para el uso en el Caso de Estudio. Los relevamientos realizados serán utilizados
para las tomas de decisiones en las estrategias de migración.
4.1 Plantilla sobre Diseño de Red

En la Tabla 4.1 se debe listar los switches disponibles y la zona de cobertura. La tabla
mencionada, junto con el diseño lógico y físico (Figura 4.1), permite visualizar la distri-
bución y la robustez de la red, algo que se deberá tener en cuenta cuando se trabaja en
un ambiente de computación en la nube.
En la Tabla 4.2 se debe especificar los detalles de las redes Wi-Fi, indicando las zonas
de alcance para determinar la cobertura y la marca/modelo, así se podrá tener un pano-
rama general de la red inalámbrica, y ver la posibilidad de incluir controladores locales
o en un entorno de computación en la nube de los mencionados equipos.
En la Tabla 4.3 se debe especificar los detalles de los enrutadores disponibles, en la
misma se debe especificar la velocidad de conexión a internet, estos datos permitirán
determinar si es suficiente dicha velocidad para trabajar en un ambiente de computación
en la nube. Además, la disponibilidad de conexiones con varios proveedores permite
aumentar la disponibilidad de acceso a los sistemas.
Capítulo 4. Ambiente de Experimentación 34
F IGURA 4.1: Plantilla de Diseño Físico y Lógico de la Red

TABLA 4.1: Plantilla para detalles de Switches

TABLA 4.2: Plantilla para detalles de WiFi
TABLA 4.3: Plantilla para detalles de Enrutadores

4.2 Plantilla sobre Detalles de Servidores

En la Tabla 4.4 se presenta la plantilla donde se debe especificar los detalles de recursos
por cada servidor físico que dispone la institución. Esto permitirá dimensionar los recur-
sos utilizados en la infraestructura local, y posteriormente comparar con el ambiente de
computación en la nube.
En la Tabla 4.5 se debe presentar la lista de Servidores Públicos y Privados. La colum-
na Clasificación de dicha tabla se refiere a si el servidor en cuestión es un servidor de Base
de Batos, Balanceadores de Carga, Servidor de Desarrollo, etc. Dependiendo de la clasifi-
cación, los servidores deben ser tratados diferentes en cuanto a los aspectos relacionados
a la seguridad, desempeño, accesibilidad, etc. Los aspectos mencionados se deben tener
en cuenta para la migración a una plataforma de computación en la nube.
En la Tabla 4.6 se debe listar los servidores físicos con los recursos disponibles. Esta
información ayudará a tener una visión global de los recursos disponibles.
En la Tabla de 4.7 se debe especificar las características y los recursos de los Storage
disponibles, para comparar el almacenamiento utilizado en la infraestructura local, y en
el entorno de computación en la nube.
TABLA 4.4: Plantilla para detalles de Servidores

TABLA 4.5: Plantilla para detalles de Servidores Públicos y Privados
TABLA 4.6: Plantilla para detalles de Servidores Físicos
TABLA 4.7: Plantilla para detalles de Storage

4.3 Plantilla sobre Detalles de Sistemas

En la Tabla 4.8, se debe listar los sistemas disponibles, una breve descripción y una cla-
sificación de los mismos, cabe mencionar que varios sistemas pueden estar alojados en
una máquina virtual.
TABLA 4.8: Clasificación de Sistemas
4.4 Plantilla sobre Orden de Migración

En la Tabla 4.9 se debe ordenar los servidores en función a varios criterios, para finalmen-
te obtener un orden de migración.
• Criterio 1: En la columna Dependencias se debe especificar los nombres de los servi-

dores del cual depende el servidor en cuestión, y en la columna Cantidad de Depen-
dencias, la cantidad de estos servidores. Éste es el primer criterio por el cual debe
ser ordenado los servidores a migrar, de menor a mayor.
• Criterio 2: En caso de que haya muchos servidores que tengan la misma cantidad de
dependencias, el siguiente criterio es la Criticidad, esta criticidad debe ser definido
por los administradores de TI de la institución, estableciendo un peso del 1 al 5,
donde 1 es el más crítico. Los servidores se deben ordenar de forma descendente,
utilizando este criterio.
• Criterio 3: En caso de que haya muchos servidores con la misma Cantidad de De-
pendencias, y la misma Criticidad, el siguiente criterio a tener en cuenta es el Tipo de
Migración, se debe migrar en el siguiente orden Retiring, luego IaaS, posteriormente
PaaS, y finalmente SaaS.
• Criterio 4: En caso de que sigue habiendo muchos servidores que tenga la misma
Cantidad de Dependencias, y la misma Criticidad, y el mismo Tipo de Migración, se
puede ordenar aleatoriamente.
TABLA 4.9: Plantilla Orden de Migración


Las plantillas presentadas facilitará el proceso de migración, ya que los mismos podrán
ser utilizados para cargar los datos relevados para su posterior análisis.
Cada plantilla presentada permite visualizar los recursos de la institución desde dis-
tintas perspectivas, y además de utilizar para el proceso de migración, podrá ser utilizado
para disponer de los registros de recursos disponibles en la institución.
En cuanto a la plantilla para determinar el orden de migración, se tubo en cuenta
cuatro criterios que son: Cantidad de Dependencia, Criticidad, Tipos de Migración y de
forma aleatoria.
42
Capítulo 5
Caso de Estudio
En este capítulo se presenta la fase de Planeación de la Estrategia propuesta para el caso

de estudio, que consiste en la evaluación de la infraestructura de HW, SW, conectivi-
dad, sistemas, entre otros. Para recabar datos de los recursos disponibles se utilizarán las
plantillas presentadas en la sección 4 (Algunas columnas de dichas planillas no se relle-
narán con los datos reales por cuestiones de confidencialidad). Se propone un orden de
migración a la nube ya que en la literatura no se especificaron los pasos a seguir para
determinar dicho orden.
5.1 Planeación de Migración

A continuación se presenta la fase de Planeación del modelo propuesto, aplicado a la
FP-UNA:
• Revisión de Infraestructura de HW y SW del centro de datos.

- En la Figura 5.1 se puede observar los servidores que están operativos, y la inter-
conexión de los mismos. En la sección 5.2.3 se observa los detalles de las máquinas
virtuales disponibles.
• Análisis de la conectividad de la institución.
- En la Figura 5.2 se puede observar el diseño físico de la red, y en la Figura 5.3 se
refleja la interconexión lógica de la misma.
• Determinar cuáles cargas de trabajo (aplicaciones) resultan más adecuadas para el
despliegue en la nube.
- El orden de migración de las aplicaciones según varios criterios tomados, se deta-
lla en la sección 5.3.
• Selección del tipo de servicio a utilizar (SaaS, PaaS, IaaS).
- El tipo de servicio a utilizar varía de acuerdo al sistema a ser migrado, la misma
se detalla junto con la lista servicios que se puede observar en la sección 5.3 .
• Selección del tipo de modelo a usar (Nube Pública, Privada o Híbrida).
- El modelo de nube a utilizar debe ser una nube híbrida, ya que es la que mejor se
adapta para la institución.
5.2 Estado Actual

En esta sección se brinda información detallada, unificada y ordenada del Stack Tecnoló-
gico con el que cuenta actualmente la FP-UNA, todos los recursos de hardware, software,
conectividad, la capacidad de operación y algunas métricas actuales de uso.
Capítulo 5. Caso de Estudio 43
5.2.1 Detalle de la Capa Física

Los detalles de la capa física incluyen: Procesador, Capacidad de Almacenamiento In-
terno, memoria RAM y Almacenamiento Masivo (Storage).
La totalidad de los cómputos asociados a los servicios que ofrece la FP-UNA se en-
cuentran distribuidos en 6 servidores físicos (cuatro Rackeables y dos de tipo Torre), la
interconexión se puede observar en la Figura 5.1. Un servidor rackeable Dell Power Edge
R920 se encuentra conectado a un Storage DELL, vía un SAN Switch Brocade, otro servi-
dor rackeable de marca Dell Power Edge R720 conectado directamente a un Storage IBM.
Éstos son los dos servidores principales. También se dispone de otros cuatro servidores
legados, una de marca SAN, otro de marca DELL y otros dos servidores IBM, éstos funcio-
nan con almacenamiento interno. Por cuestiones de seguridad y flexibilidad, los sistemas
alojados en estos servidores legados se están migrando gradualmente a los servidores
principales.
Las conexiones a los servidores principales se realizan mediante enlaces troncales,
esto permite aumentar la flexibilidad en las configuraciones de los servidores. Los servi-
dores legados están conectados directamente a la VLAN de servidores.
La velocidad de conexión entre switches y entre switch core y los servidores de es
1 Gbps con cable de cobre UTP CAT 6. La velocidad entre el servidor DELL R920-SAN
Switch y SAN Switch-Storage es de 8 Gbps mediante fibras monomodo, y la conexión
entre el Servidor DELL R720 y el Storage IBM es de 5 Gbps mediante cable SAS.
La conexión entre el Switch Core y los switches de acceso utilizan tanto cable de fibra
(monomodo y multimodo) y también cable de cobre CAT 5E. Los enlaces de fibra utilizan
tranceiver de 100 Mbps y también de 1 Gbps de velocidad.
Switch Core Storage IBM
5 Gbps
Switch de Switch de
Acceso Servidores Servidor DELL R910
Servidor DELL R920
8 Gbps
Fibra Monomodo
Cable SAS
SAN Switch Brocade
Cable RJ45
Enlace Troncal
Storage DELL
Servidor DELL T710
Servidor SunFire V20Z
Servidor IBM Servidor IBM
F IGURA 5.1: Interconexión de Servidores

5.2.2 Detalle de Redes

La capa de redes incluye: Arquitectura, Gestión, Proveedor, Ancho de Banda. Se dispone
oficialmente de cuatros proveedores de Internet, los mismos se detallan a en la Tabla 5.1,
en dicha figura se puede observar que la cantidad total de ancho de banda disponible es
de 68 Mbps. La interconexión física de estos proveedores a los equipos de la FP-UNA se
realiza vía el Switch Core, como se observa en la Figura 5.2.
TABLA 5.1: Proveedores de Internet
Cabe mencionar que toda la red esta segmentada por VLAN (Figura 5.3) donde existe
una VLAN exclusiva para los servidores.
La FP-UNA no cuenta con ASN (Número de Sistema Autónomo), por lo que el pro-
veedor de IP pública es el CNC, se dispone de treinta IPs (200.10.229.189/27).
En las Tablas 5.2 y 5.3 se puede observar los recursos y las particiones de discos de los
dos servidores principales de la institución. En cuanto al Servidor 01, se observa el uso
del 83 % del almacenamiento, distribuido en todas las particiones. En cuanto al Servidor
02, se observa una disponibilidad mayor de recursos, uso del 43 % del espacio disponible.
En la Tabla 5.4 se observa los detalles de los siete enrutadores disponibles. En la mis-
ma se observa los siguiente:
• Dos enrutadores son del tipo virtual, los mismos se encuentran alojados en los ser-
vidores.
• Uno de los enrutadores es una PC configurado como enrutador.
• Tres de los enrutadores son switches de capa tres, configurados con las funcionali-
dades de ruteo.
• Uno de los enrutadores es un equipo fabricado especial como enrutador.
En la Tabla 5.5 se puede observar la lista de los veinte switches disponibles en la insti-
tución. En la misma se puede notar la existencia de gran variedad de marcas y modelos,
así también se observa la distribución geográfica equitativa de los mismos.
En la Tabla 5.6 se observa los dos equipos de almacenamiento masivo disponible en
la institución. En la misma se puede observar que los almacenamientos de estos equipos
son de 12 TB y 24 TB respectivamente.
En la Tabla 5.7 se presenta el listado de las señales inalámbrica disponibles en la ins-
titución. En la misma se observa la distribución en todos los bloques, indicando la zona
de alcance, además, se observa la existencia de una gran variedad de marcas de estos
equipos.
En la Figura 5.2 se presenta el diseño físico de la red, en la misma se observa la existen-
cia de los cuatros proveedores de internet, los mismos están conectados al Switch Core,
para luego distribuir la señal a los usuarios mediante los switches de acceso.
En la Figura 5.3, se presenta el diseño lógico de la red, en la misma se observa la
conexión lógica entre los switches y enrutadores, pudiendo notar que los enlaces lógicos
entre switches son VLAN configurados en modo Trunk (troncal), de la misma manera, los
enlaces troncales son conectados a algunas de las máquinas virtuales. Cabe mencionar
que las conexiones a las terminales se realizan mediante VLAN en modo Access.
En la Figura 5.4 se presenta el diseño de dos enrutadores virtuales Multi-WAN exis-
tente, que funcionan en modo Maestro - Esclavo, estando en equipos hardware distintos.
La virtualización permite aumentar o disminuir la asignación de recursos de acuerdo a
la necesidad, y también la copia de respaldo de la máquina virtual completa. La configu-
ración Multi-WAN permite el balanceo de carga entre los proveedores, haciendo posible
la continuidad de servicios a los usuarios en caso de algún inconveniente con uno de los
proveedores. El modo Maestro-Eslavo entre las máquinas virtuales hace posible que en
caso de algún problema con el Máster, tome el control el Esclavo. Y finalmente, el hecho
de estar en equipos HW distintos, hace posible que en caso de falla de HW donde se aloja
el Máster, igual pueda seguir ofreciendo el servicio mediante el Esclavo.
En la Figura 5.5 se observa la virtualización de un controlador Wi-Fi para equipos de
la marca UniFi. Este controlador hace posible el manejo centralizado de los equipos de
esta marca, en especial del modelo Ubiquiti, de esta manera se flexibiliza los cambios de
configuraciones de todos los equipos de la marca y modelo mencionado.
TABLA 5.2: Servidor 01

TABLA 5.3: Servidor 02
TABLA 5.4: Enrutadores

TABLA 5.5: Switches
TABLA 5.6: Storage

TABLA 5.7: Wi-Fi
Wi-Fi
Nro Bloque SSID Zona de alcance Dispositivo
1 A SSID 1 Policopias Ubiquiti-Unifi Plato
2 A SSID 2 Cantina Ubiquiti-Unifi Plato
3 A SSID 3 PA - Zona Aula Magna TP-Link
4 A SSID 4 PB - Helipuerto
5 A SSID 5 PA - Nubia TP-LINK TL-WA901ND
6 B SSID 6 PB TP-Link
7 B SSID 7 Of. Decano TP-LINK TL-WR841N
8 B SSID 8 PA
9 B SSID 9 Aula-Magna Mikrotik
10 B SSID 10 Aula Magna Ubiquiti Nano Loco 2
11 C SSID 11 Aula-Magna D-LINK
12 C SSID 12 Bloque B, Caminero y Estac.
13 C SSID 13 Sala de post grado 2 Ubiquiti Unifi (Plato)
14 C SSID 14 Pregrado - Admisión PLANET WRT-416
15 C SSID 15 Pasillo TPLINK TL-WR841N
16 C SSID 16 Sala de Prof. TPLINK TL-WR1043ND
17 C SSID 17 Secretaría Planet
18 E SSID 18 Oficina DECI TP-Link
19 E SSID 19 Rack BC - Helipuerto Cisco Linksys
20 D SSID 20 Techo Ubiquiti Bullet M2
21 D SSID 21 Ofi. Lidu TP-LINK
22 D SSID 22 Clase IDIOMATICA . Planta Baja
23 D SSID 23 Biblioteca - Area de estudio Ubiquiti Nano Loco 2
24 D SSID 24 Startuplab TP-Link
25 D SSID 25 PA - Sala de conferencias TP-Link
26 D SSID 26 PB - American Corner
27 D SSID 27 Bloque D (Ing. Biomedica-Inv) DLINK-AP
28 E SSID 28 Bloque D Planta alta -Pasillo Ubiquiti Unifi LR (Plato)
29 E SSID 29 BLOQUE D Planta Baja Ubiquiti Unifi (Plato)
30 E SSID 30 GIEM D-Link DIR-320
31 E SSID 31 GIEM Kaiomy AP router - Level ONE
32 E SSID 32 Postgrado D-Link DIR-615
33 E SSID 33 Bloque D PB. Ofic. de Planific. D-Link-DIR 615
34 E SSID 34 Oficina de Gerardo Blanco
35 F SSID 35 Rack Bloque E Mikrotik
36 F SSID 36 Rack Bloque E Mikrotik
37 F SSID 37 Bloque E: Aulas de Cursillo Microtik 2011UiAS-2HnD
38 F SSID 38 Bloque E: Aulas de Cursillo Microtik 2011UiAS-2HnD
39 F SSID 39 F27 Mikrotik
40 F SSID 40 F27 Mikrotik
41 F SSID 41 Techo Ubiquiti Bullet M2
42 F SSID 42 PB UBIQUITI Plato
43 G SSID 43 PA UBIQUITI Plato
44 G SSID 44 PA Elearning TPLINK TL-WR841N
45 G SSID 45 E - Learning Microtik 2011UiAS-2HnD
46 G SSID 46 NOC TP-LINK AC1750
48 G SSID 48 Pasillo
50 G SSID 50 Rack - E-Learning
51 G SSID 51 Bloque F-PA TP-Link TL-WR841HP
52 H SSID 52 BFPA - Dir. de Carrera IIN TP-LINK
53 H SSID 53 CIA Mikrotik
54 H SSID 54 Rack-CIA Planet WRT-416
55 H SSID 55 Piso TPLINK TL-WR841N
56 H SSID 56 Direc. Electricidad y Electrónica TPLINK TL-WA701N
57 H SSID 57 CIA Ubiquiti NS Loco M2
58 H SSID 58 CIA CISCO - RV192W
59 H SSID 59 Bloque G 2 piso
60 J SSID 60 Bloque G -Algoritmo Ubiquiti Unifi (Plato)
61 J SSID 61 Bloque G 2 piso (ala norte) Ubiquiti Unifi (Plato)
62 J SSID 62 Bloque G 2 piso (ala sur)
63 J SSID 63 Bloque H
66 J SSID 66 Bloque H - Repetidor de wifi-met-fp Tp-LINK AC7
67 J SSID 67 Meteorologia 3COM wl-537
CNC Personal Tigo Claro
Proveedores de Internet
Switch Core
Switches
de
Acceso
F IGURA 5.2: Diseño Físico de Red

Enrutador Virtual
Switch Core
Switch de
Acceso
Switch de
Servidores
Enlace Troncal
VLAN
F IGURA 5.3: Diseño Lógico de Red

Enrutador Virtual con

Balanceador de Carga
Switch Core
Switch de Switch de
Acceso Servidores
VLAN 4 – CNC
VLAN 253 – Personal
VLAN 254 – Tigo
VLAN 255 – Claro
VLAN 56 – LAN HA
VLAN 58 – Pfsync
Enlace Troncal
F IGURA 5.4: Enrutadores virtuales con Balanceador de Carga

Switch de Acceso
Switch Core
Controlador Wireless
(Virtual)
VLAN 4 – CNC
VLAN 253 – Personal
VLAN 254 – Tigo Switch de Servidor Físico
VLAN 255 – Claro Servidores
VLAN 56 – LAN HA
VLAN 58 – Pfsync
Enlace Troncal
F IGURA 5.5: Controlador Wi-Fi

5.2.3 Detalles de Sistemas

En la Tabla 5.8 se puede observar la lista de servicios ofrecidos por la FP-UNA, junto con
la clasificación de los mismos. Los sistemas más críticos son los servicios públicos, entre
los cuales están el sistema de Inscripción, la plataforma E-Learning y el portal de la ins-
titución. En la institución también se dispone de Sistemas de Gestión de Bases de Datos,
Balanceadores de Cargas, repositorios de códigos de sistemas, servidores de backup de
base de datos y configuraciones, sistema analizador de logs de base de datos, etc.
TABLA 5.8: Clasificación de Sistemas
En la Tabla 5.9 se lista los sistemas operativos utilizados, en la misma se observa que
90.8 % de los sistemas están instalados en sistemas operativos Linux Server, el 3.45 % en
Windows Server, y el 5.75 % en Pfsense.
TABLA 5.9: Sistemas Operativos

5.2.4 Diagramas de uso y consumo de las aplicaciones críticas

En las Figuras 5.6, 5.7 y 5.8 se observa el uso de tres sistemas más críticos de la institución.
El sistema de inscripción se utiliza masivamente en ciertas épocas, alcanzando un pico
de más de 40.000 visitas en un solo día, sin embargo, el Sistema E-Learning y el Portal
se utiliza durante todo el año alcanzando un tope de acceso en el día de 448 y 33.744
respectivamente.
F IGURA 5.6: Estadística de uso del Sistema Educa
F IGURA 5.7: Estadística de uso del Portal

F IGURA 5.8: Estadística del Sistema de Inscripción

5.3 Orden de migración a entorno de computación en la nube

El orden se determinó de acuerdo a los niveles de dependencias, los niveles de criticidad
y el tipo de migración, como se detalla en la Sección 4.4. A continuación se presenta la
lógica utilizada para la migración.
1. Inicialmente los servidores que no están en uso, deben ser retirados.
2. Posteriormente se debe migrar los servidores teniendo en cuenta la cantidad de

dependencias (de menor a mayor), la criticidad (de menor a mayor) y el Tipo de
Migración (IaaS, posteriormente PaaS, y finalmente SaaS.).
3. En caso de que haya servidores con la misma cantidad de dependencia, la misma

criticidad, y el mismo Tipo de Migración, se puede elegir el servidor de forma alea-
toria.

Para el caso de estudio se presentó la fase de planeación de la estrategia de migración pro-
puesta. Para recabar datos de recursos disponibles se utilizó las plantillas presentadas en
la sección 4, disponiendo de esta forma una visión global del estado de la infraestructura
local.
59
Capítulo 6
Resultados
En esta sección se presenta parte de los resultados de la propuesta de migración aplicada

al caso de estudio. Se presenta una estadística de dependencia de los sistemas, la criti-
cidad de los mismos, y del tipo de migración aplicada a cada una de ellas. Además se
presenta el orden en que los servidores deben ser migrados, siguiendo lo propuesto en la
sección 5.3. Finalmente, se realiza una estimación de inversión utilizando la calculadora
de Ámazon Web Services.
6.1 Estadística de Migración
F IGURA 6.1: Dependencias de Servicios
El análisis de la dependencia entre servicios es uno de los parámetros que define el

orden de la migración. En la Figura 6.1 se observa las cantidades de servicios con las
dependencias correspondientes. El 69,318 % de los servicios están sin dependencia, el
13,636 % con una dependencia, el 15,909 % con dos dependencias, y finalmente el 1,136 %
con nueve dependencias.
El segundo parámetro que define el orden de migración es la criticidad de los servi-
cios. En la Figura 6.2 se observa los niveles de criticidad, definido del 1 (uno) al 5 (cinco),
donde 1 es de mayor prioridad. El 40,91 % de los sistemas son de alta prioridad (1), el
Capítulo 6. Resultados 60
F IGURA 6.2: Criticidad de Servicios
TABLA 6.1: Estadística de Tipo de Migración
Estadística de Tipos de Migración

Tipo de Migración Cantidad
SaaS 3
IaaS 27
IaaS –>SaaS 28
Retain 11
Retiring 19
Retiring (Apagados) 59
Total 147
F IGURA 6.3: Gráfica de Tipo de Migración
9,09 % son de prioridad 2, el 14,77 % de prioridad 3, el 13,64 % de prioridad 4 y 21,59 %

de menor prioridad (5).
En la Tabla 6.1 se resume las cantidades de sistemas que se debe migrar por tipo de
migración. Como se observa, 3 de debe migrar directo a SaaS, 27 se migra directo a IaaS,
28 se debe migrar a IaaS y paulatinamente a SaaS, 11 deben ser retenidos y 78 deben ser
retirados.
En la Figura 6.3 se observa que gran porcentaje de los servidores deben ser retirados,
lo que significa que antes de realizar la migración ya se puede hacer mejor uso de los
recursos, gracias al análisis de los estados de los servicios.
A continuación se presenta la lista de servidores ordenados por los criterios mencio-
nados:
Tabla 6.2: Lista de Servidores Ordenados
INFORMACIÓN DETALLADA DE SERVIDORES
ORDEN DE MIGRACIÓN
Nro.
de
Nombre Espacio Total Total Descrip Tipo de
Estado SO En caso de Migración a Cloud Dependencias Depen Criticidad
VM GB RAM CPUs ción Migración
denci
a
VM1 46 4 2 Apagado Se retira, ya no está en uso Retiring - - -
Linux
VM60 14 2 1 ejecutando Se retira, ya no está en uso Retiring X 0 5
Debian 9
Linux
VM61 220 8 4 ejecutando CentOS Se retira, ya no está en uso Retiring X 0 5
7.4
Linux
Se puede migrar a servidor de aplicación
VM62 220 8 4 ejecutando CentOS Retiring X 0 5
nativa para la nube
7.4
Linux
7.4
Linux
7.4
Linux
7.4
Linux
7.4
Linux
VM67 30 2 1 Corriendo CentOS Se retira, ya no está en uso Retiring X 0 5
7.4
Linux
VM68 51 4 1 Apagado CentOS Se retira, ya no está en uso Retiring X 0 5
6.7
Linux
6.6
Linux
6.7
Linux
6.7
Linux
VM72 20 4 1 Corriendo Ubuntu Se retira, ya no está en uso Retiring X 0 5
12.0
Linux
6.7
Linux
6.7
Linux
6.7
Linux
6.7
Linux
VM77 955 4 2 Corriendo Se retira, ya no está en uso Retiring X 0 5
openSUSE
Linux
7.4
Sistema para administración local de
Linux
VM79 8 1 1 ejecutando despliegue de noticias en varios Retain X 0 4
Debian 8
monitores
Linux
Migración IaaS. Sitema monolítico. En una
VM80 20 4 4 ejecutando CentOS IaaS --> SaaS X 0 4
segunda etapa se podría migrar a SaaS
7.4
Linux
Se debe migrar como IaaS, ya que tiene
configuraciones específicas
6.8
Linux
Se debe migrar a IaaS y posteriormente a
VM82 50 4 1 Corriendo Ubuntu IaaS --> SaaS X 0 4
SaaS
12.04
Debian Migración IaaS, el sistema dispone
VM83 500 4 2 Corriendo GNU/Linu configuraciones específicas. En una IaaS --> SaaS X 0 4
x7 segunda etapa se podría migrar a SaaS
Linux
VM84 17 2 1 Corriendo CentOS IaaS X 0 4
7.4
Linux
Buscar plataforma nativas para
VM85 50 4 4 Corriendo Ubuntu IaaS X 0 4
evaluación de código fuente
12.0.4
Linux
Usar servidor de aplicación nativa de
VM86 20 2 1 Corriendo Ubuntu IaaS X 0 4
cloud, solo usa APACHE Y MySQL
14.04
Linux
Se debe migrar como IaaS, tiene
7.4
Linux Se puede migrar a servidor de aplicación
VM88 200 1 1 Corriendo Ubuntu nativa para la nube como Drive, SaaS X 0 4
14.04 OneDrive, Drobox, etc
Linux Se debe migrar inicialmente a IaaS, por la
VM89 500 20 10 ejecutando CentOS cantidad de contenido, y gradualmente a IaaS --> SaaS x 0 3
7.4 SaaS
Linux
6.8
Linux Migración IaaS, el sistema dispone
VM91 50 8 6 Corriendo CentOS configuraciones específicas. En una IaaS --> SaaS X 0 3
6.6 segunda etapa se podría migrar a SaaS
Linux
VM92 10 2 2 ejecutando CentOS IaaS X 0 3
7.4
Linux
7.4
Linux
7.4
Linux
6.6
Linux
Migrar como IaaS, el sistema dispone de
6.7
Se debe mantener localmente. Provee
servicio de envío de correo para los
Linux
sitemas de monitoreo. En una segunda
VM97 30 1 1 ejecutando Ubuntu SaaS X 0 2
etapa se podría utilizar un correo
12.0
electrónico en la nube, para los sistemas
de monitoreo
FreeBSD Debe permanecer local debido a que
VM98 20 4 4 ejecutando Retain X 0 2
PFsense ofrece servicio proxy a la red interna
Windows
Sistema para administración local de
VM99 600 6 4 ejecutando Server Retain X 0 2
sistema antivirus
2008 R2
Linux
VM100 50 2 1 ejecutando CentOS Retain X 0 2
servicio de monitoreo a la red interna
7.4
FreeBSD Se debe mantener localmente. Provee
PFsense servicio de VPN a la red interna
Linux Debe permanecer local debido a que
VM102 30 2 1 Corriendo CentOS ofrece servicio de monitoreo interno de la Retain X 0 2
6.9 red y los servidores
Windows
Inicialmente se debe migrar a IaaS, y
VM103 2 4 2 ejecutando Server IaaS --> PaaS X 0 2
luego pasar a PaaS
2008 R2
PFsense balancea trafico de red
Linux
Se debe mantener localmente.
VM105 20 6 6 ejecutando Ubuntu Retain X 0 1
Controlador de sistema Wi-Fi
14.04
VM106 200 8 4 ejecutandoLinux ClearOS Retain x 0 1
servicio de Proxy a la red interna
FreeBSD Se debe mantener localmente. Provee
PFsense servicio DHCP a la red interna
VM108 7 4 4 Corriendo Retain X 0 1
PFsense balancea trafico de red
Linux
posteriormente a SaaS
7.4
Linux
posteriormente a SaaS
7.4
6.2 Estimación de Inversión

Haciendo una estimación de inversión en la calculadora de AWS, se concluye que con
todos los sistemas que dispone la FP-UNA, se podría ahorrar el 81 % moviendo de una
infraestructura tradicional a AWS. Cabe mencionar que esta infraestructura tradicional
debe cumplir ciertos requerimientos (aproximado a TIER III) para que sea comparable
con la infraestructura de AWS. A continuación se presenta las metodologías de cálculo y
las suposiciones.
F IGURA 6.4: AWS - Total Cost of Ownership (TCO) Comparison
6.2.1 Metodología de Cálculo

La calculadora de TCO de AWS utiliza la siguiente metodología para calcular los costos
on-premises y de AWS.
La metodología de AWS define el costo total de propiedad (TCO) como se muestra a
continuación:
TCO = Costos de adquisición + Costos operacionales
Los costos operativos incluyen el costo de mano de obra para administrar las opera-
ciones del centro de datos, así como los costos generales asociados con la ejecución del
equipo del centro de datos. Se utiliza un marco de tiempo estándar de 3 años para los
cálculos como la vida útil del equipo del centro de datos.
En la siguiente Figura 6.5 se observa las principales categorías de costos en entornos
on-premises.
On-Premises TCO = Costos del servidor + Costos de almacenamiento + Costos de red
+ Costes laborales de TI
Para entornos on-premises, los costos principales (servidor, almacenamiento y red)
incluye el costo de hardware, software (donde corresponda) y costos generales. Los cos-
tos generales incluyen el costo del espacio del centro de datos, la energía y la refrigeración
de los equipos de centro de datos. Para los cálculos, de un rack estándar se considera el
rack típico de 19 pulgadas que tiene un rack de 28 pies cuadrados en el centro de datos.
F IGURA 6.5: Calculo de Costo
Además, se asume que la densidad de potencia promedio por rack es de 10 kW en un

centro de datos local y un gabinete que tiene un circuito monofásico primario de 20 am-
perios, 120V y un circuito redundante de 20 amperios y 120 V. Se utiliza el modelo de
costos de Uptime Institute para calcular los costos generales de una oferta de precio local
y pública disponible de un proveedor de servicios de infraestructura de TI administrada,
interconexión y administrada global. Como los gastos de energía y refrigeración se factu-
ran mensualmente, se calcula los costos generales mensualmente. También se utiliza un
rack estándar como punto común para calcular los gastos generales.
En la Figura 6.6 se observa la lógica por la cual se calcula el costo general para los
entornos locales.
Con AWS (Figura 6.7) se incluye los costos de soporte de nivel empresarial de AWS.
El soporte de nivel empresarial de AWS incluye orientación para optimizar los productos
y la configuración de AWS para satisfacer sus necesidades específicas. El soporte a nivel
empresarial proporciona descuentos a medida que crece su uso de AWS
6.2.2 Suposiciones
La calculadora de TCO de AWS realiza las siguientes suposiciones para entornos locales
y de AWS.
Suposiciones On-Premises
1. Servidores y Racks:
• Los precios de los servidores se basan en los servidores Dell PowerEdge y los ser-
vidores HP ProLiant.
• Los servidores pueden ser físicos o virtualizados. Actualmente, la herramienta es

compatible con los hipervisores VMware vSphere, KVM y Xen.
• Para entornos virtualizados, se admiten dos configuraciones de host de virtualiza-

ción:
F IGURA 6.6: Calculo de costos de On-premises
F IGURA 6.7: Comparación de AWS y Vendedores de HW
– Host 1 - 2 procesadores con 8 núcleos cada uno y 96 GB de RAM.

– Host 2 - 4 procesadores con 8 núcleos cada uno y 256 GB de RAM
• La densidad de las máquinas virtuales se calcula en función de la RAM virtual y

los núcleos virtuales asignados a las máquinas virtuales.
• El hardware del servidor y del rack tiene un descuento del 25 % en los precios de
lista disponibles al público.
• Se considera un rack estándar de 19 pulgadas y 42U.
• En promedio, cada rack se llena hasta el 75 % de la capacidad (es decir, para un rack
de 42U, en realidad se usa 32U).
• El rack para el Dell PowerEdge Energy Smart 4620S se usa para mantener el equipo
del centro de datos con un precio base de $ 3,499.
• Cada rack consta de dos interruptores (ToR) de la parte superior del rack para re-
dundancia de switches Cisco Catalyst 2960 de 48 puertos, utilizado en cálculos con
la siguiente configuración: 48 x 10/100/1000 - PoE + 525Watt + 4 x SFP, Base LAN
Capa 2.
• Cada rack consta de 2 unidades de distribución de alimentación (PDU) para una
alta disponibilidad. APC Metered Rack PDU con un precio base de $ 545.
• Un 15 % de mantenimiento de hardware / año aplicado al servidor y al hardware
de rack.
• 5 % de toda la capacidad del servidor se asume como repuesto. Un repuesto diná-
mico o un modo de espera activo se utiliza como mecanismo de conmutación por
error para proporcionar confiabilidad y alta disponibilidad en entornos de centros
de datos.
2. Software
• Se asumieron las licencias de VMware vSphere Enterprise Plus para los clientes que
utilizan entornos VMware. Un precio base de $ 3,495 por licencias y $ 874 por 1 año
de soporte y suscripción asumidos
• KVM es un software gratuito publicado bajo la licencia GPL. Los proveedores co-
mo RedHat ofrecen el hipervisor KVM bajo un modelo de suscripción que incluye
acceso al producto y todas las actualizaciones y soporte.
• El hipervisor Xen está cubierto por la licencia pública GNU y está disponible de
forma gratuita. Los proveedores como Citrix ofrecen una versión gratuita y de pago
de XenServer.
• Las licencias y el mantenimiento del software se descuentan en un 25 % de los pre-
cios de lista disponibles al público.
• Las distribuciones de Linux utilizadas en el modelo están disponibles de forma
gratuita. El modelo no utiliza las distribuciones de pago de Linux como SUSE En-
terprise Linux y Red Hat Enterprise Linux.
3. Storage
• Los fabricantes de discos duros miden la capacidad de la unidad de forma diferente

a los sistemas operativos. Los fabricantes de discos duros usan una medida "base
10", mientras que los sistemas operativos usan una medida "base 2". Este desajuste
provoca una penalización del 7 % en la capacidad del disco.
• La capacidad sin procesar se define como la capacidad del disco en la caja, mientras
que la capacidad utilizable es la capacidad del disco después de la protección RAID
y está disponible para la asignación del host.
• Se asume precio promedio de los dispositivos de estado sólido (SSD) y unidades de

disco duro (HDD) por GB. En el modelo asume precios más altos, ya que se incluye
el precio de los adaptadores de bus de host (HBA), los adaptadores de canal de fibra
óptica, los cables de canal de fibra óptica y otros equipos de almacenamiento.
• Se aplica un descuento del 50 % de forma predeterminada al precio de SSD y HDD

por GB.
• El modelo asume que un administrador de almacenamiento maneja 1000 TB de

datos anualmente.
• El modelo asume que un solo rack de almacenamiento contiene 1000 TB de discos.
• El modelo asume cintas LTO-5 utilizadas para copias de seguridad.
• Un precio base de $1800 / unidad asumido para el costo de la unidad LTO-5 que
toma cintas de hasta 1,5 TB de capacidad verdadera (sin comprimir).
4. Network
• El modelo supone una sobrecarga de red del 20 % para los entornos locales. La
sobrecarga de la red se calcula tomando una sobrecarga del 20 % en el costo del
hardware del servidor y del rack.
• El tráfico en el centro de datos se supone que es tanto de norte a sur (entre servi-
dores dentro del centro de datos y puntos finales fuera del centro de datos) como
de este a oeste (entre componentes en el centro de datos). El modelo supone que el
80 % de todo el tráfico del centro de datos es “este-oeste”.
• Para el entorno on-premises, los costos de ancho de banda también incluyen el costo
de los optimizadores de WAN y la VPN de MPLS.
• El precio promedio del ancho de banda de colocación está escalonado: el modelo

supone $ 30 / Mbps en el nivel más bajo y $ 7 / Mbps en el nivel más alto.
• El esfuerzo promedio de administración de la red es de alrededor del 8 % del es-

fuerzo total de administración de TI.
5. Potencia y enfriamiento.
• Se utiliza un precio promedio de la electricidad en Estados Unidos.
• Se considera el promedio en centavos por kilovatio-hora en el segmento comercial

de EE. UU, en enero de 2014 fue de 10.34 centavos.
• El modelo asume un PUE (Power Usage Effectiveness) estándar para on-premises

/ colocation de 1.5 y un precio base de kWh (kilo vatios hora) de 10 centavos por
hora. Esto nos da un cargo de electricidad de 15 centavos por kWh (10 * 1.5).
6. Espacio del centro de datos

• El modelo asume que los proveedores de colocación cobran una tarifa fija de $ por
kW que cubre el costo de toda la energía y el espacio contratado. Se supone que
cada rack tiene una fuente de alimentación primaria y redundante.
• El modelo supone un cargo separado por espacio, energía y refrigeración para en-
tornos on-premise.
7. IT Labor
• Se tiene en cuenta los salarios promedio de los administradores de centros de datos

de la región.
Suposiciones de AWS
1. Computo
• Por demanda e instancias reservadas a 3 años, utilizada para el cálculo de AWS.
• Las instancias de EC2 se combinan con servidores on-premises y máquinas virtua-

les basadas en CPU, RAM o almacenamiento.
• La cantidad de instancias de EC2 es la misma que la de los servidores físicos o las

máquinas virtuales locales, lo que significa que no aplicamos ninguna optimización
de costos en el lado de AWS. En situaciones de la vida real, los clientes cambiarían el
tamaño de las instancias en función de la supervisión de varias métricas de recursos
de AWS, como la utilización de la CPU, la memoria libre o el uso del disco.
• Amazon EC2 proporciona una amplia selección de tipos de instancia optimizados

para adaptarse a diferentes casos de uso. El modelo utiliza instancias de propósito
general, computación optimizada, memoria optimizada y almacenamiento optimi-
zado.
• El modelo utiliza solo la generación actual de instancias: propósito general (m3),

computación optimizada (c3), memoria optimizada (R3) y almacenamiento optimi-
zado (I2).
• La generación actual de instancias proporciona procesadores Intel Ivy Bridge más

rápidos y nuevos, almacenamiento de instancias basado en SSD, redes mejoradas
de mayor rendimiento y funciones avanzadas, como compatibilidad con AMI de
HVM.
• El modelo asume los descuentos por volumen de instancia reservada.
2. Almacenamiento
• Los sistemas de almacenamiento SAN y NAS en On-premises están representados

en AWS como volúmenes EBS.
• El almacenamiento de objetos On-premises se representa en AWS como S3.
• S3 ofrece múltiples clases de almacenamiento: S3 Standard, RRS y Glacier, según la

forma en que S3 maneje los datos. El modelo asume solamente el estándar S3.
• El modelo asume RAID 0 para volúmenes EBS.
• Se pueden dividir varios volúmenes de EBS para lograr hasta 48,000 IOPS cuando
se adjuntan a instancias de EC2 más grandes.
• El % de copia de seguridad / mes es la cantidad de datos que cambia cada mes.

Entonces, un 50 % significa que el 50 % de los datos cambia cada mes y se realiza
una copia de seguridad.
• El modelo calcula el costo de instancia optimizado para EBS por separado, pero no
lo agrega al costo total de almacenamiento.
3. Network
• El modelo asume las tarifas escalonadas de Transferencia de Datos OUT disponibles

públicamente desde Amazon EC2 a Internet.
4. IT Labor
• El modelo supone que un administrador de TI puede administrar 400 instancias de

EC2.
5. Soporte AWS
• El modelo asume soporte de nivel empresarial para AWS.

Como parte del resultado de la propuesta de migración aplicada al caso de estudio se tie-
ne en cuenta el análisis de las dependencias de los sistemas, se resalta que el 69,3 % están
sin dependencia, es decir, funcionan de forma independiente. En cuanto a la criticidad
de los sistemas, el 40,91 % son servicios de alta criticidad. Lo que respecta al Tipo de Mi-
gración, es notable que el 37,4 % deben ser migrados a IaaS, el 12,9 % deben ser retirados
y el 7,5 % deben ser retenidos dentro de la institución.
Utilizando la calculadora de AWS, se determinó que en un lapso de 3 años se ahorra-
ría el 81 % teniendo en cuenta los recursos utilizados. Dicha comparación supone que el
centro de datos local tiene en cuenta gran parte de las consideraciones para la certifica-
ción Tier III, de esta forma se podría comparar con la infraestructura de AWS.
72
Capítulo 7
Conclusiones y Trabajo Futuros
7.1 Conclusiones
En el presente trabajo se presentó un breve análisis de algunas de las estrategias de mi-
gración existente, cada una enfocada desde distintas perspectivas. Se comprobó que es
esencial que se defina una estrategia de extremo a extremo que tenga en cuenta los objeti-
vos de la organización, así como el impacto de la migración a la computación en la nube
de las operaciones de TI.
Existen varios tipos de migración, cada uno se debe aplicar dependiendo del sistema
específico que se desea migrar, de los objetivos que se desea alcanzar con el sistema o de-
pendiendo de las características de la nube que se desea aprovechar con la migración. La
migración a IaaS es la que requiere menor esfuerzo de migración pero que menos apro-
vecha las características de la nube, mientras la reingeniería en SaaS es la que requiere
mayor esfuerzo, pero una de la que más aprovecha las características mencionadas.
Se comprobó de que no existe una metodología definida o un estándar internacional
aceptado para que las organizaciones adopten el modelo de computación en la nube en
la operación de sus infraestructuras de TI. Cada organización define los requerimientos
de integración y estandarización de sus plataformas y servicios de TI según la visión que
tengan sobre su crecimiento.
Del análisis de los posibles escenarios, para la migración a la computación a la nube,
se ha decidido evaluar en una institución educativa, tomando como caso particular la
Facultad Politécnica. Las funciones principales de la migración es aprovechar las ventajas
de la nube para aumentar el desempeño, la escalabilidad, la flexibilidad, entre otros. El
propósito es mejorar la calidad de servicio, la experiencia del usuario y la disponibilidad.
La estrategia de migración presentada se basó en la recopilación y agrupamiento de
otras estrategias presentadas. Éstas estrategias enfocan la migración desde distintas pers-
pectivas, y la presentada la integra, permitiendo disponer de una estrategia más consoli-
dada.
Con el caso de estudio se evaluó la infraestructura de comunicación, sistemas y centro
de datos, se confirmó que es posible que gran porcentaje de una propiedad informática
organizacional ya no esté en uso. Específicamente para el caso de estudio, el 12,9 % de los
servicios están corriendo pero los mismos están sin uso, y el 40,1 % ya están apagados y
también sin uso.
En cuanto a la evaluación de los sistemas, los resultados obtenidos son los siguientes:
el 2,1 % se debe migrar a SaaS, el 18,4 % a IaaS, el 19 % a IaaS y posteriormente a SaaS, el
7,5 % se debe retener en la institución y el 53 % deben ser retirados.
Como principal aporte de este trabajo se puede mencionar la estrategia de migración
a la nube específica presentada para la institución. Se propuso un nuevo orden de mi-
gración de recursos a la nube. Se presentaron plantillas específicas a ser utilizadas para
el relevamiento de datos. Se permiten nuevos enfoques que promoverán cambios en el
paradigma de trabajo y acceso a la educación virtual gracias a una plataforma en la nube.
Capítulo 7. Conclusiones y Trabajo Futuros 73
7.2 Trabajos Futuros

• Proponer una estrategia de evaluación de costo de alta precisión para la migración.
• Realizar todos los pasos de la Estrategia de Migración presentada.
• Estudiar la necesidad de migración al entorno de computación en la nube, a nivel

nacional.
7.3 Presentación de Trabajo

Este trabajo fue seleccionado por la XIII Jornadas de Jóvenes Investigadores de UNI-
VERSIDAD NACIONAL DE ASUNCIÓN para la presentación en la XXVII Jornada de
Jóvenes Investigadores organizado por la Asociación de Universidades Grupo Monte-
video (AUGM) en la Universidad Federal de Sao Carlos, estado de Sao Paulo, Brasil. El
mismo fue presentado en la fecha el 24 de octubre del 2019.
74
Capítulo 8
Anexo

Total Cost of Ownership (TCO) Comparison
This report includes a total cost of ownership (TCO) comparison between running your
application in an on-premises or colocation infrastructure and AWS. The on-
premises/colocation infrastructure is based on the description you provided in the online
tool. The AWS infrastructure is an approximation of the infrastructure you described. These
calculations use third-party estimates and assumptions. This calculator provides an
estimate of usage charges for AWS services based on certain information you provide.
Your monthly charges will be based on your actual usage of AWS services and may vary
from the estimates the calculator has provided.
Notices
© 2014 Amazon Web Services, Inc., This report is provided for informational purposes only.
Amazon Web Services, Inc. is not responsible for any damages related to the information in
this report, which is provided “as is” without warranty of any kind, whether express, implied,
or statutory. Nothing in this report creates any warranties or representations from Amazon
Web Services, Inc., its affiliates, suppliers, or licensors. This report does not modify the
applicable terms and conditions governing your use of Amazon Web Services technologies,
including the Amazon Web Services website. This report represents Amazon Web Services'
current product offerings as of the date of issue and are subject to change without notice. 
Total Cost of Ownership (TCO) : On-Premises vs. AWS

AWS Total Cost of Ownership (TCO) Calculator
On-Premises vs. AWS Summary
You could save 81% a year by moving your infrastructure to AWS.
Your three year total savings would be $ 1,230,608.

3 Years Cost Breakdown
3 Yr. Total Cost of Ownership
On-Premises AWS
Server $ 1,183,898 $ 155,365
Storage $ 142,987 $ 64,284
Network $ 177,367 $ 37,525
IT-Labor $ 15,228 $ 31,698
Total $ 1,519,479 $ 288,871
AWS cost includes business level support

 
6/9/2019 © 2008- 2014, Amazon Web Services, Inc. or its affiliates. All rights reserved. Page 2 of 39
Environment Details
Currency: United States Dollar

Your Virtual environment Your AWS environment : US East (N. Virginia)
Environment: Virtual Closest AWS Instances
# of CPU Memory VM Optimize # RAM Optimize Instance

OS Instance vCPU
VMs Cores (GB) Usage (%) by Instances (GiB) by Type
1 2 4 Linux 100% RAM 3 Yr. Partial

1 c3.xlarge 4 7.5 RAM
Upfront RI
1 1 1 Linux 100% RAM
3 Yr. Partial
1 t2.micro 1 1 RAM
Upfront RI
3 Yr. Partial
1 1 4 Linux 100% RAM 1 c3.xlarge 4 7.5 RAM Upfront RI

Upfront RI
3 Yr. Partial
5 10 16 Linux 100% RAM Upfront RI

Upfront RI
3 Yr. Partial
5 m4.xlarge 4 16 RAM
Upfront RI
3 Yr. Partial
1 4 8 Linux 100% RAM 4 c3.2xlarge 8 15 RAM
Upfront RI

3 Yr. Partial
1 t2.small 1 2 RAM
Upfront RI
3 Yr. Partial
1 t2.small 1 2 RAM

1 m4.large 2 8 RAM
Upfront RI
3 Yr. Partial
Upfront RI
3 Yr. Partial
1 1 1 Linux 100% RAM 1 c3.xlarge 4 7.5 RAM
Upfront RI

3 Yr. Partial
Upfront RI
3 Yr. Partial
Upfront RI

Upfront RI
3 Yr. Partial
6/9/2019 1 Inc. or its affiliates.
© 2008- 2014, Amazon Web Services, t2.small
All rights reserved. 1 2 RAMPage 3 of 39
3 Yr. Partial
1 c3.xlarge Total
4 Cost of7.5
Ownership
RAM (TCO) : On-Premises vs. AWS

Upfront RI
3 Yr. Partial
1 t2.small 1 2 RAM

1 t2.micro 1 1 RAM
Upfront RI

3 Yr. Partial
1 t2.micro 1 1 RAM
Upfront RI
3 Yr. Partial
Upfront RI

1 t2.small 1 2 RAM
Upfront RI
3 Yr. Partial
1 t2.micro 1 1 RAM

1 t2.small 1 2 RAM
Upfront RI

3 Yr. Partial
1 t2.small 1 2 RAM
Upfront RI
3 Yr. Partial
Upfront RI

1 c3.xlarge 4 7.5 RAM Upfront RI
3 Yr. Partial
1 t2.small 1 2 RAM

1 m4.xlarge 4 16 RAM
Upfront RI

3 Yr. Partial
1 t2.small 1 2 RAM
Upfront RI
3 Yr. Partial
1 6 20 Linux 100% RAM 1 m4.large 2 8 RAM
Upfront RI

1 t2.micro 1 1 RAM
Upfront RI
1 10 20 Linux 100% RAM
3 Yr. Partial
1 c3.2xlarge 8 15 RAM

1 t2.small 1 2 RAM
Upfront RI

3 Yr. Partial
1 t2.small 1 2 RAM
Upfront RI
3 Yr. Partial
Upfront RI

6/9/2019 © 2008- 2014, Amazon Web Services,
1 Inc. or its affiliates. All rights reserved.
db.t2.large 2 8 RAMPage 4 of 39
Upfront RI
3 Yr. Partial
1 t2.small 1 Cost of2Ownership
Total RAM (TCO) : On-Premises vs. AWS
Upfront RI
3 Yr. Partial
Upfront RI

1 db.t2.large 2 8 RAM
Upfront RI
3 Yr. Partial

Upfront RI
3 Yr. Partial
1 t2.small 1 2 RAM
Upfront RI
3 Yr. Partial
1 1 2 Linux 100% RAM 1 db.t2.large 2 8 RAM
Upfront RI

1 db.t2.medium 2 4 RAM
Upfront RI
3 Yr. Partial

1 m4.large 2 8 RAM
Upfront RI
1 12 12 Linux 100% RAM
3 Yr. Partial
Upfront RI
3 Yr. Partial
Upfront RI
Storage (TB) Bandwidth (Mbps)

3 Yr. Partial
1 db.m3.2xlarge 8 30 RAM
Upfront RI
SAN NAS Object Pipe Peak/Average
Size Ratio
3 Yr. Partial
69 0 0 1 t2.small 1 2 RAM
Upfront RI
1,000 3
3 Yr. Partial
1 m4.large 2 8 RAM
Upfront RI
3 Yr. Partial
1 c3.xlarge 4 7.5 RAM Upfront RI
3 Yr. Partial
Upfront RI
3 Yr. Partial
Upfront RI
3 Yr. Partial
1 t2.small 1 2 RAM
Upfront RI
3 Yr. Partial
Upfront RI
3 Yr. Partial
1 m4.large 2 8 RAM
Upfront RI
6/9/2019 © 2008- 2014, Amazon Web Services,

3 Yr. Partial
1 Inc. or its affiliates.
c3.xlarge
All rights reserved. 4 7.5 RAMPage 5 of 39
Upfront RI
3 Yr. Partial
1 c3.xlarge 4 Cost of7.5
Total RAM
Ownership (TCO) : On-Premises vs. AWS
Upfront RI
3 Yr. Partial
1 m4.large 2 8 RAM
Upfront RI
3 Yr. Partial
Upfront RI
3 Yr. Partial
1 t2.small 1 2 RAM
Upfront RI
3 Yr. Partial
1 t2.micro 1 1 RAM
Upfront RI
3 Yr. Partial
Upfront RI
3 Yr. Partial
Upfront RI
3 Yr. Partial
Upfront RI
3 Yr. Partial
Upfront RI
3 Yr. Partial
1 t2.micro 1 1 RAM
Upfront RI
EC2 Instance Mapping Criteria
Optimize by Description
Option matches by VCPU count and then

CPU finds the lowest priced EC2 instance from
the available choices
Option matches by RAM size and then finds

RAM the lowest priced EC2 instance from the
available choices
Option matches by I/O requirements and

Storage IO then finds the lowest priced EC2 instance 
from the available choices
 
Cost Breakdown

Your On-Premises Cost Breakdown Your AWS Cost Breakdown

 
Server

Input
On-Premises Server Configuration
App Name # of VMs CPU Cores Memory (GB) Hypervisor Guest OS VM Usage (%) Virtualization Host
web2 1 2 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM

backup00 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
scm01 1 2 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
acad2 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
acad5 1 2 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
acad 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
acad11 -15 5 10 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
acad16 -19 4 8 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
scm02 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
tgm01 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
sdi 1 4 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
jasper01 1 2 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
www00 1 2 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
logAnalyzer 1 4 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
cloud01 1 2 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
gdocbkp01 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
startuplab02 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
startuplab01 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
sonar01 1 4 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
storage -cia 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
ws -sat 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
itaipu01 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
encuesta 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
devel-cia02 1 6 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
odk 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
storage -acad 1 6 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
tyky 1 2 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
mobe 1 2 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
develcia01 1 6 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
sbd02 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
gitorius03 1 2 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
opengeo01 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
smb 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
sbd 1 2 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
sbdo4 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
educa02 1 6 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
pentaho -02 1 4 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
devel-sbd01 1 10 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
haproxy01 1 10 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
devel-pentaho 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
educa02 1 6 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
pentaho -02 1 4 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
devel-sbd01 1 10 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
haproxy01 1 10 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
devel-pentaho 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
test-www 1 4 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
genexus 1 2 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
gw-balancer02 1 4 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
monitoreo 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
dhcp 1 4 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
proxy 1 4 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
VPN 1 4 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
monitoreo2 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
concerto 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
kav01 1 4 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
wifi 1 6 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
proxy-pfsense 1 4 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
gw-balancer03 1 12 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
smtp 1 1 0 KVM/Xen Linux 0 Host 1: 2 CPU, 8 Cores, 96 GB RAM
Modified Assumption
Parameter Value
Host 1: 2 CPU, 8 Cores, 96 GB RAM

VMware License cost ($)
Metered Power cost/kWH
Cost to operate a rack/mo
Output
On-Premises - Server Costs AWS - EC2 Costs
Server Hardware Costs EC2 Instance Costs (3 Yr.) – On-Demand and

Reserved Instances
Virtual Host Sizing for Virtualized Environments 3 Yr. Partial Upfront Reserved Instances
# Host # # VM AWS Instance Upfront Hourly Total Costs

App Name RAM
VMs Type Cores Servers Density
c3.xlarge $ 1,016 $ 0.05 $ 2,202

Host
web2 1 16 96 1 1
1
t2.micro $ 66 $ 0.00 $ 119
Host
backup00 1 16 96 1 1 c3.xlarge $ 1,016 $ 0.05 $ 2,202
1
Host c3.xlarge $ 1,016 $ 0.05 $ 2,202

scm01 1 16 96 1 1
1
c3.xlarge $ 1,016 $ 0.05 $ 2,202
Host
acad2 1 16 96 1 1
1 c3.xlarge $ 1,016 $ 0.05 $ 2,202
Host m4.xlarge $ 1,051 $ 0.04 $ 10,525

acad5 1 16 96 1 1
1
c3.2xlarge $ 2,031 $ 0.09 $ 17,611

Host
acad 1 16 96 1 1
1
t2.small $ 122 $ 0.00 $ 243
Host
acad11 -15 5 16 96 2 3 t2.small $ 122 $ 0.00 $ 243
1
Host Total Cost of Ownership (TCO) : On-Premises vs. AWS
acad5 1 16 96 1 1 m4.xlarge $ 1,051 $ 0.04 $ 10,525
1
c3.2xlarge $ 2,031 $ 0.09 $ 17,611

Host
acad 1 16 96 1 1
1
t2.small $ 122 $ 0.00 $ 243
Host
acad11 -15 5 16 96 2 3 t2.small $ 122 $ 0.00 $ 243
1
Host m4.large $ 526 $ 0.02 $ 1,053

acad16 -19 4 16 96 1 4
1
c3.xlarge $ 1,016 $ 0.05 $ 2,202
Host
scm02 1 16 96 1 1
1 c3.xlarge $ 1,016 $ 0.05 $ 2,202
Host c3.xlarge $ 1,016 $ 0.05 $ 2,202

tgm01 1 16 96 1 1
1
c3.xlarge $ 1,016 $ 0.05 $ 2,202
Host
sdi 1 16 96 1 1
1
c3.xlarge $ 1,016 $ 0.05 $ 2,202
Host
jasper01 1 16 96 1 1 t2.small $ 122 $ 0.00 $ 243
1
Host t2.micro $ 66 $ 0.00 $ 119

www00 1 16 96 1 1
1
t2.micro $ 66 $ 0.00 $ 119
Host
www02 1 16 96 1 1
1 c3.xlarge $ 1,016 $ 0.05 $ 2,202
Host t2.small $ 122 $ 0.00 $ 243

www04 1 16 96 1 1
1
t2.micro $ 66 $ 0.00 $ 119
Host
www07 1 16 96 1 1
1
t2.small $ 122 $ 0.00 $ 243
Host
backup01 1 16 96 1 1 t2.small $ 122 $ 0.00 $ 243
1
c3.xlarge $ 1,016 $ 0.05 $ 2,202

Host
backup03 1 16 96 1 1
1
c3.xlarge $ 1,016 $ 0.05 $ 2,202
Host
backup04 1 16 96 1 1
1 t2.small $ 122 $ 0.00 $ 243
Host m4.xlarge $ 1,051 $ 0.04 $ 2,105

logAnalyzer 1 16 96 1 1
1
t2.small $ 122 $ 0.00 $ 243
Host
cloud01 1 16 96 1 1
1
m4.large $ 526 $ 0.02 $ 1,053
Host
gdocbkp01 1 16 96 1 1 t2.micro $ 66 $ 0.00 $ 119
1
c3.2xlarge $ 2,031 $ 0.09 $ 4,403

Host
startuplab02 1 16 96 1 1
1
t2.small $ 122 $ 0.00 $ 243
Host
1 t2.small $ 122 $ 0.00 $ 243
Host m4.large $ 526 $ 0.02 $ 1,053

sonar01 1 16 96 1 1
1
6/9/2019 db.t2.large
© 2008- 2014, Amazon Web Services, Inc. or its affiliates. All rights reserved.$ 872 $ 0.03 Page$10
1,689
of 39
t2.small $ 122 $ 0.00 $ 243
1 t2.small $ 122 $ 0.00 $ 243
Host m4.large $ 526 $ 0.02 $ 1,053

sonar01 1 16 96 1 1
1
db.t2.large $ 872 $ 0.03 $ 1,689
Host
storage -cia 1 16 96 1 1
1 c3.xlarge $ 1,016 $ 0.05 $ 2,202
Host c3.xlarge $ 1,016 $ 0.05 $ 2,202

ws -sat 1 16 96 1 1
1
t2.small $ 122 $ 0.00 $ 243

Host
itaipu01 1 16 96 1 1
1
db.t2.large $ 872 $ 0.03 $ 1,689
Host
encuesta 1 16 96 1 1 db.t2.medium $ 872 $ 0.03 $ 1,663
1
Host c3.4xlarge $ 4,063 $ 0.18 $ 8,806

devel-cia02 1 16 96 1 1
1
m4.large $ 526 $ 0.02 $ 1,053
Host
odk 1 16 96 1 1
1 c3.4xlarge $ 4,063 $ 0.18 $ 8,806
storage - Host c3.2xlarge $ 2,031 $ 0.09 $ 4,403

1 16 96 1 1
acad 1
db.m3.2xlarge $ 5,382 $ 0.38 $ 15,448

Host
tyky 1 16 96 1 1
1
t2.small $ 122 $ 0.00 $ 243
Host
mobe 1 16 96 1 1 m4.large $ 526 $ 0.02 $ 1,053
1
Host c3.xlarge $ 1,016 $ 0.05 $ 2,202

develcia01 1 16 96 1 1
1
c3.xlarge $ 1,016 $ 0.05 $ 2,202
Host
sbd02 1 16 96 1 1
1 c3.xlarge $ 1,016 $ 0.05 $ 2,202
Host t2.small $ 122 $ 0.00 $ 243

gitorius03 1 16 96 1 1
1
c3.xlarge $ 1,016 $ 0.05 $ 2,202

Host
opengeo01 1 16 96 1 1
1
m4.large $ 526 $ 0.02 $ 1,053
Host
smb 1 16 96 1 1 c3.xlarge $ 1,016 $ 0.05 $ 2,202
1
Host t2.small $ 122 $ 0.00 $ 243

sbd 1 16 96 1 1
1
t2.micro $ 66 $ 0.00 $ 119
Host
sbdo4 1 16 96 1 1
1 c3.xlarge $ 1,016 $ 0.05 $ 2,202
Host c3.xlarge $ 1,016 $ 0.05 $ 2,202

educa02 1 16 96 1 1
1
c3.xlarge $ 1,016 $ 0.05 $ 2,202

Host
pentaho -02 1 16 96 1 1
1
c3.2xlarge $ 2,031 $ 0.09 $ 4,403
Host
devel-sbd01 1 16 96 1 1 t2.micro $ 66 $ 0.00 $ 119
1
Total Cost: $ 142,750
c3.xlarge $ 1,016 $ 0.05 $ 2,202
pentaho -02 1 16 96 1 1
1
c3.2xlarge $ 2,031 $ 0.09 $ 4,403
Host
devel-sbd01 1 16 96 1 1 t2.micro $ 66 $ 0.00 $ 119
1
Host Total Cost: $ 142,750

haproxy01 1 16 96 1 1
1
Host Total costs = (upfront cost + hourly cost*8,784 hours/yr.*3

sbd01 1 16 96 1 1 years)* # of instances (Applied to the whole term whether or
1
not you're using the Reserved Instance)
Host
sbd05 1 16 96 1 1
1
On-Demand
devel- Host
1 16 96 1 1 AWS Instance Upfront Hourly Total Costs
pentaho 1
Host c3.xlarge 0 0.21 $ 5,534

test-www 1 16 96 1 1
1
t2.micro 0 0.012 $ 316
Host
genexus 1 16 96 1 1
1 c3.xlarge 0 0.21 $ 5,534
gw- Host c3.xlarge 0 0.21 $ 5,534

1 16 96 1 1
balancer02 1
c3.xlarge 0 0.21 $ 5,534
Host
monitoreo 1 16 96 1 1
1
c3.xlarge 0 0.21 $ 5,534
Host
dhcp 1 16 96 1 1 m4.xlarge 0 0.2 $ 26,352
1
c3.2xlarge 0 0.42 $ 44,271

Host
proxy 1 16 96 1 1
1
t2.small 0 0.023 $ 606
Host
VPN 1 16 96 1 1
1 t2.small 0 0.023 $ 606
Host m4.large 0 0.1 $ 2,635

monitoreo2 1 16 96 1 1
1
c3.xlarge 0 0.21 $ 5,534
Host
concerto 1 16 96 1 1
1
c3.xlarge 0 0.21 $ 5,534
Host
kav01 1 16 96 1 1 c3.xlarge 0 0.21 $ 5,534
1
c3.xlarge 0 0.21 $ 5,534

Host
wifi 1 16 96 1 1
1
c3.xlarge 0 0.21 $ 5,534
proxy- Host
1 16 96 1 1
pfsense 1 t2.small 0 0.023 $ 606
gw- Host t2.micro 0 0.012 $ 316

1 16 96 1 1
balancer03 1
t2.micro 0 0.012 $ 316
Host
smtp 1 16 96 1 1
1
c3.xlarge 0 0.21 $ 5,534
t2.small 0 0.023 $ 606
Server Hardware Costs

6/9/2019 © 2008- 2014, Amazon Web Services, Inc. or its affiliates. All rights reserved. Page$12 of 39
t2.micro 0 0.012 316
t2.micro 0 0.012 $ 316
smtp 1 16 96 1 1
1
c3.xlarge 0 0.21 $ 5,534
t2.small 0 0.023 $ 606
Server Hardware Costs

t2.micro 0 0.012 $ 316
# # of RAM Units Power Unit Unit Total

Servers Cores (GB) (U) (KW) Cost Discount Cost t2.small 0 0.023 $ 606
$ $ t2.small 0 0.023 $ 606

1 16 96 2 0.75 25%
9,263 6,947
c3.xlarge 0 0.21 $ 5,534
$ $
1 16 96 2 0.75 25%
9,263 6,947
c3.xlarge 0 0.21 $ 5,534
$ $
1 16 96 2 0.75 25% t2.small 0 0.023 $ 606
9,263 6,947
m4.xlarge 0 0.2 $ 5,270

$ $
1 16 96 2 0.75 25%
9,263 6,947
t2.small 0 0.023 $ 606
$ $
1 16 96 2 0.75 25% m4.large 0 0.1 $ 2,635
9,263 6,947
$ $ t2.micro 0 0.012 $ 316

1 16 96 2 0.75 25%
9,263 6,947
c3.2xlarge 0 0.42 $ 11,068
$ $
2 16 96 4 1.5 25%
9,263 13,895 t2.small 0 0.023 $ 606
$ $ t2.small 0 0.023 $ 606

1 16 96 2 0.75 25%
9,263 6,947
m4.large 0 0.1 $ 2,635

$ $
1 16 96 2 0.75 25%
9,263 6,947
db.t2.large 0 0.136 $ 3,584
$ $
1 16 96 2 0.75 25% c3.xlarge 0 0.21 $ 5,534
9,263 6,947
$ $ c3.xlarge 0 0.21 $ 5,534

1 16 96 2 0.75 25%
9,263 6,947
t2.small 0 0.023 $ 606
$ $
1 16 96 2 0.75 25%
9,263 6,947 db.t2.large 0 0.136 $ 3,584
$ $ db.t2.medium 0 0.136 $ 3,584

1 16 96 2 0.75 25%
9,263 6,947
c3.4xlarge 0 0.84 $ 22,136

$ $
1 16 96 2 0.75 25%
9,263 6,947
m4.large 0 0.1 $ 2,635
$ $
1 16 96 2 0.75 25% c3.4xlarge 0 0.84 $ 22,136
9,263 6,947
$ $ c3.2xlarge 0 0.42 $ 11,068

1 16 96 2 0.75 25%
9,263 6,947
db.m3.2xlarge 0 1.48 $ 39,001
$ $
1 16 96 2 0.75 25%
9,263 6,947 t2.small 0 0.023 $ 606
$ $ m4.large 0 0.1 $ 2,635

1 16 96 2 0.75 25%
9,263 6,947
$ $ c3.2xlarge 0 0.42 $ 11,068
1 16 96 2 0.75 25% Total Cost of Ownership (TCO) : On-Premises vs. AWS
9,263 6,947
db.m3.2xlarge 0 1.48 $ 39,001
$ $
1 16 96 2 0.75 25%
9,263 6,947 t2.small 0 0.023 $ 606
$ $ m4.large 0 0.1 $ 2,635

1 16 96 2 0.75 25%
9,263 6,947
c3.xlarge 0 0.21 $ 5,534

$ $
1 16 96 2 0.75 25%
9,263 6,947
c3.xlarge 0 0.21 $ 5,534
$ $
1 16 96 2 0.75 25% c3.xlarge 0 0.21 $ 5,534
9,263 6,947
$ $ t2.small 0 0.023 $ 606

1 16 96 2 0.75 25%
9,263 6,947
c3.xlarge 0 0.21 $ 5,534
$ $
1 16 96 2 0.75 25%
9,263 6,947 m4.large 0 0.1 $ 2,635
$ $ c3.xlarge 0 0.21 $ 5,534

1 16 96 2 0.75 25%
9,263 6,947
t2.small 0 0.023 $ 606
$ $
1 16 96 2 0.75 25%
9,263 6,947
t2.micro 0 0.012 $ 316
$ $
1 16 96 2 0.75 25% c3.xlarge 0 0.21 $ 5,534
9,263 6,947
$ $ c3.xlarge 0 0.21 $ 5,534

1 16 96 2 0.75 25%
9,263 6,947
c3.xlarge 0 0.21 $ 5,534
$ $
1 16 96 2 0.75 25%
9,263 6,947 c3.2xlarge 0 0.42 $ 11,068
$ $ t2.micro 0 0.012 $ 316

1 16 96 2 0.75 25%
9,263 6,947
$ $
1 16 96 2 0.75 25%
9,263 6,947
Total costs = (hourly cost*8,784 hours*3 years*utilization)* #
$ $ of instances (Hourly usage fee charged for each hour you
1 16 96 2 0.75 25%
9,263 6,947 use the instance)
$ $
1 16 96 2 0.75 25%
9,263 6,947
Lowest Priced Instance
$ $
1 16 96 2 0.75 25%
9,263 6,947 Instance Cost Type
$ $ c3.xlarge $ 2,202 3 Yr. Partial Upfront RI

1 16 96 2 0.75 25%
9,263 6,947
t2.micro $ 119 3 Yr. Partial Upfront RI
$ $
1 16 96 2 0.75 25%
9,263 6,947
c3.xlarge $ 2,202 3 Yr. Partial Upfront RI
$ $
1 16 96 2 0.75 25% c3.xlarge $ 2,202 3 Yr. Partial Upfront RI
9,263 6,947

$ $
1 16 96 2 0.75 25%
9,263 6,947
6/9/2019 $ $ Services, Inc. or its affiliates. All rights reserved.
© 2008- 2014, Amazon Web Page 14 of 39
1 16 96 2 0.75 25%
$ $ Total Cost of Ownership (TCO) : On-Premises vs. AWS
1 16 96 2 0.75 25% c3.xlarge $ 2,202 3 Yr. Partial Upfront RI
9,263 6,947

$ $
1 16 96 2 0.75 25%
9,263 6,947
$ $
1 16 96 2 0.75 25%
9,263 6,947 m4.xlarge $ 10,525 3 Yr. Partial Upfront RI
$ $ c3.2xlarge $ 17,611 3 Yr. Partial Upfront RI

1 16 96 2 0.75 25%
9,263 6,947
t2.small $ 243 3 Yr. Partial Upfront RI
$ $
1 16 96 2 0.75 25%
9,263 6,947
$ $
1 16 96 2 0.75 25% m4.large $ 1,053 3 Yr. Partial Upfront RI
9,263 6,947

$ $
1 16 96 2 0.75 25%
9,263 6,947
$ $
1 16 96 2 0.75 25%
9,263 6,947 c3.xlarge $ 2,202 3 Yr. Partial Upfront RI

1 16 96 2 0.75 25%
9,263 6,947
$ $
1 16 96 2 0.75 25%
9,263 6,947 t2.small $ 243 3 Yr. Partial Upfront RI
$ $ t2.micro $ 119 3 Yr. Partial Upfront RI

1 16 96 2 0.75 25%
9,263 6,947

$ $
1 16 96 2 0.75 25%
9,263 6,947
$ $
1 16 96 2 0.75 25% t2.small $ 243 3 Yr. Partial Upfront RI
9,263 6,947
$ $ t2.micro $ 119 3 Yr. Partial Upfront RI

1 16 96 2 0.75 25%
9,263 6,947
$ $
1 16 96 2 0.75 25%
9,263 6,947 t2.small $ 243 3 Yr. Partial Upfront RI

1 16 96 2 0.75 25%
9,263 6,947

$ $
1 16 96 2 0.75 25%
9,263 6,947
$ $
1 16 96 2 0.75 25% m4.xlarge $ 2,105 3 Yr. Partial Upfront RI
9,263 6,947
$ $ t2.small $ 243 3 Yr. Partial Upfront RI

1 16 96 2 0.75 25%
9,263 6,947
m4.large $ 1,053 3 Yr. Partial Upfront RI
$ $
1 16 96 2 0.75 25%
9,263 6,947 t2.micro $ 119 3 Yr. Partial Upfront RI

1 16 96 2 0.75 25%
9,263 6,947
6/9/2019 t2.small
© 2008- 2014, Amazon Web Services, Inc. or $ 243
its affiliates. All rights reserved. 3 Yr. Partial
PageUpfront
15 of 39 RI
$ $
$ $ Total Cost of Ownership (TCO) : On-Premises vs. AWS
1 16 96 2 0.75 25%
9,263 6,947 t2.micro $ 119 3 Yr. Partial Upfront RI

1 16 96 2 0.75 25%
9,263 6,947

$ $
1 16 96 2 0.75 25%
9,263 6,947
$ $
1 16 96 2 0.75 25% m4.large $ 1,053 3 Yr. Partial Upfront RI
9,263 6,947
$ $ db.t2.large $ 1,689 3 Yr. Partial Upfront RI

1 16 96 2 0.75 25%
9,263 6,947
$ $
1 16 96 2 0.75 25%
9,263 6,947 c3.xlarge $ 2,202 3 Yr. Partial Upfront RI
$ $ t2.small $ 243 3 Yr. Partial Upfront RI

1 16 96 2 0.75 25%
9,263 6,947
db.t2.large $ 1,689 3 Yr. Partial Upfront RI

$ $
1 16 96 2 0.75 25%
9,263 6,947
db.t2.medium $ 1,663 3 Yr. Partial Upfront RI
$ $
1 16 96 2 0.75 25% c3.4xlarge $ 8,806 3 Yr. Partial Upfront RI
9,263 6,947
$ m4.large $ 1,053 3 Yr. Partial Upfront RI

63 126 47.25
437,677
c3.4xlarge $ 8,806 3 Yr. Partial Upfront RI
Total Server Hardware cost $ 437,677

Server Hardware Maintenance cost for 3
$ 196,955
Yrs. (@15%/Yr.)
Total number of Racks required (1 db.m3.2xlarge $ 15,448 3 Yr. Partial Upfront RI
Rack=42U, 28U occupied by servers, 4U by 5
ToR switches and PDUs ) t2.small $ 243 3 Yr. Partial Upfront RI
Total Peak power consumed (kW) 47.25
Rack Infrastructure Costs
Rack Chassis with PDU (@$3500/rack) c3.xlarge $ 2,202 3 Yr. Partial Upfront RI
$ 9,250
cost
PDUs, dual 280V per rack (@$540 each, c3.xlarge $ 2,202 3 Yr. Partial Upfront RI
$ 4,600
2/rack for HA) cost
Top of Rack Switch (48-port 10/100/1G,
$ 50,000 c3.xlarge $ 2,202 3 Yr. Partial Upfront RI
$5,000 each, 2/rack for high availability)
Rack and Stack one-time deployment cost
$ 15,750 t2.small $ 243 3 Yr. Partial Upfront RI
( $250/server)
Provision for spare servers for 3 Yrs. (@5%
$ 95,195
spare capacity/Yr.) c3.xlarge $ 2,202 3 Yr. Partial Upfront RI
Total Rack costs (rack infrastructure and $ 809,426 m4.large $ 1,053 3 Yr. Partial Upfront RI
server hardware)
Virtualization Software Costs c3.xlarge $ 2,202 3 Yr. Partial Upfront RI
Total virtualization license and maintenance $ - t2.small $ 243 3 Yr. Partial Upfront RI
cost (3 Yrs.)

MySQL
MySql Edition Open Source
MySql License List Price (per 2 cores) $ -
MySql License Price After Discount $ -
MySql Standard Ed. Licenses Required 1
MySql
6/9/2019 Standard Cost $ Amazon Web Services,
© 2008- 2014, - Inc. or its affiliates. All rights reserved. Page 16 of 39
Total virtualization license and maintenance $ - t2.small $ 243 3 Yr. Partial Upfront RI
cost (3 Yrs.)
MySQL
MySql Edition Open Source
MySql License List Price (per 2 cores) $ -
MySql License Price After Discount $ -
MySql Standard Ed. Licenses Required 1
MySql Standard Cost $ -
Total 3-Year Database Software License
$ -
Cost
Total Server Costs (Hardware and Software) $ 809,426
- 3 Yr. t2.micro $ 119 3 Yr. Partial Upfront RI

Facilities Costs (data center space, power and
cooling) - On-Premises
EC2 Costs (3 Yr.) $ 142,750
Total Power consumed by servers (kW) 47.25
Metered cost per kWH $ 0.10
EC2 Reserved Instances discounts (if Applicable)
Estimated power cost/month $ 3,402.00
Monthly cost to operate a rack $ 1,400.00
EC2 Reserved Instances
Total rack costs/month $ 7,000.00
Total monthly Facilities costs $ 10,402.00
AWS Pricing # Upfront
Total cost
Instance model Instances fee
Facilities costs - On-Premises (3 Yr.) $ 374,472
3 Yr.
Server cost break-down c3.xlarge Partial 1 $ 1,016 $ 2,202
Upfront RI
Server cost break-down 3 Yr.

t2.micro Partial 1 $ 66 $ 119
Category Cost % of Total Cost Upfront RI
Hardware $ 809,426 68% 3 Yr.

c3.xlarge Partial 1 $ 1,016 $ 2,202
Upfront RI
Software $- 0%
3 Yr.
Operating Costs (3 Yrs.) $ 374,472 32% c3.xlarge Partial 1 $ 1,016 $ 2,202
Upfront RI
Total $ 1,183,898 100%
3 Yr.
Total server cost, including $ 1,183,898
Upfront RI
operational cost (3 Yr.)
3 Yr.
Upfront RI
3 Yr.
m4.xlarge Partial 5 $ 1,051 $ 10,525
Upfront RI
3 Yr.
c3.2xlarge Partial 4 $ 2,031 $ 17,611
Upfront RI
3 Yr.
t2.small Partial 1 $ 122 $ 243
Upfront RI
3 Yr.
6/9/2019
t2.small Partial
© 2008- 2014, Amazon Web Services, Inc. or its affiliates. All rights reserved.
1 $ Page
12217 of 39$ 243
Upfront RI
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
m4.large Partial 1 $ 526 $ 1,053
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
m4.xlarge Partial 1 $ 1,051 $ 2,105
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
c3.2xlarge Partial 1 $ 2,031 $ 4,403
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
db.t2.large Partial 1 $ 872 $ 1,689
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
db.t2.large Partial 1 $ 872 $ 1,689
Upfront RI
3 Yr.
db.t2.medium Partial 1 $ 872 $ 1,663
Upfront RI
3 Yr.
c3.4xlarge Partial 1 $ 4,063 $ 8,806
Upfront RI
3 Yr.
Upfront RI
3 Yr.
c3.4xlarge Partial 1 $ 4,063 $ 8,806
Upfront RI
3 Yr.
c3.2xlarge Partial 1 $ 2,031 $ 4,403
Upfront RI
3 Yr.
db.m3.2xlarge Partial 1 $ 5,382 $ 15,448
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
6/9/2019 Upfront RI
© 2008- 2014, Amazon Web Services, Inc. or its affiliates. All rights reserved. Page 20 of 39
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
Upfront RI
3 Yr.
c3.2xlarge Partial 1 $ 2,031 $ 4,403
Upfront RI
3 Yr.
Upfront RI
Total fee $ 142,750
Discount Tier Applicable 0%
AWS Business Support (EC2) $ 12,615

EC2 Costs (3 Yr.) after discount $ 155,365

 
Storage

Input
On-Premises Storage Configuration
Storage Type Raw Storage Capacity (TB) Max IOPS for Application Backup % / Month Disk Type
SAN 12 0 0
SAN 24 0 0
SAN 19 0 0
SAN 14 0 0
Modified Assumption
Parameter Value
SAN
Number of TB in a rack
Output
On-Premises - Storage Costs AWS - Storage Costs
Only raw capacity specified, no IO requirements;
use HDD by default EBS Storage - Only Standard EBS used with no IOPS
SAN Cost requirements
Starting capacity/raw capacity (TB) user EBS Costs - Equivalent to On-Premises SAN environment
69
provided
Starting capacity/raw capacity (GB) 70,656 Starting capacity (GB) 12,718
Capacity after OS Penalty (~7%, capacity General
63,590
OS recognizes) (GB) Equivalent EBS storage volume Purpose
Usable capacity based on RAID (RAID 10 (SSD)
12,718
assumed) configuration (GB) Number of EBS volumes required 13
$/raw GB purchase price $ 1.50 EBS volumes cost/month $ 1,589.76
Discounted $/raw purchase price (50% Initial snapshot cost(one-time) $ 1,208.22
$ 0.75
storage hardware discount applied) EBS incremental snapshots cost/month $ -
Total EBS cost /month $ 1,590
Acquisition Cost of SAN storage $ 52,992

EBS Costs (3 Yr) - no IOPS $
58,440
EBS Costs (3 Yr.) $ 64,284
Storage backup cost AWS Business Support (EBS) $ 5,844

EFS Costs (3 Yr.)
Total amount of storage to be backed up (TB) 69.00 $
{TotalCostForThreeYears}
Total amount of storage to be backed up (GB) 70,656
AWS Business Support (EFS) $
Type of Tape Library used LTO-6
{EFSSupportCost}
Max uncompressed speed (MB/s) for Tape
160
Library Total AWS Storage Costs (3 Yr.) $ 64,283.54
Max uncompressed speed - TB/day 13.18
Backup Window Time(hr.) 8
TBs processed/drive for backup window 4.39
Number of Tape drives required 16
Tape Library price/drive $ 2,300
Backup cost (3 Yr.) $ 36,800
Storage Overhead (data center space,

6/9/2019
power,
© 2008- 2014, Amazon Web Services, Inc. or its affiliates. All rights reserved. Page 22 of 39
cooling, storage administrator)
TBs processed/drive for backup window 4.39
Number of Tape drives required 16 Total Cost of Ownership (TCO) : On-Premises vs. AWS
Tape Library price/drive $ 2,300
Backup cost (3 Yr.) $ 36,800
Storage Overhead (data center space, power,

cooling, storage administrator)
Typical TB managed by storage admin/Yr. 1000
Storage Admin Costs (3 Yr.) $ 2,795
Amount of TBs hosted by a single rack (TB) 1000

Number of racks required 1
Monthly cost to operate a rack $ 1,400
Total data center space, power, cooling $ 50,400

costs (3 Yr.)
Storage cost break-down

Storage cost break-down
Category Cost % of Total Cost
Raw Capacity (Incl. IOPS) $ 52,992 37%
Backup $ 36,800 26%
Overhead (excl. storage admin) $ 50,400 35%
Storage Admin $ 2,795 2%
Total $ 142,987 100%
Total Storage Costs (3 Yr.) $ 142,987


 
Network

Input
Data Center Bandwidth (Mbit/s) 1000
Peak/Average Ratio 3
Modified Assumption
Parameter Value
Network overhead as % of Hardware costs (%)
Output
On-Premises - Networking Costs AWS - Data Transfer Costs
Networking Hardware and Software Costs

Network overhead cost as a % of server Monthly Data Transfer Out (TB) 10.3
10%
hardware acquisition cost
Network hardware and software cost $ 80,942.60 Data Transfer Costs
Network hardware and software
15%
maintenance/Yr. US East (N. Tier Monthly
Maintenance cost (3 Yr.) $ 36,424.17 Virginia) (GB) Cost
Total Network Hardware and Software First 1 GB per

costs (3 Yr.)
$ 117,367
month
$- 1 $-
Bandwidth Costs (On-Premises) Up to 10 TB per

$ 0.09 10240 $ 921.60
Size of Network Pipe (Mbps) 1000 Month
Peak/Avg. Ratio 3
Average Bandwidth 333 Next 40 TB per
$ 0.09 306 $ 26.00
Month
On-premises Bandwith costs/Mbps $ 5.00
Bandwith costs/month $ 1,666.67
Next 100 TB per
Avg. data transferred per month (TB)- $ 0.07 0 $-
103 Month
Inbound + Outbound
Avg. data transferred per month (TB)-
20.6 Over 350 TB per
North/South $ 0.05 0 $-
Month
Avg. data transferred per month (TB) -
10.3
Outbound
On-premises Bandwith costs/Mbps $ 5.00 Total monthly data transfer costs $ 947.60
Bandwith costs/month $ 1,666.67
AWS Business Support (data transfer) $ 3411.36
Data Transfer Costs (3 Yr.) $ 37,525
Bandwith costs - On-Premises (3 Yr.) $ 60,000.00
Network Admin Costs

Network admin effort as % of total IT admin
8%
effort
Avg. burdened salary for your Network
$ 13,500
Admin
IT labor cost (1 Yr.) $ -
Network admin costs (1 Yr.) $ -
Network admin costs (3 Yrs.) $ -
Total Networking Costs (3 Yr.) $ 177,367


 
Avg. burdened salary for your Network
$ 13,500
Admin
IT labor cost (1 Yr.) $ -
Network admin costs (1 Yr.) $ -
Network admin costs (3 Yrs.) $ -
Total Networking Costs (3 Yr.) $ 177,367


 
IT Labor

Input
Provide average salary for your data center staff $ 13500
Provide Number of VMs per Admin 250
Modified Assumption
Parameter Value
On-Premises Server Admin Ratio 13500
Output
On-Premises- IT Labor Costs AWS - IT Labor Costs
Number of VMs managed by an Admin 250

Avg. burdened salary for your IT Admin $ 13,500
EC2 Admin Costs
Number of VMs in your current
69 # of EC2 instances managed by an admin 375
environment
Avg. burdened salary for your IT Admin $ 13,500
Admin effort required for your current
28% # of EC2 instances in your environment 61
environment
Total IT Admin Costs -based on number Admin effort required for your current
$ 3,726 17%
of VMs/Servers (1 Yr.) environment
IT labor costs (1 Yr.) $ 2,196
Total IT Admin Costs -based on IT labor costs (3 Yr.) $ 6,588
$ 11,178
number of VMs/Servers (3 Yr.)
Database Admin Costs
Number of Databases managed by an RDS Admin Cost

40
Admin
Avg. burdened salary for your IT Admin $ 13,500 # of RDS instances managed by an admin 100
Colo On-Call Labor Cost 0 Avg. burdened salary for your IT Admin $ 13,500
Number of Databases in your current # of RDS instances in your environment 8
4 Admin effort required for your current
environment
8%
Admin effort required for your current environment
10%
environment IT labor costs (3 Yr.) 3,240
Total IT Admin Costs -based on $ 9,828
3-Year IT DBA Labor costs $ 11,178
number of VMs / Servers (3 Yr.) 
 
AWS SUPPORT

Modified Assumption
Parameter Value
AWS Server Admin Ratio

AWS support Included Y
1 Yr. or 3 Yr. Reserved Instances 3
AWS - Support Costs
Monthly EC2 Spend $ 2,150.25

Monthly EBS Spend $ 1,623.32
Monthly S3 Spend $ -
Monthly S3IA Spend $ -
Monthly Data Transfer Spend $ 947.60
Total AWS Spend - Month $ 4,721.17
Support Costs - All Services
Business Level Support Cost
10% of monthly AWS usage for the first $0 - $10K $ 472.12
7% of monthly AWS usage for the first $0 - $10K $-
AWS Support for all services - Month $ 472.12
AWS Support for all services (3 Yr.) $ 16,996.22
EC2 Reserved Instances Upfront cost after $ 65,341

discount
Support Costs - Reserved Instances
Business Level Support Cost
10% of monthly AWS usage for the first $0–$10K $ 1,000.00
7% of monthly AWS usage from $10K–$80K $ 3,873.87
5% of monthly AWS usage from $80K–$250K $ 0.00
3% of monthly AWS usage over $250K $ 0.00
AWS Reserved Instance Support cost (One - $ 4,873.87

Time)
21,870 
Total AWS Support (Business) $
3% of monthly AWS usage overof$250K
Total Cost $ 0.00
Ownership (TCO) : On-Premises vs. AWS
AWS Reserved Instance Support cost (One - $ 4,873.87

Time)
Total AWS Support (Business) $ 21,870 
METHODOLOGY 
The AWS TCO calculator uses the following methodology when calculating on-premises, colocation, and AWS
costs.
Our methodology defines Total Cost of Ownership (TCO) as below –
TCO = Acquisition Costs + Operational Costs
Operational costs include labor cost to manage the data center operations as well as overhead cost associated
with running the data center equipment. A standard 3 year time frame is used for our calculations as the useful
life for the data center equipment.

The following graphic shows the major cost categories in on-premises and colocation environments
For On-Premises/Colocation, TCO = Server Costs + Storage Costs + Network Costs + IT

Labor Costs
For on-premises and colocation environments, each of the major cost categories (server, storage, and network)
include the cost of hardware, software (where applicable), and overhead costs. Overhead costs include the cost
of data center floor space, and power and cooling required for data center equipment. For our calculations, a
“standard rack” is considered to be the typical 19 inch rack that has a rack footprint of 28 sq. ft. (actual area
covered by the rack) in the data center. Additionally, we assume average power density per rack to be 10kW in an
on-premises data center and a cabinet to have a primary 20 amp, 120V single phase circuit and a redundant 20
amp, 120V circuit in a colocation environment. We use Uptime institute cost model to calculate overhead costs
for on-premises and a publicly available price quote from a global colocation, interconnection, and managed IT
infrastructure service provider for colocation environment.Since power and cooling expenses are billed on a
monthly basis, we calculate our overhead costs on a monthly basis. We also use a “standard rack” as a
common point for calculating overhead costs.
infrastructure service provider for colocation environment.Since power and cooling expenses are billed on a
Total Costrack”
monthly basis, we calculate our overhead costs on a monthly basis. We also use a “standard of Ownership
as a (TCO) : On-Premises vs. AWS
common point for calculating overhead costs.
For On-Premises and Colocation environments, the $/rack/month is calculated

differently -
As shown above, the logic by which the overhead cost is calculated for on-premises and colocation
environments is different. Most of the other cost categories are handled similarly between these environments.
On the network side, a colocation environment incurs recurring bandwidth costs where as an on-premises
environment also incurs network capital expense and network operation expense.
environments is different. Most of the other cost categories are handled similarly between these environments.
On the network side, a colocation environment incurs recurring bandwidth costs whereTotal
as anCost of Ownership (TCO) : On-Premises vs. AWS
on-premises
environment also incurs network capital expense and network operation expense.
Finally, on AWS side overhead costs is included in the publicly listed prices and customers don’t have to pay
extra for space, power, and cooling as shown below.
With AWS, we include AWS Business level support costs. AWS Business level support includes guidance on
optimizing AWS products and configuration to meet your specific needs. Business level support provides
discounts as your AWS usage grows
TCO Methodology for RDS
optimizing AWS products and configuration to meet your specific needs. Business level support provides
discounts as your AWS usage grows Total Cost of Ownership (TCO) : On-Premises vs. AWS
TCO Methodology for RDS
SharePoint Architecture
Amazon Web Services – Microsoft SharePoint Server 2016 on the AWS Cloud May 2016
ASSUMPTIONS
The AWS TCO calculator makes the following assumptions for on-premises, co -location, and AWS environments.
On-Premises and Co-location Assumptions
1. Servers and Racks:

ASSUMPTIONS
The AWS TCO calculator makes the following assumptions for on-premises, co -location, and AWS environments.
On-Premises and Co-location Assumptions
1. Servers and Racks:
l On-premises and co -location server prices are based on Dell PowerEdge Rack servers and HP ProLiant Rack
servers.
l Dell PowerEdge prices available here.
l HP ProLiant Rack servers prices available here.
l Servers can be physical or virtualized. Currently the tool supports VMware vSphere, KVM and Xen hypervisors.
l For virtualized environments, two virtualization host configurations are supported –
l Host 1 - 2 processors with 8 cores each and 96 GB RAM.
l Host 2 – 4 processors with 8 cores each and 256 GB RAM
l VM density is calculated based on the virtual RAM and virtual cores allocated to VMs.
l Server and rack hardware are discounted by 25% off the publicly available list prices.
l A “standard rack” is considered to be the typical 19 inch rack that has a rack footprint (actual area covered by
the rack) in the data center as defined here. Standard rack assumed to consist of 42 rack units (42U).
l On average each rack is filled up to 75% of capacity (i.e. for a 42U rack, 32U is actually used)
l Dell PowerEdge Energy Smart 4620S Rack Enclosure used to hold data center equipment. A base price of
$3,499 assumed as per the published price here.
l Every rack consists of two top of rack Switches (ToR) for Redundancy. Cisco Catalyst 2960 48 port switches
used in calculations with the following configuration- 48 x 10/100/1000 - PoE+ 525Watt + 4 x SFP, LAN Base
Layer 2. here.
l Every rack consists of 2 Power Distribution Units (PDU) for high-availability. APC Metered Rack PDU - power
distribution strip used with a base price of $545 as per the published price here.
l A 15% hardware maintenance/year applied to the server and rack hardware.
l 5% of all server capacity assumed to be hot spare servers. A hot spare or hot standby is used as a failover
mechanism to provide reliability and high-availability in data center environments.
2. Software
l VMware vSphere Enterprise Plus licenses assumed for customers using VMware environments. A base price
of $3,495 per licenses and $874 for 1 year support and subscription assumed as per the published prices
from VMware here.
l KVM is free software released under the GPL as described here. Vendors like RedHat offer KVM hypervisor
under a subscription model that includes product access, all updates, and support. Details can be found here.
l Xen hypervisor is covered by the GNU general public license as described here and available for free. Vendors
like Citrix offer a free and paid version of XenServer. Details can be found here.
l Software licenses and maintenance are discounted by 25% off the publicly available list prices.
l The Linux distributions used in our model are available for free as described here. Our model doesn’t use the
paid Linux distributions like SUSE Enterprise Linux and Red Hat Enterprise Linux.
3. Storage
l Our model assumes RAID 10 configurations for on-premises and colocation storage. RAID 10 details are
available here.
l Hard disk manufacturers measure drive capacity differently than operating systems. Hard disk manufacturers
use a “base -10” measure, whereas operating systems use a “base -2” measure as described here. This
3. Storage
l Our model assumes RAID 10 configurations for on-premises and colocation storage. RAID 10 details are
available here.
l Hard disk manufacturers measure drive capacity differently than operating systems. Hard disk manufacturers
use a “base -10” measure, whereas operating systems use a “base -2” measure as described here. This
mismatch causes a 7% penalty on the disk capacity.
l Raw capacity is defined as the disk capacity in the box or frame while usable capacity is the disk capacity after
RAID protection and available for host allocation.
l Average Solid State Devices (SSD) and Hard Disk Drives (HDD) price per GB available here. Our model
assumes higher prices as we include the price of Host Bus Adapters (HBA), Fiber Channel Adapters, Optical
or Fiber Channel Cables and other storage equipment.
l A discount of 50% is applied by default to the SSD and HDD price per GB.
l The model assumes that a storage admin manages 1000 TB of data on an annual basis.
l The model assumes that a single storage rack contains 1000 TB of disks.
l The model assumes LTO -5 tapes used for backups. Details available here.
l A base price of $1800/drive assumed for the cost of LTO-5 drive taking tapes of up to 1.5 TB true
(uncompressed) capacity as per the published price here.
4. Network
l The model assumes a 20% network overhead for on-premises environments. The network overhead is
calculated by taking a 20% overhead on server and rack hardware cost.
l For a colocation facility, no network overhead is assumed as colocation providers would bundle this cost in
their prices.
l Traffic in the data center assumed to be both north-south (between servers inside the data center and end
points outside the data center) and east-west (between components in the data center). Our model assumes
80% of all data center traffic is “east -west ”.
l For on-premises environment, Bandwidth costs also include cost of WAN Optimizers and MPLS VPN.
l Average colocation bandwidth pricing is tiered – our model assumes $30/Mbps at the lowest tier and $7/Mbps
at the highest tier. More details can be found here.
l Average network admin effort is around 8% of total IT administration effort as per this report.
5. Power and Cooling
l Average Retail Price of Electricity in the US can be found here.

l The average cents per kilowatt-hour in the US commercial segment for January 2014 was 10.34 cents.
l The model assumes a standard on -premises/colocation PUE of 1.5 and a base kWh (kilo watt hour) price of
10 cents/hr. This gives us a total electricity charge of 15 cents per kWh (10*1.5).
6. Data Center Space
l The model assumes colocation providers charge a fixed $ per kW rate that covers the cost of all power and
space contracted. Every rack assumed to have a primary and redundant power supply.
l The model assumes a separate charge for space, power and cooling for on-premises environments.
7. IT Labor
l Average data center admin salaries by region available here.

space contracted. Every rack assumed to have a primary and redundant power supply.
l The model assumes a separate charge for space, power and cooling for on-premises environments.
7. IT Labor
l Average data center admin salaries by region available here.
AWS Assumptions
1. Compute
l Both On-Demand and 3 Yr. Reserved Instance types used for AWS compute.
l EC2 instances are matched with on-premises servers and VMs based on CPU, RAM, or storage I/O.
l The number of EC2 instances is the same as the physical servers or VMs on-premises meaning we don ’t
apply any cost optimization on AWS side. In real-life situations, customers would change instance sizes up or
down based on monitoring various AWS resource metrics like CPU utilization, free memory, or disk usage.
l Amazon EC2 provides a wide selection of instance types optimized to fit different use cases. Our model uses
General purpose, Compute-optimized, Memory-optimized, and Storage-optimized instances.
l The model uses only the current generation of instances- General purpose (m3), Compute-optimized (c3),
Memory-Optimized (R3), and Storage-optimized (I2).
l Current generation of instances provide faster, newer Intel Ivy Bridge processors, SSD-based instance
storage, Higher performance Enhanced Networking, and advanced features such as support for HVM AMIs.
l The model assumes Reserved Instance volume discounts as described here.
2. Storage
l On-premises SAN and NAS storage systems are represented in AWS as EBS volumes.
l On-premises Object storage is represented in AWS as S3.
l S3 offers multiple storage classes – S3 Standard, RRS, and Glacier depending on how S3 handles data. Our
model assumes S3 standard only.
l Model assumes RAID 0 for EBS volumes as described here.
l Multiple EBS volumes can be striped together to achieve up to 48,000 IOPS when attached to larger EC2
instances as described here.
l For backup, we use EBS snapshots to S3 for calculating backup costs on AWS.
l Backup%/month is the amount of data that changes every month. So a 50% number means that 50% of data
changes every month and is backed up.
l Model calculates EBS-optimized instance cost separately, but doesn’t add it to the total storage cost.
3. Network
l Model assumes publicly available Data Transfer OUT tiered rates From Amazon EC2 to Internet as described
here.
4. IT Labor
l Model assumes that an IT admin can manage 400 EC2 instances.
5. AWS Support
l Model assumes Business -level support for AWS as described here.
SharePoint Assumptions
l Model assumes that an IT admin can manage 400 EC2 instances.
5. AWS Support
l Model assumes Business -level support for AWS as described here.
SharePoint Assumptions
1. SharePoint Server 2016 on AWS
l The Amazon Web Services (AWS) cloud provides a suite of infrastructure services that enable you to deploy
SharePoint Server 2016 securely, affordably, and with high availability.Running SharePoint Server on the AWS
cloud gives you flexibility and agility, and you can fully customize and extend SharePoint for your business
processes. This Quick Start implementation guide walks you through the steps to automatically deploy an
enterprise SharePoint Server 2016 architecture in your own AWS account
2. Cost and Licenses
l You are responsible for the cost of the AWS services used while running this Quick Start reference deployment.
There is no additional cost for using the Quick Start itself. The AWS CloudFormation template for the SharePoint
Server 2016 Quick Start includes configuration parameters that you can customize, and some settings, such as
the instance types and the number of instances, can greatly affect the cost of the deployment. AWS has
published a whitepaper that shows how to estimate the cost of your SharePoint deployment. You have a wide
array of options for building your SharePoint farm, and it’s not possible to cover them all in that whitepaper or in
this guide. The following table offers a model based on some key assumptions
3. Deploying Microsoft software on AWS
l Microsoft on AWS here.

l Secure Microsoft applications on AWS here.
l Microsoft Licensing Mobility here.
l MSDN on AWS here.
4. Microsoft SharePoint Server
l Configure SQL Server 2012 Always On Availability Groups for SharePoint 2013 here.
l Windows Server Failover Clustering and SQL Server AlwaysOn Availability Group here.

FAQ

1. What is the purpose of the AWS TCO calculator?
You can use the AWS TCO calculator to compare the cost of running your applications in an on-premises or
colocation environment to AWS. The tool produces a detailed cost comparison with AWS based on the
infrastructure details you provide.
2. What assumptions do you make?
We make several assumptions based on third party analyst and industry research as well as data from hundreds
of AWS customers. Please refer to the Assumptions section of the TCO output page.
3. What is the difference between an on -premises data center and colocation facility?
An on-premises data center is a brick and mortar structure that contains all the required systems / facilities to
house computing infrastructure running 24 x 7 x 365. An on-premises data center is owned and operated by the
owners of the computing infrastructure. A colocation facility is usually offered by a provider that owns their own
“data center” and rents out rack space and/or computing hardware. These environments have very different cost
structures and your TCO for the same application would vary between these environments.
4. How are you calculating on-premises (or colocation) server infrastructure costs?
The calculator averages market rate pricing from multiple enterprise server vendors to determine an average price
for a server based on CPU, RAM, and storage configuration. In addition, the tool adds licensing cost for Operating
System and virtualization licenses as well as rack infrastructure costs. Rack infrastructure costs include cost of
power distribution units, top of rack switches, rack chassis and one-time server deployment.
5. Do you apply any discount to on-premises (or colocation) server hardware, storage
hardware, and software acquisition costs?
Yes, by default server hardware is discounted by 25%, Operating System and Virtualization licenses by 25% and
storage hardware by 50%. These closely resemble industry standard pricing policy.
6. What types of storage are you using to compare?
On-premises Storage Area Network (SAN) and Network Attached Storage (NAS) are mapped to Amazon EBS, while
on-premises object storage is mapped to Amazon S3. The amount of on-premises storage specified in the
calculator input represents the amount of raw physical storage capacity purchased. AWS storage that is calculated
is not equal to the amount of raw physical storage capacity, but rather a percentage of the storage that is actually
utilized for on-premises data storage. Primary and secondary research indicates that this is ~50-60% of the raw
physical storage purchased after taking into account RAID and Operating System overhead.
7. How are you calculating on-premises (or colocation) storage costs?
We are using industry standard pricing based on $ per raw GB purchase. We use a combination of Solid State
Drives (SSD) and Hard Disk Drives (HDD); SSDs are used in case customers need higher IOPS for their on-
premises/colocation environments. The tool uses RAID 10 configurations for on-premises and colocation storage.
7. How are you calculating on-premises (or colocation) storage costs?
We are using industry standard pricing based on $ per raw GB purchase. We use a combination of Solid State
Drives (SSD) and Hard Disk Drives (HDD); SSDs are used in case customers need higher IOPS for their on-
premises/colocation environments. The tool uses RAID 10 configurations for on-premises and colocation storage.
A discount of 50% is applied by default to the SSD and HDD price per GB.
8. How are you calculating on-premises network costs?
This is calculated as a percentage (20%) of server hardware acquisition cost. The network cost includes the cost
for network interface cards, host bus adapters, core switches and other networking gear.
9. How are you calculating bandwidth costs?
We use a sampling of average market rates for data center telecom from major markets (typically measured in
$/Mbps). Traffic in the data center is assumed to be both north-south (between servers inside the data center and
end points outside the data center) and east-west (between components in the data center). We also assume a
high percentage of data center traffic (~70-80%) to be “east -west ”.
10. What is the overhead cost? How are you calculating it for on-premises and colocation
environments?
Overhead costs include the cost of data center floor space, and power and cooling required for data center
equipment. It can also include other ongoing data center expenses such as maintenance and physical security.
For the sake of simplicity, we only consider data space, power, and cooling when calculating overhead costs. The
way overhead cost is calculated is different for on-premises and colocation environments. We leverage the publicly
available Uptime institute’s cost model to calculate overhead costs for on-premises data center and a price quote
from a global colocation and interconnection infrastructure service provider for colocation environment. Since
power and cooling expenses are billed on a monthly basis, we calculate our overhead costs on a monthly basis.
We also use a “standard rack” as a common point for calculating overhead costs.
11. How do you calculate IT Labor costs?
You can specify the fully burdened cost of your IT admin resources. We leverage industry and third party analyst
research for server: admin ratios. For physical environments, we assume one FTE IT admin per 100 physical
servers or 250 virtual machines. We use these two variables and the rest of the inputs of the tool to calculate the
percentage administrative cost. For storage, we assume a storage admin to manage 1 PB of storage annually and
for network we assume network admin effort to be ~8% of the total IT admin effort.
12. How are the Amazon EC2 compute costs computed?
The tool automates the task of selecting the right AWS instance type based on the information you provide; you can
input your physical or virtual infrastructure details and the tool will provide the equivalent AWS instance types that
meet your requirements. The calculator uses current generation Amazon EC2 instances (except GPU instances) to
calculate AWS compute costs. The tool also takes into account your on-premises usage/utilization rate. You can
think of on-premises usage/utilization rate as the total desired uptime for your servers or VMs. For example, over a
3 year time-period, a 10% usage rate implies that your servers are running 10% of the time (or 3.6 months).
13. Why do you ask for usage/utilization rate?

meet your requirements. The calculator uses current generation Amazon EC2 instances (except GPU instances) to
calculate AWS compute costs. The tool also takes into account your on-premises usage/utilization rate. You
Total Cost of Ownership can
(TCO) : On-Premises vs. AWS
think of on-premises usage/utilization rate as the total desired uptime for your servers or VMs. For example, over a
3 year time-period, a 10% usage rate implies that your servers are running 10% of the time (or 3.6 months).
13. Why do you ask for usage/utilization rate?
If you don't need your on-premises VMs or physical servers up and running 24/7/365 you could save lot of money by
powering off the VM/servers when not used. AWS provides multiple pricing models to optimize your spend for
variable or steady-state workloads. The calculator will let you change the usage % (uptime) and automatically
select the right AWS pricing model that will meet that uptime at the lowest price. If you don’t know your
usage/utilization rate, the tool defaults to 100% (which means that your servers/VMs are running 24/7/365).
14. Why can’t I run calculations with previous generation Amazon EC2 instances?
We encourage you to use the latest generation of Amazon EC2 instances to get the best price for performance
ratio. The calculator uses the current Amazon EC2 instances - M3, C3, R3, I2 and HS1 (and m1.small and
t1.micro). You can find more details about the previous generation Amazon EC2 instances here.
15. Do you use S3 Reduced Redundancy Storage and Amazon Glacier?
No, currently the tool only uses S3 standard. For backup of EBS data, the tool uses EBS Snapshots to Amazon S3
charges.
16. Are data transfer costs included in the AWS storage cost?
No, all AWS data transfer costs are included under the network charges for AWS. The data transfer cost is
calculated based on the EC2 data transfer out from Amazon EC2 to the internet. Since the calculator doesn’t
assume cross -AZ deployments, it doesn’t calculate data transfer charges between Amazon EC2 instances in
another Availability Zone in the same region.
17. What is the AWS server to admin ratio?
We have found a 400:1 Server to Admin ratio to be appropriate when running your apps on AWS. This is a
conservative ratio based on AWS customer engagements. (Note: for on-premises we assume a 100:1 server
admin ratio for physical servers and 250:1 ratio for virtual machines)
18. Why do you include AWS support costs?
We recommend all AWS customers use AWS Support to ensure a seamless experience leveraging AWS
infrastructure services. We have created multiple tiers to fit your unique technical needs and budget. AWS Basic
Support offers all AWS customers access to our Resource Center, Service Health Dashboard, Product FAQs,
Discussion Forums, and Support for Health Checks – at no additional charge. Customers who desire a deeper
level of support can subscribe to AWS Support at the Developer, Business, or Enterprise level. in our TCO model,
we assume Business -level support costs

114
Bibliografía
[1] The twelve-factor app.
[2] Vasilios Andrikopoulos, Tobias Binz, Frank Leymann, and Steve Strauch. How to
adapt applications for the cloud environment. Computing, 95(6):493–535, Jun 2013.
[3] Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz,
Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and Matei
Zaharia. A view of cloud computing. Commun. ACM, 53(4):50–58, April 2010.
[4] AWS. Architecting for the cloud, 2016.
[5] AWS. Aws well-architected framework, 2018.
[6] AWS. Migrar a amazon web services, Accedido en Octubre 2018.
[7] Javier Barabas. Iaas paas saas - modelos de servicio cloud, Accedido en Septiembre
2018.
[8] Tobias Binz, Frank Leymann, and David Schumm. CMotion: A Framework for Mi-
gration of Applications into and between Clouds. In 2011 IEEE International Confe-
rence on Service-Oriented Computing and Applications (SOCA). IEEE Computer Society,
December 2011.
[9] Richard Blandford. Information security in the cloud. 2011:15–17, 04 2011.
[10] Rajkumar Buyya, James Broberg, and Andrzej M. Goscinski. Cloud Computing Prin-
ciples and Paradigms. Wiley Publishing, 2011.
[11] y W. Romero C.A. Gutiérrez, R. Almeida. Diseño de un modelo de migración a cloud

computing para entidades públicas de salud. pages 10–16, 06 2017.
[12] Shuchih Ernest Chang, Kuo-Ming Chiu, and Yu-Ching Chiao. Cloud migration:
Planning guidelines and execution framework. In 2015 Seventh International Confe-
rence on Ubiquitous and Future Networks, pages 814–819, July 2015.
[13] Cisco. Planning the migration of enterprise applications to the cloud, May. 2018.
[14] TeamQuest Corporation. Capacity planning - discipline for data center decisions.
TQ-WP23 Rev. B, 2004.
[15] C. Núnez C. Cabanellas F. Invernizzi, S. Ortiz. Despliegue de un sistema web vertical

rígido como sistema web elástico en la nube. 2018.
[16] Gartner. Five ways to migrate applications to the cloud, May. 2018.
[17] James Hamilton. On designing and deploying internet-scale services. In Proceedings

of the 21st Conference on Large Installation System Administration Conference, LISA’07,
pages 18:1–18:12, Berkeley, CA, USA, 2007. USENIX Association.
BIBLIOGRAFÍA 115
[18] 45Squared Inc. Method of migrating to the cloud: Rehosting. Apr. 2018.
[19] Imperva Inc. Cloud migration guide. Jan. 2018.
[20] P. Jamshidi, A. Ahmad, and C. Pahl. Cloud migration research: A systematic review.
IEEE Transactions on Cloud Computing, 1(2):142–157, July 2013.
[21] Mike Capern Kyle Brown. Top 9 rules for cloud applications, April 2014.
[22] Beimar Alberto Leon Velandia and Mario Armando Rosero-Munoz. Recomendacio-
nes para contratar servicios en la ’nube’. Facultad de Ingenieria. Scieloco, 23:93 – 108,
07 2014.
[23] A. D. Lin, C. S. Li, W. Liao, and H. Franke. Capacity optimization for resource poo-
ling in virtualized data centers with composable systems. IEEE Transactions on Para-
llel and Distributed Systems, 29(2):324–337, Feb 2018.
[24] M. M. Melo and E. A. M. Fagotto. A decision-making tool for datacenter migration.

IEEE LATIN AMERICA TRANSACTIONS, 13(5):1446 – 1452, n.d.
[25] N. C. Mendonca. Architectural options for cloud migration. Computer, 47(8):62–66,

Aug. 2014.
[26] Atif Farid Mohammad and Hamid Mcheick. Cloud services testing: An understan-
ding. Procedia Computer Science, 5:513 – 520, 2011. The 2nd International Conference
on Ambient Systems, Networks and Technologies (ANT-2011) / The 8th Internatio-
nal Conference on Mobile Web Information Systems (MobiWIS 2011).
[27] Maram Mohammed and Omar Batarfi. Cloud scalability considerations. 5:37–47, 08
2014.
[28] Cadet P. Lemberger P. Morel M., Alves M. Google Apps: Mastering Integration and
Customization. Packt Publishing Ltd, 2011.
[29] Nebula. A novel vocational training programme on cloud computing skills, July.
2018.
[30] María A. Murazzo Susana B. Chávez Adriana E. Martín Nelson R. Rodríguez, Fran-
cisca A. Valenzuela. Factores que influyen en la evaluación de parámetros de perfor-
mance y escalabilidad para clouds híbridos. Departamento e Instituto de Informática,
Universidad Nacional de San Juan San Juan, C.P. 5400 , Argentina, 2013.
[31] RedHat. What’s the difference between cloud and virtualization?, Apr. 2018.
[32] Matt Stine. Migrating to cloud-native application architectures (twelve factor).
[33] J. Varia. Migrating your existing applications to the aws cloud, Octubre 2010.
[34] Jinesh Varia. Cloud architectures, 2008.
[35] Peter Weill and Jeanne W. Ross. IT Savvy: What Top Executives Must Know to Go from
Pain to Gain. Harvard Business School Press, Boston, MA, USA, 2009.
[36] Jun-Feng Zhao and Jian-Tao Zhou. Strategies and methods for cloud migration.
International Journal of Automation and Computing, 11(2):143–152, Apr 2014.

Estrategias de Migración A Un Entorno de Computación en La Nube PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Estrategias de Migración A Un Entorno de Computación en La Nube PDF

Caricato da

Copyright:

Formati disponibili

U NIVERSIDAD N ACIONAL DE A SUNCIÓN FACULTAD

T ESIS DE M AESTRÍA EN T ECNOLOGÍA DE LA I NFORMACIÓN Y

5.2.2 Detalle de Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7 Conclusiones y Trabajo Futuros 72

2.1 Tipos de Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 Tipos de Migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1 Plantilla de Diseño Físico y Lógico de la Red . . . . . . . . . . . . . . . . . 34

5.1 Interconexión de Servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.1 Dependencias de Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.1 Virtualización vs Computación en la Nube . . . . . . . . . . . . . . . . . . 9

3.1 Resumen de Tipos de Migraciones de la Literatura . . . . . . . . . . . . . . 12

4.1 Plantilla para detalles de Switches . . . . . . . . . . . . . . . . . . . . . . . 35

5.1 Proveedores de Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.1 Estadística de Tipo de Migración . . . . . . . . . . . . . . . . . . . . . . . . 60

NIST National Institute of Standards and Technology

1.2.2 Objetivos Específicos

• Realizar un estudio de la infraestructura de sistema.

• Estudiar el uso los recursos en el Centro de Datos local.

• Proponer una estrategia de migración del Centro de Datos a un ambiente de compu-

1.3 Organización de la Tesis

Según la definición del Instituto Nacional de Estándares y Tecnología (NIST), la compu-

2.1 Características Principales

• El servicio al usuario de diferentes modelos de infraestructura se ajusta a los reque-

• La independencia de las complicaciones en la gestión de los recursos. De esta ma-

• La aparición de recursos de computación “infinitos”, disponibles bajo demanda, lo

• La eliminación de un compromiso inicial por parte de los usuarios de la nube, lo

2.2 Modelos de Implementación

2.3 Tipos de Servicios

F IGURA 2.1: Tipos de Servicios [22].

• Infraestructura como servicio (IaaS): se encuentra en la capa inferior y es un me-

2.4 Características que necesita un aplicativo para ser considera-

2.5 Economía informática en la nube

F IGURA 2.2: Uso de recursos en un ambiente de computación en la nube

A continuación se presenta tres casos de uso particularmente convincentes que favo-

• Cuando la demanda de un servicio varía con el tiempo. Por ejemplo, el aprovisio-

• Cuando la demanda se desconoce de antemano. Por ejemplo, el inicio de un ser-

Las horas compradas a través de la computación en la nube pueden distribuirse de

F IGURA 2.3: Uso de recursos en Centro de Datos Tradicionales [3].

2.6 Centro de Datos Convencional vs Centro de Datos en la Nu-

TABLA 2.1: Virtualización vs Computacion en la Nube [3, 31]

Virtualización Computación en la Nube

En la Tabla 2.1 se puede observar una comparación entre la virtualización y el entorno

2.7 Conclusiones del Capítulo

3.1 Fundamentos de la estrategia de migración

• Se debe aprovechar la oportunidad para descubrir y evaluar las aplicaciones de

• Se debe comprender el modelo de responsabilidad compartida en lo que se refiere

3.2 Tipos de Migración

F IGURA 3.1: Tipos de Migración

Existen varios tipos de migraciones mencionados por distintos autores, algunos de

• La primera categoría incluye aplicaciones que, debido a sus restricciones o requi-

• La segunda categoría de aplicaciones son aquellas especialmente desarrolladas pa-

• La tercera categoría de aplicaciones se puede adaptar al entorno de la nube.

TABLA 3.1: Resumen de Tipos de Migraciones de la Literatura

Autor Retain Retire IaaS PaaS SaaS

Autor Retain Retire IaaS PaaS SaaS

En [25] se menciona dos estrategias y siete soluciones de migración al entorno de nu-

• La primera categoría incluye aplicaciones que, debido a sus restricciones o requisi-

TABLA 3.2: Tipos y Soluciones de Migración [25]

F IGURA 3.2: Proceso de Migración de Aplicaciones [6]

Este tipo de migración puede proporcionar una solución de migración en la nube,

En [8] se clasificó la migración en tres tipos: Migración de Formato Estandarizado,

• En la Migración de Formato Estandarizado, se migra un componente implemen-

• El primer tipo reemplaza componentes con ofertas en la nube, que es el tipo de