Cloud ComputingPúblico/Privado/Híbrido
-2-
Público/Privado/Híbrido
Sebastián RodríguezService Design de nexica
Privada vs. Pública
• La distinción se establece a partir de la infraestr uctura (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.
-4-
• El límite entre Privada y Pública no es claro. Abundan las definiciones y los puntos de vista en Internet.
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
-8-
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.
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
-9-
España los casos de uso más habituales conciernen a necesidades regulatorias (LOPD nivel alto, PCI DSS, etc.)
Infraestructura como Servicio - On Demand
IaaS
• 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.
-11-
gestionarlas.
• 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: aplicaciones web)
Orquestador
Variaciones puntuales Ejemplo: Presencia en medios
Variaciones predecibles y periódicas.Ejemplo: Diurno / Nocturo
Infraestructura como Servicio - Reserva
IaaS
• 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.
-12-
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
Casos de Uso del Cloud
• Laboratorio de pruebas
• Servidores temporales para demostraciones comerciales
• Entornos de desarrollo, test y validación
• Aulas de formación (e-learning)
Servidores con un ciclo de vida corto ¿Qué busca en el Cloud?
• Agilidad en la provisión y desprovisión
• Pago por uso
• Self-Service
-13-
• Incremento temporal de la capacidad para servir pág ina Web (elasticidad)
• Procesos muy intensivos en cálculo (procesamiento de la imagen, cálculos científicos, etc.)
Aumento temporal de la capacidad (Cloud Bursting)
• Construir arquitecturas elásticas
• Pago por uso
• Transparencia en los costes
¿Qué busca en el Cloud?
Casos de Uso del Cloud
• Ofrecer soluciones SaaS basadas en nuestro IaaS
• Replicación de entornos PaaS definidos por el ISV (por cliente, por región, etc.)
• Integración con plataformas de cliente
Vendedores de Software Independientes (ISV)
• Agilidad en la provisión (de arquitecturas prediseñadas)
• Pago por uso
• Self- Service
• Interoperabilidad
¿Qué busca en el Cloud?
-14-
• Virtualización de Datacenters
• Agilidad en la provisión de nuevas plataformas
• Separación de costes de TI por departamento
• Delegación selectiva de la gestión (capas más bajas)
Departamentos internos de TI
• Agilidad en la provisión (de arquitecturas prediseñadas)
• Pago por uso
• Self- Service o diferentes modalidades de gestión delegada.
¿Qué busca en el Cloud?
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.
-16-
• 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 .
Self-Service
Puntos a Favor Puntos en Contra
Tengo un control total de mi plataforma, por lo que
puedo obtener nuevos servicios en muy poco tiempo.
Aunque el coste de infraestructura pueda sea menor,
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,
simplemente configuro lo que quiero en cada
momento.
Tengo que invertir tiempo en aprender a utilizar las
herramientas y conceptos de un proveedor
específico, y mantenerme al día con los cambios que
va introduciendo en el servicio.
Desde el punto de vista del cliente, un modelo de Self-Service total:
-17-
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
que pedir y negociar presupuestos, aprobar pedidos,
etc.
La creación de arquitecturas elásticas es compleja y
cualquier error puede suponer pagar altos consumos
o sufrir cortes de servicio.
Puedo comparar diferentes proveedores de forma
muy rápida, sin riesgo.
Los desarrollos que haga sobre la API de un
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.
Resumiendo…3 consejos para IaaS
Pago por
Uso
Hay que diseñar
nuestra plataforma
para que pueda
beneficiarse del
Cloud
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
en la provisión.
Es importante elegir un proveedor
que nos permita elegir qué nivel de
gestión queremos asumir o delegar
-18-
Cloud=Managed
Virtual
Hosting
Elasticidad
Uso
Self
Service