4. Privada vs. Pública
• La distinción se establece a partir de la infraestructura (hardware). Se habla
de Cloud Privada cuando la infraestructura sobre la que se construye el Cloud está
dedicada exclusivamente a una organización.
• El Cloud Privado puede estar en las instalaciones de la organización o de un
proveedor, y puede ser gestionada por el cliente o por el proveedor.
• El Cloud Público comparte infraestructura, es completamente gestionado por el
proveedor y sus costes se reparten entre muchos clientes de forma muy granular y
alto nivel de detalle.
• El límite entre Privada y Pública no es claro. Abundan las definiciones y los puntos
de vista en Internet.
-4-
8. Clouds Híbridas
• Combina modelos de despliegue
privados y públicos para
aprovechar lo mejor de ambos
modelos.
• El caso de uso más habitual es
Cloud Bursting (la provisión ágil
de recursos en el Cloud Público
para atender un pico en la
demanda del Cloud Privado)
• Existen otras consideraciones a la hora de decidir qué aplicaciones van a un
modelo o el otro: Seguridad, Latencia de Red, Normativa legal, Costes, etc.
• La opción que reúne más ventajas es la que combina el Cloud Público con el
Cloud Privado Virtual.
-8-
9. Community Cloud
• Es un Cloud Público (la infraestructura es compartida) con acceso restringido a
los miembros de una determinada comunidad de organizaciones.
• Se trata de Clouds “especializados”, diseñados a medida para cumplir con
requisitos específicos de esa comunidad.
• Los ejemplos más conocidos son gubernamentales y académicos (USA). En
España los casos de uso más habituales conciernen a necesidades regulatorias
(LOPD nivel alto, PCI DSS, etc.)
-9-
10. Cloud Computing
IaaS
Sebastián Rodríguez
Service Design de nexica
-10-
11. IaaS
Infraestructura como Servicio - On Demand
• Compramos componentes (servidores,
almacenamiento, IP’s) por unidades de tiempo
(horas, días, meses)
• No existen relaciones preestablecidas o
arquitecturas prediseñadas (como en PaaS).
Somos los responsables de diseñar
arquitecturas escalables (o elásticas) y de
gestionarlas.
Orquestador
• La provisión de estos componentes se hace a
través de paneles de autoprovisión (self-service)
y es cuestión de minutos u horas.
• Hay pocas o ninguna garantía de recursos (no
hay QoS ni SLA)
• Ideal para aplicaciones de demanda muy
variable que necesitan elasticidad constante (ej: Variaciones puntuales
Ejemplo: Presencia en medios
Variaciones predecibles y periódicas.
Ejemplo: Diurno / Nocturo
aplicaciones web)
-11-
12. IaaS
Infraestructura como Servicio - Reserva
• Compramos “capacidad en bruto” (Ghz,
RAM, almacenamiento en disco, redes
privadas, etc.) y la gestionamos a través
de un panel de autoprovisión.
• Es un datacenter virtual privado. Los SLA
pueden ser mucho más estrictos y se
puede implementar QoS.
• Niveles más altos de seguridad.
• Ideal para aplicaciones estables que
requieren alto rendimiento y escalabilidad
a largo plazo (ej: ERP’s, Intranets, etc.)
Crecimiento sostenido Demanda constante
-12-
13. Casos de Uso del Cloud
Servidores con un ciclo de vida corto ¿Qué busca en el Cloud?
• Laboratorio de pruebas • Agilidad en la provisión y
desprovisión
• Servidores temporales para demostraciones comerciales
• Pago por uso
• Entornos de desarrollo, test y validación
• Self-Service
• Aulas de formación (e-learning)
Aumento temporal de la capacidad (Cloud Bursting) ¿Qué busca en el Cloud?
• Incremento temporal de la capacidad para servir página Web • Construir arquitecturas elásticas
(elasticidad)
• Pago por uso
• Procesos muy intensivos en cálculo (procesamiento de la imagen, cálculos
• Transparencia en los costes
científicos, etc.)
-13-
14. Casos de Uso del Cloud
Vendedores de Software Independientes (ISV) ¿Qué busca en el Cloud?
• Ofrecer soluciones SaaS basadas en nuestro IaaS • Agilidad en la provisión (de
arquitecturas prediseñadas)
• Replicación de entornos PaaS definidos por el ISV (por cliente, por región,
etc.) • Pago por uso
• Integración con plataformas de cliente • Self- Service
• Interoperabilidad
Departamentos internos de TI ¿Qué busca en el Cloud?
• Virtualización de Datacenters • Agilidad en la provisión (de
arquitecturas prediseñadas)
• Agilidad en la provisión de nuevas plataformas
• Pago por uso
• Separación de costes de TI por departamento
• Self- Service o diferentes
• Delegación selectiva de la gestión (capas más bajas)
modalidades de gestión delegada.
-14-
16. Self-Service
• El factor que más pesa en la decisión de migrar hacia el Cloud es la agilidad
en el negocio.
• El Self-Service cumple un doble papel en este sentido:
• Reduce los costes del servicio para el proveedor (no necesariamente
para el cliente, que debe dedicar un tiempo adicional a la configuración y
gestión de su plataforma).
• Reduce los tiempos de provisión y puesta en marcha para el cliente.
• Existen grandes diferencias en el grado de implementación del self-service
entre los distintos proveedores. Amazon es el ejemplo de una implementación
total, mientras que otros proveedores como Telefonica, Terremark o NEXICA
lo han hecho en menor grado.
• Existen 2 herramientas fundamentales para ofrecer el Self-Service: Panel de
control y API.
-16-
17. Self-Service
Desde el punto de vista del cliente, un modelo de Self-Service total:
Puntos a Favor Puntos en Contra
Tengo un control total de mi plataforma, por lo que Aunque el coste de infraestructura pueda sea menor,
puedo obtener nuevos servicios en muy poco tiempo. el TCO de mi plataforma no lo es.
El tiempo que el proveedor no dedica a gestionar las
capas más altas de mi plataforma debo dedicarlo yo.
No tengo que explicar mis necesidades a nadie, Tengo que invertir tiempo en aprender a utilizar las
simplemente configuro lo que quiero en cada herramientas y conceptos de un proveedor
momento. específico, y mantenerme al día con los cambios que
va introduciendo en el servicio.
No pago por tareas que puedo hacer yo mismo. Yo soy responsable de mantener el servicio 24x7 (el
proveedor me da la infraestructura base, pero no
monitoriza ni mantiene mis servidores, aplicaciones,
etc.)
Los costes son predecibles y transparentes, no tengo La creación de arquitecturas elásticas es compleja y
que pedir y negociar presupuestos, aprobar pedidos, cualquier error puede suponer pagar altos consumos
etc. o sufrir cortes de servicio.
Puedo comparar diferentes proveedores de forma Los desarrollos que haga sobre la API de un
muy rápida, sin riesgo. proveedor no servirán para otro proveedor, lo que a
la práctica es una barrera de salida.
Puedo automatizar tareas de gestión y control de la
plataforma a través de las API. -17-
18. Resumiendo…3 consejos para IaaS
Hay que analizar el uso que
hacemos de los recursos y
buscar la combinación de
modelos de servicio más
favorable No es un objetivo en sí mismo. Lo
que se busca en realidad es agilidad
Hay que diseñar en la provisión.
nuestra plataforma Es importante elegir un proveedor
para que pueda que nos permita elegir qué nivel de
beneficiarse del gestión queremos asumir o delegar
Cloud Pago por
Uso
Self
Elasticidad
Service = Cloud
Managed
Virtual
Hosting
-18-
19. Gracias por tu atención.
srodriguez@nexica.com
¿Alguna pregunta?
-19-