CloudComputing Consideraciones generales

CloudComputing
Consideraciones generales
Índice
Mejores prácticas para lograr Cloud Computing ________________________________________________________________________________________ 4
Introducción..........................................................................................................................................................................................................................................4
Objetivos. ..............................................................................................................................................................................................................................................4
Historia y Evolución de Cloud Computing._____________________________________________________________________________________________ 4
Marco Histórico y Evolutivo.................................................................................................................................................................................................................4
Definición de Cloud Computing. _____________________________________________________________________________________________________ 5
Características esenciales. ...................................................................................................................................................................................................................5
Modelos de Servicio .............................................................................................................................................................................................................................6
Cloud Infrastructure as a Service (IaaS): ....................................................................................................................................................................................6
Cloud Platform as a Service (PaaS): ...........................................................................................................................................................................................6
Cloud Software as a Service (SaaS): ...........................................................................................................................................................................................7
Modelos de Despliegue .......................................................................................................................................................................................................................7
Nube Privada:..............................................................................................................................................................................................................................7
Nube pública: ..............................................................................................................................................................................................................................7
Nube Híbrida: ..............................................................................................................................................................................................................................7
Nube Comunitaria:......................................................................................................................................................................................................................7
Niveles de Servicio................................................................................................................................................................................................................................8
Beneficios y Desventajas de Utilizar Cloud Computing. __________________________________________________________________________________ 9
Beneficios..............................................................................................................................................................................................................................................9
Desventajas de la Utilización de Cloud Computing ........................................................................................................................................................................ 10
Mecánica de la creación y solicitud de servicios. ______________________________________________________________________________________ 10
Consideraciones adicionales. ........................................................................................................................................................................................................... 12
El servicio de negocio ES un servicio de negocio. ........................................................................................................................................................12
Arquitectura del servicio VS la Nube ............................................................................................................................................................................12
“Malos entendidos” sobre los modelos de servicio. ____________________________________________________________________________________ 12
PaaS y SaaS vs aprovisionamiento de software. ............................................................................................................................................................................. 12
Muchas máquinas virtuales hacen un servicio. .............................................................................................................................................................................. 13
Las capas en la Nube. ........................................................................................................................................................................................................................ 13
Seguridad y Marco Regulatorio en la Nube. __________________________________________________________________________________________ 14
Seguridad ........................................................................................................................................................................................................................................... 14
La flexibilidad al momento del aprovisionamiento: ....................................................................................................................................................14
La capacidad de poder implementar plantillas de configuración...............................................................................................................................15
La utilidad de una arquitectura multi capas. ...............................................................................................................................................................15
La flexibilidad de un proceso de cambios para gestionar los accesos. .......................................................................................................................15
Cumplimiento regulatorio y auditorías ........................................................................................................................................................................................... 15
Enfoque PROACTIVO vs. REACTIVO en la nube. _______________________________________________________________________________________ 15
Definición de las plataformas donde se prestará el servicio de Cloud.......................................................................................................................................... 15
Asignación eficiente de recursos...................................................................................................................................................................................................... 16
Gestión de la capacidad. __________________________________________________________________________________________________________ 17
Planeamiento de la demanda. ......................................................................................................................................................................................................... 17
Gestión de compras con los proveedores de Hardware y Software............................................................................................................................................. 18
Casos de uso adicionales Cloud + Capacity ..................................................................................................................................................................................... 18
Aviso de falta de capacidad al consumidor:.................................................................................................................................................................18
Aprovisionamiento en el servidor menos utilizado.....................................................................................................................................................18
Extensión de locación. ..................................................................................................................................................................................................18
Conclusiones ___________________________________________________________________________________________________________________ 19
2
Document Information
Version:
1.5
Created by:
Mariano Grinfeld (BMC Software)
Last Modified on:
Modified by:
Armando Salas S. (Extension)
3
Mejores prácticas para lograr Cloud Computing
Introducción
Cloud Computing se ha tornado en un término cada vez más escuchado en las organizaciones que utilizan la tecnología informática para dar soporte
a sus procesos de Negocio. Lejos de ser una moda, muchas de sus características pueden fácilmente ser traducidas a un aporte concreto en términos
de valor hacia el negocio.
Objetivos.
El objetivo de este documento es poder brindar un nivel de conocimiento suficiente, en cuanto a visión y terminología que le permita al lector iniciar
una conversación sobre Cloud Computing y por sobre todo que le permita establecer sus propias estrategias, permitiéndole incluir en ésta los
elementos necesarios que garanticen el camino al éxito de dicha iniciativa. El poder articular correctamente estos objetivos, según nuestra experiencia
resultará muy beneficioso para la toda la compañía, y en términos de impacto positivo al negocio,
Como hemos mencionado, la meta principal de este documento no es el de exponer productos y marcas, sino darle una visión más general y
agnóstica.
Historia y Evolución de Cloud Computing.
Marco Histórico y Evolutivo.
El término “Cloud Computing”, o “computación en la nube” obedece una idea que data de los primeros tiempos de Internet, donde la fantasía popular
dictaba un gran “ente” que conecta todo con todo y que podía tener recursos infinitos. Y es en realidad un cambio de paradigma en la forma tradicional
de ver la computación desde el punto de vista organizacional y su relación con el negocio.
Tradicionalmente los servicios de negocios en sistemas abiertos se encontraban invariablemente contenidos en servidores físicos, que tenían altos
costos de mantenimiento, ocupaban una gran cantidad del preciado espacio en un datacenter y por sobre todo, los recursos subyacentes
(almacenamiento, redes, etc.) dependían de distintos factores, como ser la capacidad de interconexión física (distintos conectores, tecnologías,
distancia, y hasta cuántos tomacorrientes había disponible). Lentamente comenzaron a aparecer en el mercado (aunque no siguiendo la cronología
de aparición) tecnologías como la SAN (storage area network) que permitía virtualizar el almacenamiento para poder asignar a un servicio
capacidades de almacenamiento que otro servicio no requería más y así poder mejorar los tiempos de entrega relacionados con el almacenamiento.
Asimismo, las tecnologías de red también marchaban rápidamente a propuestas de virtualización, pero sin un rumbo claro.
Luego aparecieron en forma masiva las tecnologías de VIRTUALIZACION de capacidad de cómputo (VMware, equipos HIGH-END con capacidades
de virtualización de capacidad de cómputo, como ser IBM con LPARs, SUN con Zonas, KVM, etc.). La adopción de estas tecnologías permitió a las
organizaciones de TI principalmente la optimización de recursos y realizar un importante ahorro en infraestructura.
Es importante remarcar que en este punto, independientemente de que si una capacidad de cómputo o aplicación, está alojada en un
ambiente físico o virtualizado, la gestión del SERVICIO que corre allí se sigue realizando de la misma manera.
En términos de gestión de servicio, aparecen herramientas de AUTOMATIZACION, orientadas a los distintos SILOS que componen un servicio de
negocio. Estas herramientas son capaces de automatizar y controlar una serie de tareas que usualmente requieren de un alto esfuerzo (y tiempo)
administrativo y que en general ayudan a lubricar los procesos intermedios que se requieren para entregar un servicio a la compañía. Entre estos
“silos” podemos indicar:
4






Servers
Networking
Bases de Datos
Clientes de PC
Seguridad Informática
Etc.
Hasta aquí, las herramientas no superaban la prueba del proceso de entrega del servicio end-to-end, que todavía requería un esfuerzo grande de
coordinación; esa sensación de procesos fluidos no se pudo alcanzar en esta etapa. Las herramientas todavía requerían un alto grado de esfuerzo
manual, lo cual le quitaba muchos de los beneficios que la automatización ofrece.
Una etapa posterior permitió que estos silos trabajen ya en forma coordinada. Con la aparición de un ORQUESTADOR, las distintas piezas podían
trabajar en forma más eficiente, y entregar el servicio siguiendo un orden y permitiendo que el servicio se entregue en forma automatizada y completa,
al tiempo que se requiere. Sin importar el horario de implantación del servicio. La misma se puede realizar en forma ordenada, repetitiva y con una
mínima tasa de error. Esta capacidad se la denomina DATACENTER AUTOMATION.
Esa rara idea de “presionar un botón” y tener el SERVICIO de NEGOCIO funcionando de principios de la década del ’90 estaba cada vez más
cerca. Sólo faltaba la incorporación de algunas tecnologías que ya estaban en el mercado para poder completar el modelo de Cloud Computing.
Simplemente había que construir un portal de auto-gestión para definir los servicios, otro portal de vista al consumidor para que éste solicite los
servicios que necesita, agregarle una herramienta que me permita tarificar los consumos realizados, gestionar los niveles de utilización, y Listo!!!! Ya
tenemos un principio de Cloud Computing. (Aunque todavía falta mucho para llegar a las opciones actuales de implementación de Cloud Computing).
Uno de los elementos faltantes más importantes es la teoría; cómo se relacionan y se interconectan estos componentes, qué facilidades puedo
ofrecer, cómo es la mecánica y las reglas del servicio, etc. La misma se detalla en la siguiente sección.
Definición de Cloud Computing.
En los términos del laboratorio de Tecnología Informática del NIST (National Institute of Standards and Technology) de Estados Unidos, Cloud
computing es Cloud Computing es un modelo que permite el acceso a un pool de recursos compartidos (COMPUTO, RED,
ALMACENAMIENTO, APLICACIONES, etc.) bajo demanda, y que pueden ser rápidamente entregados y liberados, con un mínimo esfuerzo o
interacción con el proveedor del servicio. Este modelo de nube fomenta la disponibilidad, visibilidad, transparencia y seguridad, y está compuesto por:

5 características esenciales

3 modelos de servicio

4 modelos de despliegue
Características esenciales.
Estas características esenciales pueden ser expresadas en los siguientes términos:
1.
Auto-Servicio bajo demanda. El consumidor podrá aprovisionar recursos computacionales en forma unilateral, según lo requiera, y sin
requerimiento de interacción humana con el proveedor del servicio.
2.
Permitir el acceso desde la red (pública, privada, híbrida, comunitaria). Debido a que estos recursos están disponibles en la red y accedido
mediante mecanismos estándar, estos recursos deben estar disponibles para el consumidor según los términos seleccionados en la contratación
del servicio y los mismos podrán ser accedidos mediante plataformas heterogéneas que utilicen clientes de estos mecanismos estándar (por
ejemplo, teléfonos móviles, laptops, PDAs, desktops, etc.).
5
3.
Pooles de recursos según características de servicio. Los recursos del proveedor estarán agrupados para servir a múltiples consumidores (o
tenants), utilizando un modelo que le permita una separación segura una vez asignados. Estos recursos pueden ser físicos o virtuales y deben
tener todos componentes necesarios para brindar un SERVICIO COMPLETO, entendiéndose que éste podrá incluir recursos de
almacenamiento, conectividad, cómputo, elementos de software, políticas, métricas, etc. Estos mismos elementos deberán poder ser
liberados de la misma forma como fueron aprovisionados, conservando las pautas de seguridad. La ubicación de los recursos donde se basa el
servicio es prerrogativa del proveedor, y de cara al cliente existe una capa de abstracción en este sentido. Cabe recordar que a pesar de lo
mencionado, es requisito cumplir con los niveles de servicio mencionados.
4.
Capacidad de rápido crecimiento elástico. Las unidades de capacidad pueden ser rápida y fácilmente aprovisionadas (en algunos casos en
forma automática), escaladas (crecimiento) o liberadas. Para el consumidor, estos recursos suelen parecer ilimitados y pueden ser adquiridos en
cualquier cantidad en cualquier momento.
5.
Servicio MEDIDO. Los sistemas de la nube controlan de forma automática y optimizada la utilización de los recursos mediante mecanismos de
medición en algún nivel de abstracción apropiado para el tipo de servicio. La utilización de los recursos puede ser monitoreada, controlada y es
posible realizar reportes para ambas partes, a fin de establecer la facturación del servicio.
Modelos de Servicio
Estos modelos se refieren a qué tipo de servicio obtiene el consumidor, y cuáles son los componentes funcionales. Estos modelos están relacionados
con la cantidad de capas entregadas al mismo, relativo al modelo computacional.
Finalización del proceso.
Instalación aplicaciones adicionales.
Tareas Post instalación (parches,
configuraciones particulares, usuarios, etc.).
Adiciona a CMDB, lights on.
Bases de datos, web servers, otras
aplicaciones COTS o In-house, agentes de
monitoreo
Aplicación de parches, políticas,
configuraciones particulares, etc.
Instalación Sistema Operativo
Instalación sistemas operativo. Soporta
múltiples plataformas.
Infraestructura subyacente
Creación del container vacío, asignación de
redes y storage.
Cloud Infrastructure as a Service (IaaS):
La capacidad provista al consumidor es la de procesamiento, almacenamiento, memoria y networking, Adicionalmente requiere de otros recursos
fundamentales, como ser el sistema operativo. En este ambiente, entonces el consumidor puede desplegar y ejecutar cualquier software en forma
arbitraria y hacer uso del mismo bajo su costo y responsabilidad. El consumidor entonces, no tiene control sobre la infraestructura subyacente, pero sí
de todo lo demás, como ser sistema operativo, configuraciones, software adicional, accesos, etc. El consumidor es conocedor de la tecnología
informática, un administrador de sistemas.
Cloud Platform as a Service (PaaS):
La capacidad provista al consumidor de recursos, es la de realizar un despliegue de los elementos mencionados en el caso anterior, y adicionalmente
algún software de base, como ser una base de datos, un servidor de aplicación, etc. El consumidor entonces puede desplegar un aplicativo,
6
desarrollos propios que utilicen el software de base. El típico usuario para este tipo de opciones puede ser un desarrollador de sistemas
informáticos.
Cloud Software as a Service (SaaS):
La capacidad provista en este caso es la de una plataforma de software completa, con todos los elementos necesarios para correr un SERVICIO.
El caso de uso es un software que acepte multi-tenants, y cuya administración está totalmente a cargo del proveedor. El usuario final, un usuario de
negocios, utiliza la herramienta que se encuentra en la nube, como si fuera un aplicativo más en su panel de aplicaciones, sin preocuparse dónde
residen los recursos, u otros temas administrativos. Sólo paga el costo de acceso y/o uso del aplicativo.
Modelos de Despliegue
Desde el punto de vista del acceso y locación de los recursos computacionales, también podemos clasificar las redes en las siguientes clases:
Nube Privada:
Los recursos pertenecen totalmente a la compañía, aunque quizás distribuidos en distintas locaciones. La TOTALIDAD de los recursos están
disponibles para aprovisionar cualquier servicio de negocio, según sus características funcionales. Ya no se depende de la capacidad de un
determinado datacenter, sino que todos los datacenters funcionan de manera coordinada y complementaria, sin importar dónde se encuentran.
Nube pública:
Un ISP (Internet Service Provider) que renta infraestructura según el modelo de Cloud. Los recursos se encuentran en el datacenter del proveedor, el
cual percibirá una tarifa por el uso de la misma.
Nube Híbrida:
Una combinación de las clases anteriores, donde seguramente la mayoría de los servicios de negocios estarán en su nube privada, pero que
adicionalmente y si requiere capacidad adicional y elástica, algunos de estos servicios (o parte de ellos) podrán moverse a una nube pública.
Esto principalmente puede ayudar a cubrir una demanda adicional o pico de demanda estacional sin necesidad de adquirir y operar equipamiento
adicional (CAPEX+OPEX).
Nube Comunitaria:
Si bien este es un término conceptual, que significa una “nube privada”, pero visible desde un GRUPO de organizaciones que comparten un mismo
interés, la misma tiene más sentido en el ámbito académico o de ONGs y puede ser implantada en la práctica como un modelo de nube PRIVADA
extendida.
7
IT Admin /
Developers
Usuarios Finales.
Infraestructura
Serviciosescalablesy
“on demand”
IaaS
Developer
s
Plataforma
PaaS
Business
User
Aplicaciones
SaaS
Orientado a Servicios
Principios de Diseño
AltamenteAutomatizado
AltamenteVirtualizado
Niveles de Servicio
En todo datacenter podemos encontrar distintos tipos de infraestructura. Análogamente para cualquier recurso (almacenamiento, servidores, equipos
de networking, etc.), podremos con seguridad diferenciar entre recursos de alta, media y baja performance. Lo mismo podemos mencionar para
infraestructuras o disposiciones de recursos que me permitan ofrecer un alto, medio o bajo nivel de confiabilidad. Es por esto que en general los
servicios en la nube suelen clasificarse por NIVEL DE SERVICIO. Por lo mismo, un servicio PLATINUM tendrá una alta performance y un alto nivel de
confiabilidad, mientras que un servicio GOLD tendrá una performance media y un grado de confiabilidad acorde.
Similarmente ocurre para un nivel de servicio “Bronze”.
Otros proveedores, adicionalmente podrán variar el tamaño de tal o cual nivel de servicio, simplemente para atender un servicio de mayor cantidad de
transacciones, aunque respetando los niveles de servicio mencionados anteriormente. Algunos ejemplos pueden ser “pequeño”, “mediano” o “largo”.,
seguramente requiriendo cantidades superiores de recursos.
Si bien estos términos son arbitrarios, las prácticas actuales suelen asignar estos mismos esquemas para describir los niveles de servicio a
aprovisionar.
La utilización de uno u otro servicio estará directamente relacionado con el tipo de aplicación que correrá sobre esta infraestructura, y de la misma
manera será evaluado el costo del mismo.
8
Beneficios y Desventajas de Utilizar Cloud Computing.
Beneficios
Siempre es una buena práctica “ponerse en los zapatos” del cliente a la hora de entender lo que busca en un servicio de Cloud Computing. Una
primera respuesta obvia sería bajar los costos, principalmente de CAPEX (capital expenditure) asociada a la adquisición de equipamiento y agilizar el
despliegue de nuevos servicios de negocios, proveer gobernabilidad, transparencia y eficiencia.
Desde el punto de vista de una Nube Privada, podemos mencionar adicionalmente los siguientes beneficios:

Agilidad en el despliegue de nuevos servicios de negocios.

Mayor grado de utilización de la infraestructura.

Reducción de CAPEX y OPEX, al gestionar eficientemente y en forma automatizada la infraestructura.

Menor tasa de error en tareas de aprovisionamiento debido a la automatización del proceso.
Para el caso de una nube PUBLICA, o HIBRIDA el usuario final (consumidor) obtiene los siguientes beneficios:

Reducción significativa en costos
-

Infraestructura.
Costos fijos y predecibles.
Capex vs Opex.
Los servicios:

Son adquiridos on demand y devueltos al término de período de contratación.
Crecer elásticamente según demanda.
“Outsourcing”… con los beneficios pero sin la carga.

Servicios publicados y gestionados.
Desde el punto de vista de CAPEX, el licenciamiento de los elementos contratados bajo una tarifa fija, también hace mucho sentido, ya que como
podemos ver en la siguiente tabla, ciertos elementos son “tercerizados”, por lo cual los mismos estarán incluidos en la tarifa del servicio:
Licencia
IaaS
PaaS
SaaS
Infraestructura
Sistema Operativo
Software de Base
Middleware
Aplicación.
Resguardo
9
Desventajas de la Utilización de Cloud Computing
Como es el caso con casi todas las tecnologías, existen algunas desventajas en la utilización de este modelo para la gestión de servicios:








La centralización de las aplicaciones y el almacenamiento de los datos origina una dependencia de los proveedores de servicios.
La disponibilidad de las aplicaciones están desatadas a la disponibilidad de acceso a internet.
Los datos "sensibles" del negocio no residen en las instalaciones de las empresas por lo que podría generar un contexto de alta vulnerabilidad
para la sustracción o robo de información.
La confiabilidad de los servicios depende de la "salud" tecnológica y financiera de los proveedores de servicios en nube. Empresas emergentes o
alianzas entre empresas podrían crear un ambiente propicio para el monopolio y el crecimiento exagerado en los servicios.
La disponibilidad de servicios altamente especializados podría tardar meses o incluso años para que sean factibles de ser desplegados en la red.
La madurez funcional de las aplicaciones hace que continuamente estén modificando sus interfaces por lo cual la curva de aprendizaje en
empresas de orientación no tecnológica tenga unas pendientes pequeñas.
Seguridad. La información de la empresa debe recorrer diferentes nodos para llegar a su destino, cada uno de ellos (y sus canales) son un foco
de inseguridad. Si se utilizan protocolos seguros, HTTPS por ejemplo, la velocidad total disminuye debido a la sobrecarga que requieren estos
protocolos.
Escalabilidad a largo plazo. A medida que más usuarios empiecen a compartir la infraestructura de la nube, la sobrecarga en los servidores de
los proveedores aumentará, si la empresa no posee un esquema de crecimiento óptimo puede llevar a degradaciones en el servicio o jitter altos.
Es justo también mencionar, que algunas de estas desventajas también están presentes en la operación de datacenter, y en especial los modelos de
outsourcing, como ser los referidos a la escalabilidad, la velocidad de transferencia de datos, seguridad, etc.
Mecánica de la creación y solicitud de servicios.
Si bien los productos, estrategias y alcances de las ofertas de Cloud computing pueden variar, la mecánica de utilización se mantiene consistente
entre los distintos proveedores.
En esencia, el proveedor (interno o externo) define su CATALOGO DE SERVICIOS de manera tal que sea entendible para el usuario, y donde estén
especificadas las características del servicio junto con algunas descripciones, como ser el nivel de disponibilidad, performance y costo financiero. En el
caso de una nube pública, suelen ser las áreas de marketing junto con TI las que definen estos catálogos de servicios. Para el caso de las nubes
privadas, en general son sólo las áreas de TI, ya que tienden a automatizar casos de usos conocidos y repetitivos.
El catálogo de servicios actualizado es publicado en un portal de auto-gestión, el cual es presentado al consumidor, quien selecciona el “sabor” de
servicio que desea contratar. En este paso de selección, se suele también verificar las condiciones de pago, como ser el saldo de tarjeta de crédito,
línea de crédito del consumidor, o si es una red privada el centro de costos. Esta último proceso es opcional, o puede estar en otro lado del flujo.
10
Defini
TI o áreas de
ción
Negocio
Portal de
Autogestión
Catálogo
de
Servicios
Requ
erimi
ento
Cliente
Final
Decomision
delServicio
Service
Request
Management
Cloud
Storage
Network
Physical
Servers
Virtual
Servers
Orquestador
O
pe
ra
tio
ns
Performance
Management
Compliance
Management
Metering &
Chargeback
Una vez seleccionado el servicio (y aquí es donde comienzan las variaciones en las ofertas), desde el punto de vista de PROCESOS, el flujo debería
atravesar por un proceso de cambio, en el caso en que la compañía tenga uno. Después de todo, la solicitud de un servicio ES un pedido de cambio y
así debe ser tratado, aunque exista la posibilidad de definirlo como un cambio pre-aprobado o de registro.
En el caso de que el tipo de cambio (definido en la descripción del servicio) requiera aprobación, se deberá aguardar a que el CAB complete el
proceso de aprobación. En el caso de un cambio pre-aprobado o de registro, el proceso continúa inmediatamente luego de completar los tickets de
cambio requeridos.
Un tema de discusión no menor es la utilización de una CMDB para registrar el alta del servicio, sus componentes de infraestructura, localización,
configuración y dependencias. Es altamente aconsejable contar con este componente, dado que los beneficios funcionales a la hora de entender los
mapas de servicios, impactos ante caídas de componentes de infraestructura, documentación, etc. son extremadamente importantes.
Una vez terminado el proceso de registración, es la hora de la acción. En este punto entra en funcionamiento el ORQUESTADOR. Es esta
herramienta la que se ocupa de que todos los pasos necesarios para la creación del SERVICIO DE NEGOCIOS, con todos sus componentes activos
sean creados en el orden correcto y en los recursos que corresponden (después de todo, no quisiéramos aprovisionar un servicio crítico en un recurso
de almacenamiento que tiene un alto grado de posibilidad de falla).
En este punto nuevamente es importante recalcar que a la hora de considerar herramientas, las mismas puedan alcanzar, si no todos, la mayor
cantidad de elementos posibles dentro de su infraestructura, y lograr el mayor grado de automatización posible. Tenga en cuenta que los que no
puedan realizar estas herramientas, ALGUIEN (usualmente usted) deberá hacerlo luego en forma manual.
Aquí es importante mencionar que un servicio de negocios, no requiere solamente de piezas de hardware o software, sino que también hay que tener
en cuenta algunos elementos que usualmente son pasados por alto, o agregados luego en forma manual, como ser:


Métricas de negocio:
o
Monitores de transacciones,
o
Monitores de utilización,
o
Monitores de disponibilidad,
Monitores de configuración:
11






o
Compliance (cumplimiento regulatorio, en el caso de ser necesario).
o
Auditorías
Monitores de vulnerabilidades.
Monitores de logs,
Proceso de resguardo
Gestión de impacto (en coordinación con la CMDB).
Generación del mapa de servicios
Gestión financiera (alta del servicio en los sistemas de facturación)
Luego de la construcción del servicio, algunos fabricantes permiten agregar al portal de gestión (del cliente o del administrador) métricas, gráficos drilldown, etc. para facilitar una eficiente gestión del “DÍA 2”, o sea el período post-aprovisionamiento.
Consideraciones adicionales.
Si bien en la definición de Cloud Computing sólo se hace referencia a una forma de APROVISIONAR SERVICIOS y ponerlos A DISPOSICIÓN DEL
CONSUMIDOR, existen algunas consideraciones no menores que en general (y gracias al poder de marketing de ciertas marcas) suelen ser
ignoradas o disminuidas (hasta que el día a día demuestra lo errado de estas suposiciones).
El servicio de negocio ES un servicio de negocio.
El lector considerará obvia y redundante esta afirmación, pero si ponemos un poco de atención podremos entender que:

El objetivo primario de Cloud Computing es entregar un servicio que soportará el negocio

Como todo servicio, el mismo no se acaba al momento del aprovisionamiento inicial, sino que tiene un CICLO DE VIDA (inicio, cambios,
incidentes, mantenimiento, decomisión, mejoramiento continuo, etc.), donde intervienen distintos PROCESOS de principio a fin.
Arquitectura del servicio VS la Nube
Desde el punto de vista constructivo del servicio, es importante entender algunas limitaciones de las ofertas actuales.

El servicio debería ser independiente de la plataforma donde corre. Esto aplica más fuertemente para servicios tipo PaaS o SaaS y en menor
medida a IaaS.

Un servicio puede tener múltiples componentes o “capas”, exactamente de la misma manera que muy probablemente sus aplicaciones
comerciales corren en su datacenter,

La nube debería adaptarse a SUS servicios, y no sus servicios a la nube. Esto puede parecer trivial, pero es una de las principales causas por la
que las iniciativas de Cloud Computing públicas no pueden escalar al marco empresarial.
“Malos entendidos” sobre los modelos de servicio.
Nuevamente, lo que parece increíble o forzado se vuelve muy visible en cuanto se analiza (solamente un poquito).
PaaS y SaaS vs aprovisionamiento de software.
Una de las principales “malas prácticas” en la nube es cometida principalmente por los ISPs, que salen a vender servicios sin prestar mucha atención
a lo que están ofreciendo. Un ejemplo de esto es una mala concepción de que simplemente aprovisionando una base de datos o un application
server, realmente están cumpliendo con una propuesta de servicio de plataforma. En general esto es errado en un 90% de los casos.
La razón es sencilla si ponemos un poco de atención y conectamos con el concepto de “CICLO DE VIDA” de un servicio. Supongamos que un
consumidor (en general un desarrollador o un end user) pondrá su software o su servicio de negocio sobre una plataforma que él considerará como
12
“confiable” (dentro de los términos de nivel de servicio contratados), ya que éste era su objetivo primario al contratar un servicio de PaaS o SaaS sobre
una Nube.
Ahora, esto tiene una implicancia que muchos no consideran, que es JUSTAMENTE esta última suposición. Para mantener el nivel de servicio es
necesario garantizar mínimamente:

Que los diversos componentes trabajen correctamente entre sí (parches, versiones de SW, bugs, etc.).

Que los parches necesarios para garantizar este punto sean aplicados en forma periódica junto con los parches de seguridad y funcionalidad.

Que las configuraciones de los distintos componentes del servicio estén acordes a los niveles de servicio esperado.

Que el servicio pueda responder a los pedidos de cambio en forma ordenada y ágil.

Que el proveedor pueda realizar rápidamente auditorías y encontrar problemas ante reclamos sobre las capas de infraestructura bajo el dominio
de proveedor del servicio para facilitar el debug de las aplicaciones del consumidor.

Que si el servicio fue contratado por un período de tiempo el proveedor deberá asegurarse que el mismo sea des-aprovisionado al término de
ese período, según las condiciones contractuales.
Muchas máquinas virtuales hacen un servicio.
Como ya se habrá hecho evidente, un servicio de negocio es mucho más que un conjunto de máquinas virtuales sobre una red de datos.
Si nos pegamos al modelo de aprovisionamiento de múltiples recursos sobre la modalidad de IaaS o PaaS llegaremos a la conclusión que algo está
faltando. Después de todo, un servidor de aplicación por sí solo no puede hacer nada, lo mismo que una base de datos que no tiene quien aporte o
consuma datos. Ciertamente lo que está faltando es la forma de cómo estos componentes interactúan, por ejemplo las configuraciones necesarias
para el canal JDBC, listeners, seguridad, etc. En general estos detalles son realizados manualmente luego del aprovisionamiento.
Las capas en la Nube.
Ahora bien, en un modelo de servicios más o menos parecido a que usted puede tener en su datacenter, raramente un servidor de aplicaciones que
sirva al público en general estará localizado en su red privada, donde reside uno de los capitales más importantes de su compañía: sus datos.
Analicemos un poquito más en detalle esto, ya que aplica para todos los modelos de despliegue.
Cuando dijimos que es la nube la que tiene que adaptarse a su aplicación, y no viceversa, decimos que si la nube tiene que soportar los modelos de
arquitectura que sus aplicaciones presentan. De otra manera la cantidad de aplicaciones que se pueden manejar con la nube es reducida y el
proyecto entero de la nube cae en el olvido.
Un ejemplo de esto es un aplicación de 3 capas, por ejemplo de un servicio (digamos poco crítico), pero que impacta a un sistema de autogestión de
cara al público.
Usualmente la arquitectura es de múltiples capas, donde una capa por ejemplo estará detrás de una DMZ (usualmente el servidor donde corre el
portal de auto gestión de reclamos). Este impactará mediante algún canal jbdc o puerto de comunicaciones con sistemas de gestión internos, bases
de datos, etc., que difícilmente quisiéramos que estén al alcance del público en general en la misma red que el application server que soporta el
sistema de gestión de reclamos.
Como podemos ver, el término multi capas no aplica sólo a las piezas de software instaladas en un servidor, sino también sobre los OTROS
elementos de infraestructura, y la forma cómo éstos se interconectan. Después de todo, para lograr la comunicación entre las capas, seguramente sea
necesario abrir puertos en el firewall de la DMZ.
13
Adicionalmente, si recordamos que en la sección “Niveles de Servicio” hablamos que existen distintos “tamaños” de despliegue (small, médium, large)
y niveles de servicio, la interacción entre piezas puede incluir un Load Balancer, múltiples application servers funcionando en cluster, aprovisionar (y
mantener) múltiples servidores e infraestructura de red. Recién ahora estamos en condiciones de evaluar el verdadero significado (y las
complicaciones) que un servicio de Nube puede requerir, para poder “simplemente” apretar un botón y tener instantáneamente un SERVICIO.
Ejemplo de modelo de servicio “SMALL”
Mismo servicio “LARGE”
Seguridad y Marco Regulatorio en la Nube.
Seguridad
Al hablar de Seguridad, hablamos de unos de los aspectos principales relacionados con Cloud Computing. Después de todo, y tal como sucede con
un outsourcing de servicios informáticos, estamos poniendo las “llaves del reino” en manos de terceros. Adicionalmente, cuando la nube es pública,
también lo es la visibilidad de nuestro aplicativo que corre en la nube.
La seguridad debe ser considerada como un elemento fundamental cuando ponemos nuestra operación en manos de un tercero.
Algunos aspectos a tener en cuenta son:
La flexibilidad al momento del aprovisionamiento:
Se refiere a la capacidad de tener el control sobre el aprovisionamiento de punta a punta, de modo de que cuando se instala el sistema operativo, el
proceso pueda ser lo suficientemente inteligente para poder también seleccionar SOLO los servicios necesarios para correr esta función. Un ejemplo
de esto es el aprovisionamiento de una base de datos. Generalmente las estrategias de aprovisionamiento basadas en clones, suelen tener varias
“plantillas” y muchas veces estas plantillas están clasificadas según sistema operativo, donde luego se aprovisionarán las aplicaciones virtuales, casi
como un menú de restaurante.
El problema con este método (uno de ellos) es que dicha imagen puede ser utilizada de la misma forma para una base de datos, un servidor de correo
electrónico o un servidor de desarrollo de aplicaciones. La complicación es que al provenir de la misma plantilla, los servicios, paquetes instalados,
configuraciones y puertos son los mismos para todos los casos, y en general muy abarcativos. Después de todo, no es seguro tener un DNS server
instalado en una base de datos, ni un servicio de replicación de Active Directory en un web server al que tendrá acceso el público en general.
14
La capacidad de poder implementar plantillas de configuración
Inclusive cuando hablamos de PaaS o SaaS, para garantizar la seguridad de la base del servicio. Estas plantillas en general son definidas por
Seguridad Informática, o bien las mejores prácticas de la industria, la organización, etc.
La utilidad de una arquitectura multi capas.
En una arquitectura multi-capas, la seguridad se refuerza al poder tener quizás una zona privada y otra pública, donde la información importante
nunca está al alcance del público en general, sino que sólo puede ser accedida por el dueño del servicio, inclusive si la totalidad del servicio se
encuentra en la nube.
La flexibilidad de un proceso de cambios para gestionar los accesos.
Las diversas capas que componen el servicio requieren de una gestión de accesos, a la cual dependiendo el modelo de delivery el consumidor no
tendrá acceso. Dado que esta es una de las tareas más comunes durante el ciclo de vida del servicio, y abarca a varios componentes, la necesidad de
un proceso alineado que permita al gestionar fácilmente (en lo posible recurrir a la auto-gestión) es fundamental.
Cumplimiento regulatorio y auditorías
El término Compliance significa mantener un estado de control que satisfaga las normativas legales vigentes para un determinado tipo de servicio, en
función de varios factores, como ser la industria (financiera, gobierno, petróleo, telecomunicaciones, etc.), el país, u organismos que regulan la
actividad comercial. Es una “línea base” donde pueden existir multas, penalidades y hasta suspensión de actividades y cárcel (en serio, cárcel) en
caso de incumplimiento. Algunos ejemplos de esto es, por ejemplo en los EEUU SOX (recordemos ENRON), o PCI en la actividad crediticia, por citar
algunos. Si bien el proveedor puede no tener la necesidad de cumplir con estos estándares, probablemente SUS CLIENTES sí lo requieran, y debido
a que en una nube pública, es el ISP el que tiene acceso a las configuraciones que tienen que ser controladas. Esto puede generar un conflicto de
intereses, y causar que si usted originalmente necesitaba un PaaS, pues bien, tendrá que bajar a un IaaS y ocuparse de las configuraciones (y del
software de base) usted mismo.
Si bien las auditorías informáticas internas no suelen tener multas, las implicaciones son muy similares. Para tener un servicio de negocio en una
infraestructura de Cloud, es necesario que todos los elementos cumplan con las especificaciones de seguridad requeridas.
Otra capacidad que usualmente no es tenida en cuenta es la de poder establecer políticas de configuración (servicios deseables para una
determinada).
Adicionalmente la capacidad de compliance puede ser ofrecida como un servicio de valor agregado y ser cobrado en forma interna o externa según
corresponda.
Como actividad posterior a la puesta en marcha de un servicio de negocio es aconsejable tomar una “foto” de todos los componentes, en términos de
configuración (servidores, equipamiento de networking, storage, etc.). Esto, además de saludable, puede ayudar a determinar si el consumidor ha
modificado algún parámetro y puede ayudarnos a resolver disputas rápidamente al tener la capacidad de comparación contra esta “foto”.
Enfoque PROACTIVO vs. REACTIVO en la nube.
Otra capacidad relacionada con las auditorías y que puede tener un gran valor en cuanto el tiempo de recupero ante caídas de servicio (MTTR) es la
de AUTORREMEDIACION. Esta capacidad suele tener un impacto altamente positivo en la reducción del tiempo de resolución de problemas
(relacionados con elementos de configuración). Tal y como ocurre con los servicios de negocio tradicionales, es deseable poder detectar con rapidez y
de la misma forma poder solucionar los problemas, antes que causen caídas de servicio u otros problemas relacionados con la consistencia de datos.
Es por eso que la existencia de herramientas que puedan detectar TENDENCIAS, más que eventos y que puedan aportar un análisis predictivo es
muy útil para actuar rápidamente sobre los mismos, antes que ocasionen pérdida de datos o servicios.
Definición de las plataformas donde se prestará el servicio de Cloud.
En general los fabricantes (especialmente los de Hardware) suelen presentar soluciones tipo “big bang”, donde en algunos casos han llegado a vender
“racks” con la nube adentro. Si bien este enfoque es válido, y tiene sus beneficios (particularmente la facilidad de despliegue), también sería bueno
15
que pueda incluir los equipos que su organización ya tiene en su datacenter, y que probablemente quiera re-utilizar en vez de gastar dinero en nueva
infraestructura. Nuevamente, de nada sirve que se decida por un proyecto de Cloud, con el objetivo de bajar costos y aumentar la eficiencia, si al final
del día tendrá que comprar nuevo hardware en forma continua.
Es altamente deseable (especialmente para las alternativas de PaaS y SaaS) tener la posibilidad de reutilizar la infraestructura existente. Por ejemplo,
si tiene que aprovisionar una base de datos o un application server, éste podría estar en un servidor Linux, AIX, Solaris, HPUX, etc. No
necesariamente debe estar acotado a un tipo especial de virtualizador y sus capacidades propias. Lo mismo con la red y el almacenamiento.
Probablemente el servicio requiera afectar una variedad de componentes de red (firewalls, load balancers, equipos de WI-FI, etc.) que están en
locaciones remotas, o crear y asignar LUNs de un storage. Es importante poder interactuar con los dispositivos y modificar las configuraciones
necesarias para que el servicio llegue donde necesita llegar.
Todas estas consideraciones son imprescindibles para bajar los costos de propiedad (TCO) y poder poner en marcha un proyecto realista desde el
punto de vista económico y evitar el VENDOR-LOCK-DOWN, o sea la dependencia de un vendedor de plataformas
Asignación eficiente de recursos
Supongamos ahora que definimos un servicio de negocios según un modelo tradicional de aprovisionamiento. Tomemos por ejemplo un servidor de
Apache, Medium (en modo PaaS). Aquí realizamos la descripción del servicio desde el punto de vista del catálogo de servicios (costo, niveles de
servicio, paquetes de software, requerimientos, etc.). Sabemos por ejemplo que el mismo tiene los siguientes requerimientos:

2 unidades computacionales.

2gb de memoria

60 gb de disco performante.

Sistema operativo Windows 32 o 64 bits, Linux Red Hat, SUSE, etc.

Una red pública

Conexión con una máquina privada que tendrá la base de datos (IP a definir durante el proceso de aprovisionamiento)
Un enfoque tradicional tendría “cableado” o pre-definido los pasos de aprovisionamiento según un flujo (workflow) pre-establecido pero mayormente
estático.
por ejemplo:
1.
Aprovisionar 2 vCPU y 2 Gb en el ESX2
2.
Clonar VM Windows 32 bits
seguridad).
3.
Instalar Apache para Windows 32 bits.
4.
Asignar ethernet2, (que es la red pública)
5.
Que cumpla con SOX 404
6.
Luego “alguien” configurará los listeners y los canales JDBC, las reglas de firewall, etc.
(recuerde que este es un genérico, por lo que quizás tenga servicios instalados que pongan en riesgo su
A primera vista no hay nada incorrecto con este método.
Ahora suponga que en el servidor ESX2 no hay espacio para clonar una máquina, o que la máquina ESX2 no exista más, o que esté fuera de servicio
temporalmente, o que debido a que ya pasó un tiempo ahora existe otro servidor en el datacenter, pero el catálogo de servicios no fue actualizado….
16
Es importante entonces poder contar con una flexibilidad tal que permita tomar decisiones al momento del aprovisionamiento basados en varios
parámetros, pero que fundamentalmente disocie las definiciones de servicio con la infraestructura operativa, pero que al mismo tiempo permita tomar
decisiones sobre la locación de los recursos al momento de solicitar el servicio.
Un escenario deseable, poder elegir el servidor, más que por un requerimiento de sistema operativo, utilizar cualquier servidor (sin importar el sistema
operativo, para este caso) que cumpla con los requisitos del servicio, por ejemplo que soporte APACHE (que ya sabemos que puede ser en cualquier
plataforma de las arriba mencionadas, y/o que la infraestructura (equipos de red, plataforma de virtualización, etc.) esté “certificada” en SOX 404. De
allí en más, instalar el paquete correspondiente, no importa si se instala en ESX2, AIX1, o el servidor que se defina para esta tarea. Esta disociación,
entre un proceso de descripción general del servicio y otro proceso que analice la infraestructura disponible presentaría la ventaja adicional de que no
sería necesario ir modificando los flujos de aprovisionamiento en forma continua, ya que la decisión de la locación de los recursos se toma al momento
de aprovisionar el servicio, en base al conocimiento de la infraestructura existente.
Gestión de la capacidad.
Planeamiento de la demanda.
Otro de los puntos fundamentales para una iniciativa de Cloud Computing es el proceso de Gestión de Capacidad. De muchas maneras este proceso
es extremadamente crítico, debido a una de las características fundamentales de Cloud Computing: La capacidad de la auto-gestión del consumidor.
Esto puede llevar a perder el control del uso de los recursos y darnos cuenta que nos estamos quedando sin espacio disponible para aprovisionar
nuevos servicios.
Usualmente es cuando nos estamos quedando sin recursos que se ejecuta una compra al proveedor. Un punto a notar es que siempre es más caro ir
comprando componentes discretos de capacidad en forma continua y “urgente”, que planificar una compra importante en períodos de tiempo
discretos, por ejemplo cada 6 meses. Podríamos decir que el primer caso es altamente riesgoso debido a que la entrega puede retrasarse por
cuestiones de disponibilidad, y que también debido al carácter de “urgente” y las escasas cantidades por transacción, le será mucho más difícil pelear
descuentos.
También al momento de aprovisionar es extremadamente necesario saber si contamos con los recursos para cumplir con lo que el consumidor está
solicitando, y poder tomar decisiones sobre dónde aprovisionar este servicio en función del uso actual. Un ejemplo de esto, es el siguiente caso:
Supongamos que tenemos que aprovisionar 2 Unidades de Cómputo en una plataforma determinada virtualizada, que podría estar compuesta por
más de un servidor. Asimismo supongamos que la utilización de los servidores al día de HOY es como sigue:
Servidor
Uso
Ser1
80%
Ser2
50%
Ser3
20%
Sería deseable poder prever que el aprovisionamiento sobre alguna de las plataformas no impacte en forma negativa, a punto de afectar el servicio
que está corriendo previamente.
17
Gestión de compras con los proveedores de Hardware y Software.
Adicionalmente otra de las ventajas de manejar un proceso de capacidad, es la capacidad de saber si un determinado servicio podrá cumplir su ciclo
de vida (definido al tiempo de aprovisionamiento), teniendo en cuenta el comportamiento actual y a futuro. Por ejemplo, si un servicio fue solicitado el
día 1 con 2procesadores, 2 gb de memoria, 300 gb de disco, y una fecha de vencimiento de día 30, es muy deseable saber, en base al
comportamiento de este servicio, si cualquiera de estos recursos se agotarán antes de llegar al día de vencimiento y poder tomar las acciones
necesarias antes que la falta de capacidad afecte el servicio.
Casos de uso adicionales Cloud + Capacity
Algunos casos de uso posibles cuando se tiene el proceso de gestión de la capacidad alineado con Cloud Computing pueden ser:
Aviso de falta de capacidad al consumidor:
Si el análisis de uso actual indica que la capacidad reservada por un determinado consumidor no es suficiente para alcanzar la fecha de término del
servicio, es posible enviar un mail avisándole al mismo cuánta capacidad será necesaria para llegar a término, y gestionar el agregado de recursos en
forma automática.
Aprovisionamiento en el servidor menos utilizado.
Al momento de aprovisionar, es posible realizar un análisis de impacto sobre cada una de las plataformas y ver cuál es la que mejor puede contener
es servicio requerido.
Extensión de locación.
En caso que el consumidor desee ampliar el contrato de locación del servicio, es posible determinar la necesidad de recursos adicionales para cumplir
con la nueva fecha de caducidad del servicio.
18
Conclusiones
En un proceso de evaluación de una iniciativa de Cloud Computing, es fundamental considerar el PROCESO de Negocios propio de ésta. Desde el
punto de vista de costos, es importante considerar que existen dos tipos de costos; los directos y los indirectos, y a la hora de realizar la evaluación
financiera, es importante tener en cuenta ambos. Si las herramientas cubren sólo una parte de las capacidades necesarias, o si las cubre de manera
deficiente, éstas deberán ser cubiertas de alguna manera (usualmente manual), ya que el cliente paga por un servicio con tales características
estandarizadas. Cuanto más amplias las herramientas, menor será el trabajo manual posterior.
Cloud Computing es un proceso continuo, que tiene un ciclo de vida. El mismo se inicia en el aprovisionamiento, continúa con el proceso de cambios,
incidencias, parches, mejora continua, y finaliza con la decomisión del servicio. Para cada estadío de este ciclo, hay un proceso asociado.
De cara a la gestión de la nube, es necesario verla como la interacción de varios procesos de negocios, según lo descripto en la sección
“mecánica….”, y como tal, los procesos deberán poder comunicarse entre sí y funcionar en forma aceitada para que la entrega del servicio se realice
lo más rápido posible, sin perder la gobernabilidad del servicio. También se puede mencionar, que los procesos de la nube en general son un
subconjunto de los procesos de negocio de la compañía u organización, y de ninguna manera un proceso separado.
La plataforma de Cloud Computing contendrá SERVICIOS DE NEGOCIOS de nuestros consumidores. Como tal, están compuestos no sólo de las
piezas individuales de hardware y software, sino también por la inter-relación entre las mismas, y las métricas de negocio que sean definidas.
La seguridad es un elemento fundamental de los proyectos de Cloud Computing. Si no podemos generar confianza hacia nuestros consumidores, no
hay motivos para que ellos nos confíen sus servicios de negocio. Por el contrario, si su nivel de confianza aumenta, nuevos servicios serán mudados a
la Nube.
Las arquitecturas multi-capas son esenciales, ya que simplemente describen los servicios que como tales hoy corren en un datacenter, y no es
aceptable que se modifiquen para correr en la nube; por el contrario, la nube tiene que adaptarse a las arquitecturas de servicios de los consumidores,
y no viceversa.
La gestión de capacidad no sólo permite ser más eficiente en la gestión de las plataformas, en cuanto al aprovisionamiento inicial, sino que le permitirá
bajar costos de adquisición de hardware y software, al poder realizar compras periódicas, de volumen, y sin la urgencia, lo que le dará un poder de
negociación mayor con los proveedores de infraestructura.
19