Cloud Computing

Consideraciones generales

ndice
Mejores prcticas para lograr Cloud Computing ________________________________________________________________________________________ 4 Introduccin..........................................................................................................................................................................................................................................4 Objetivos. ..............................................................................................................................................................................................................................................4 Historia y Evolucin de Cloud Computing._____________________________________________________________________________________________ 4 Marco Histrico y Evolutivo.................................................................................................................................................................................................................4 Definicin de Cloud Computing. _____________________________________________________________________________________________________ 5 Caractersticas 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 pblica: ..............................................................................................................................................................................................................................7 Nube Hbrida: ..............................................................................................................................................................................................................................7 Nube Comunitaria:......................................................................................................................................................................................................................7 Niveles de Servicio................................................................................................................................................................................................................................8 Beneficios y Desventajas de Utilizar Cloud Computing. __________________________________________________________________________________ 9 Beneficios..............................................................................................................................................................................................................................................9 Desventajas de la Utilizacin de Cloud Computing ........................................................................................................................................................................ 10 Mecnica de la creacin 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 mquinas 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 configuracin...............................................................................................................................15 La utilidad de una arquitectura multi capas. ...............................................................................................................................................................15 La flexibilidad de un proceso de cambios para gestionar los accesos. .......................................................................................................................15 Cumplimiento regulatorio y auditoras ........................................................................................................................................................................................... 15 Enfoque PROACTIVO vs. REACTIVO en la nube. _______________________________________________________________________________________ 15 Definicin de las plataformas donde se prestar el servicio de Cloud.......................................................................................................................................... 15 Asignacin eficiente de recursos...................................................................................................................................................................................................... 16 Gestin de la capacidad. __________________________________________________________________________________________________________ 17 Planeamiento de la demanda. ......................................................................................................................................................................................................... 17 Gestin 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 Extensin de locacin. ..................................................................................................................................................................................................18 Conclusiones ___________________________________________________________________________________________________________________ 19

Document Information
Version: Created by: Last Modified on: Modified by: Armando Salas S. (Extension) 1.5 Mariano Grinfeld (BMC Software)

Mejores prcticas para lograr Cloud Computing

Introduccin
Cloud Computing se ha tornado en un trmino cada vez ms escuchado en las organizaciones que utilizan la tecnologa informtica para dar soporte a sus procesos de Negocio. Lejos de ser una moda, muchas de sus caractersticas pueden fcilmente ser traducidas a un aporte concreto en trminos de valor hacia el negocio.

Objetivos.
El objetivo de este documento es poder brindar un nivel de conocimiento suficiente, en cuanto a visin y terminologa que le permita al lector iniciar una conversacin sobre Cloud Computing y por sobre todo que le permita establecer sus propias estrategias, permitindole incluir en sta los elementos necesarios que garanticen el camino al xito de dicha iniciativa. El poder articular correctamente estos objetivos, segn nuestra experiencia resultar muy beneficioso para la toda la compaa, y en trminos 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 visin ms general y agnstica.

Historia y Evolucin de Cloud Computing.

Marco Histrico y Evolutivo.
El trmino Cloud Computing, o computacin en la nube obedece una idea que data de los primeros tiempos de Internet, donde la fantasa popular dictaba un gran ente que conecta todo con todo y que poda tener recursos infinitos. Y es en realidad un cambio de paradigma en la forma tradicional de ver la computacin desde el punto de vista organizacional y su relacin con el negocio. Tradicionalmente los servicios de negocios en sistemas abiertos se encontraban invariablemente contenidos en servidores fsicos, que tenan altos costos de mantenimiento, ocupaban una gran cantidad del preciado espacio en un datacenter y por sobre todo, los recursos subyacentes (almacenamiento, redes, etc.) dependan de distintos factores, como ser la capacidad de interconexin fsica (distintos conectores, tecnologas, distancia, y hasta cuntos tomacorrientes haba disponible). Lentamente comenzaron a aparecer en el mercado (aunque no siguiendo la cronologa de aparicin) tecnologas como la SAN (storage area network) que permita virtualizar el almacenamiento para poder asignar a un servicio capacidades de almacenamiento que otro servicio no requera ms y as poder mejorar los tiempos de entrega relacionados con el almacenamiento. Asimismo, las tecnologas de red tambin marchaban rpidamente a propuestas de virtualizacin, pero sin un rumbo claro. Luego aparecieron en forma masiva las tecnologas de VIRTUALIZACION de capacidad de cmputo (VMware, equipos HIGH-END con capacidades de virtualizacin de capacidad de cmputo, como ser IBM con LPARs, SUN con Zonas, KVM, etc.). La adopcin de estas tecnologas permiti a las organizaciones de TI principalmente la optimizacin de recursos y realizar un importante ahorro en infraestructura. Es importante remarcar que en este punto, independientemente de que si una capacidad de cmputo o aplicacin, est alojada en un ambiente fsico o virtualizado, la gestin del SERVICIO que corre all se sigue realizando de la misma manera. En trminos de gestin 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 compaa. Entre estos silos podemos indicar: Servers Networking

Bases de Datos Clientes de PC Seguridad Informtica Etc.

Hasta aqu, las herramientas no superaban la prueba del proceso de entrega del servicio end-to-end, que todava requera un esfuerzo grande de coordinacin; esa sensacin de procesos fluidos no se pudo alcanzar en esta etapa. Las herramientas todava requeran un alto grado de esfuerzo manual, lo cual le quitaba muchos de los beneficios que la automatizacin ofrece. Una etapa posterior permiti que estos silos trabajen ya en forma coordinada. Con la aparicin de un ORQUESTADOR, las distintas piezas podan trabajar en forma ms 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 implantacin del servicio. La misma se puede realizar en forma ordenada, repetitiva y con una mnima tasa de error. Esta capacidad se la denomina DATACENTER AUTOMATION.

Esa rara idea de presionar un botn y tener el SERVICIO de NEGOCIO funcionando de principios de la dcada del 90 estaba cada vez ms cerca. Slo faltaba la incorporacin de algunas tecnologas que ya estaban en el mercado para poder completar el modelo de Cloud Computing. Simplemente haba que construir un portal de auto-gestin 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 utilizacin, y Listo!!!! Ya tenemos un principio de Cloud Computing. (Aunque todava falta mucho para llegar a las opciones actuales de implementacin de Cloud Computing). Uno de los elementos faltantes ms importantes es la teora; cmo se relacionan y se interconectan estos componentes, qu facilidades puedo ofrecer, cmo es la mecnica y las reglas del servicio, etc. La misma se detalla en la siguiente seccin.

Definicin de Cloud Computing.

En los trminos del laboratorio de Tecnologa Informtica 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 rpidamente entregados y liberados, con un mnimo esfuerzo o interaccin con el proveedor del servicio. Este modelo de nube fomenta la disponibilidad, visibilidad, transparencia y seguridad, y est compuesto por: 5 caractersticas esenciales 3 modelos de servicio 4 modelos de despliegue

Caractersticas esenciales.
Estas caractersticas esenciales pueden ser expresadas en los siguientes trminos: 1. Auto-Servicio bajo demanda. El consumidor podr aprovisionar recursos computacionales en forma unilateral, segn lo requiera, y sin requerimiento de interaccin humana con el proveedor del servicio. 2. Permitir el acceso desde la red (pblica, privada, hbrida, comunitaria). Debido a que estos recursos estn disponibles en la red y accedido mediante mecanismos estndar, estos recursos deben estar disponibles para el consumidor segn los trminos seleccionados en la contratacin del servicio y los mismos podrn ser accedidos mediante plataformas heterogneas que utilicen clientes de estos mecanismos estndar (por ejemplo, telfonos mviles, laptops, PDAs, desktops, etc.).

3.

Pooles de recursos segn caractersticas de servicio. Los recursos del proveedor estarn agrupados para servir a mltiples consumidores (o tenants), utilizando un modelo que le permita una separacin segura una vez asignados. Estos recursos pueden ser fsicos o virtuales y deben tener todos componentes necesarios para brindar un SERVICIO COMPLETO, entendindose que ste podr incluir recursos de almacenamiento, conectividad, cmputo, elementos de software, polticas, mtricas, etc. Estos mismos elementos debern poder ser liberados de la misma forma como fueron aprovisionados, conservando las pautas de seguridad. La ubicacin de los recursos donde se basa el servicio es prerrogativa del proveedor, y de cara al cliente existe una capa de abstraccin en este sentido. Cabe recordar que a pesar de lo mencionado, es requisito cumplir con los niveles de servicio mencionados.

4.

Capacidad de rpido crecimiento elstico. Las unidades de capacidad pueden ser rpida y fcilmente aprovisionadas (en algunos casos en forma automtica), 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 automtica y optimizada la utilizacin de los recursos mediante mecanismos de medicin en algn nivel de abstraccin apropiado para el tipo de servicio. La utilizacin de los recursos puede ser monitoreada, controlada y es posible realizar reportes para ambas partes, a fin de establecer la facturacin del servicio.

Modelos de Servicio
Estos modelos se refieren a qu tipo de servicio obtiene el consumidor, y cules son los componentes funcionales. Estos modelos estn relacionados con la cantidad de capas entregadas al mismo, relativo al modelo computacional.

Finalizacin del proceso.

Adiciona a CMDB, lights on.

Instalacin aplicaciones adicionales.

Bases de datos, web servers, otras aplicaciones COTS o In-house, agentes de monitoreo

Tareas Post instalacin (parches, configuraciones particulares, usuarios, etc.).

Aplicacin de parches, polticas, configuraciones particulares, etc.

Instalacin Sistema Operativo

Instalacin sistemas operativo. Soporta mltiples plataformas.

Infraestructura subyacente

Creacin del container vaco, asignacin 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 dems, como ser sistema operativo, configuraciones, software adicional, accesos, etc. El consumidor es conocedor de la tecnologa informtica, 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 algn software de base, como ser una base de datos, un servidor de aplicacin, etc. El consumidor entonces puede desplegar un aplicativo,

desarrollos propios que utilicen el software de base. El tpico usuario para este tipo de opciones puede ser un desarrollador de sistemas informticos.

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 administracin 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 ms en su panel de aplicaciones, sin preocuparse dnde residen los recursos, u otros temas administrativos. Slo paga el costo de acceso y/o uso del aplicativo.

Modelos de Despliegue
Desde el punto de vista del acceso y locacin de los recursos computacionales, tambin podemos clasificar las redes en las siguientes clases:

Nube Privada:
Los recursos pertenecen totalmente a la compaa, aunque quizs distribuidos en distintas locaciones. La TOTALIDAD de los recursos estn disponibles para aprovisionar cualquier servicio de negocio, segn sus caractersticas 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 dnde se encuentran.

Nube pblica:
Un ISP (Internet Service Provider) que renta infraestructura segn 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 Hbrida:
Una combinacin de las clases anteriores, donde seguramente la mayora de los servicios de negocios estarn en su nube privada, pero que adicionalmente y si requiere capacidad adicional y elstica, algunos de estos servicios (o parte de ellos) podrn moverse a una nube pblica. 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 trmino conceptual, que significa una nube privada, pero visible desde un GRUPO de organizaciones que comparten un mismo inters, la misma tiene ms sentido en el mbito acadmico o de ONGs y puede ser implantada en la prctica como un modelo de nube PRIVADA extendida.

IT Admin / Developers

Usuarios Finales.

Developer s

Business User

Infraestructura

Plataforma

Aplicaciones

Servicios escalables y on demand

IaaS

PaaS

SaaS

Orientado a Servicios

Principios de Diseo

Altamente Automatizado Altamente Virtualizado

Niveles de Servicio
En todo datacenter podemos encontrar distintos tipos de infraestructura. Anlogamente 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 podrn variar el tamao 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 pequeo, mediano o largo., seguramente requiriendo cantidades superiores de recursos. Si bien estos trminos son arbitrarios, las prcticas actuales suelen asignar estos mismos esquemas para describir los niveles de servicio a aprovisionar. La utilizacin de uno u otro servicio estar directamente relacionado con el tipo de aplicacin que correr sobre esta infraestructura, y de la misma manera ser evaluado el costo del mismo.

Beneficios y Desventajas de Utilizar Cloud Computing.

Beneficios
Siempre es una buena prctica ponerse en los zapatos del cliente a la hora de entender lo que busca en un servicio de Cloud Computing. Una primera respuesta obvia sera bajar los costos, principalmente de CAPEX (capital expenditure) asociada a la adquisicin 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 utilizacin de la infraestructura. Reduccin de CAPEX y OPEX, al gestionar eficientemente y en forma automatizada la infraestructura. Menor tasa de error en tareas de aprovisionamiento debido a la automatizacin del proceso.

Para el caso de una nube PUBLICA, o HIBRIDA el usuario final (consumidor) obtiene los siguientes beneficios: Reduccin significativa en costos Infraestructura. Costos fijos y predecibles. Capex vs Opex.

Los servicios: Son adquiridos on demand y devueltos al trmino de perodo de contratacin. Crecer elsticamente segn 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, tambin hace mucho sentido, ya que como podemos ver en la siguiente tabla, ciertos elementos son tercerizados, por lo cual los mismos estarn incluidos en la tarifa del servicio: Licencia Infraestructura IaaS PaaS SaaS

Sistema Operativo

Software de Base

Middleware

Aplicacin.

Resguardo

Desventajas de la Utilizacin de Cloud Computing

Como es el caso con casi todas las tecnologas, existen algunas desventajas en la utilizacin de este modelo para la gestin de servicios: La centralizacin de las aplicaciones y el almacenamiento de los datos origina una dependencia de los proveedores de servicios. La disponibilidad de las aplicaciones estn desatadas a la disponibilidad de acceso a internet. Los datos "sensibles" del negocio no residen en las instalaciones de las empresas por lo que podra generar un contexto de alta vulnerabilidad para la sustraccin o robo de informacin. La confiabilidad de los servicios depende de la "salud" tecnolgica y financiera de los proveedores de servicios en nube. Empresas emergentes o alianzas entre empresas podran crear un ambiente propicio para el monopolio y el crecimiento exagerado en los servicios. La disponibilidad de servicios altamente especializados podra tardar meses o incluso aos para que sean factibles de ser desplegados en la red. La madurez funcional de las aplicaciones hace que continuamente estn modificando sus interfaces por lo cual la curva de aprendizaje en empresas de orientacin no tecnolgica tenga unas pendientes pequeas. Seguridad. La informacin 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 ms 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 tambin mencionar, que algunas de estas desventajas tambin estn presentes en la operacin de datacenter, y en especial los modelos de outsourcing, como ser los referidos a la escalabilidad, la velocidad de transferencia de datos, seguridad, etc.

Mecnica de la creacin y solicitud de servicios.

Si bien los productos, estrategias y alcances de las ofertas de Cloud computing pueden variar, la mecnica de utilizacin 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 estn especificadas las caractersticas del servicio junto con algunas descripciones, como ser el nivel de disponibilidad, performance y costo financiero. En el caso de una nube pblica, suelen ser las reas de marketing junto con TI las que definen estos catlogos de servicios. Para el caso de las nubes privadas, en general son slo las reas de TI, ya que tienden a automatizar casos de usos conocidos y repetitivos. El catlogo de servicios actualizado es publicado en un portal de auto-gestin, el cual es presentado al consumidor, quien selecciona el sabor de servicio que desea contratar. En este paso de seleccin, se suele tambin verificar las condiciones de pago, como ser el saldo de tarjeta de crdito, lnea de crdito 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

Defin
TI o reas de Negocio
Catlogo de Servicios

Portal de Autogestin

Requ
Cliente Final

Service Request Management

Decomision del Servicio

Cloud Storage Physical Servers Virtual Servers Orquestador O pe ra tio ns Performance Management Compliance Management Metering & Chargeback

Network

Una vez seleccionado el servicio (y aqu es donde comienzan las variaciones en las ofertas), desde el punto de vista de PROCESOS, el flujo debera atravesar por un proceso de cambio, en el caso en que la compaa tenga uno. Despus 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 descripcin del servicio) requiera aprobacin, se deber aguardar a que el CAB complete el proceso de aprobacin. En el caso de un cambio pre-aprobado o de registro, el proceso contina inmediatamente luego de completar los tickets de cambio requeridos. Un tema de discusin no menor es la utilizacin de una CMDB para registrar el alta del servicio, sus componentes de infraestructura, localizacin, configuracin 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 cadas de componentes de infraestructura, documentacin, etc. son extremadamente importantes. Una vez terminado el proceso de registracin, es la hora de la accin. En este punto entra en funcionamiento el ORQUESTADOR. Es esta herramienta la que se ocupa de que todos los pasos necesarios para la creacin del SERVICIO DE NEGOCIOS, con todos sus componentes activos sean creados en el orden correcto y en los recursos que corresponden (despus de todo, no quisiramos aprovisionar un servicio crtico 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 automatizacin 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 tambin hay que tener en cuenta algunos elementos que usualmente son pasados por alto, o agregados luego en forma manual, como ser: Mtricas de negocio: o Monitores de transacciones, o Monitores de utilizacin, o Monitores de disponibilidad, Monitores de configuracin:

11

o Compliance (cumplimiento regulatorio, en el caso de ser necesario). o Auditoras Monitores de vulnerabilidades. Monitores de logs, Proceso de resguardo Gestin de impacto (en coordinacin con la CMDB). Generacin del mapa de servicios Gestin financiera (alta del servicio en los sistemas de facturacin)

Luego de la construccin del servicio, algunos fabricantes permiten agregar al portal de gestin (del cliente o del administrador) mtricas, grficos drilldown, etc. para facilitar una eficiente gestin del DA 2, o sea el perodo post-aprovisionamiento.

Consideraciones adicionales.
Si bien en la definicin de Cloud Computing slo se hace referencia a una forma de APROVISIONAR SERVICIOS y ponerlos A DISPOSICIN 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 da a da demuestra lo errado de estas suposiciones).

El servicio de negocio ES un servicio de negocio.

El lector considerar obvia y redundante esta afirmacin, pero si ponemos un poco de atencin 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, decomisin, 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 debera ser independiente de la plataforma donde corre. Esto aplica ms fuertemente para servicios tipo PaaS o SaaS y en menor medida a IaaS. Un servicio puede tener mltiples componentes o capas, exactamente de la misma manera que muy probablemente sus aplicaciones comerciales corren en su datacenter, La nube debera 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 pblicas no pueden escalar al marco empresarial.

Malos entendidos sobre los modelos de servicio.

Nuevamente, lo que parece increble 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 prcticas en la nube es cometida principalmente por los ISPs, que salen a vender servicios sin prestar mucha atencin a lo que estn ofreciendo. Un ejemplo de esto es una mala concepcin de que simplemente aprovisionando una base de datos o un application server, realmente estn cumpliendo con una propuesta de servicio de plataforma. En general esto es errado en un 90% de los casos. La razn es sencilla si ponemos un poco de atencin 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 trminos 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 suposicin. Para mantener el nivel de servicio es necesario garantizar mnimamente: 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 peridica junto con los parches de seguridad y funcionalidad. Que las configuraciones de los distintos componentes del servicio estn 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 rpidamente auditoras 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 perodo de tiempo el proveedor deber asegurarse que el mismo sea des-aprovisionado al trmino de ese perodo, segn las condiciones contractuales.

Muchas mquinas virtuales hacen un servicio.

Como ya se habr hecho evidente, un servicio de negocio es mucho ms que un conjunto de mquinas virtuales sobre una red de datos. Si nos pegamos al modelo de aprovisionamiento de mltiples recursos sobre la modalidad de IaaS o PaaS llegaremos a la conclusin que algo est faltando. Despus de todo, un servidor de aplicacin 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 cmo estos componentes interactan, 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 ms o menos parecido a que usted puede tener en su datacenter, raramente un servidor de aplicaciones que sirva al pblico en general estar localizado en su red privada, donde reside uno de los capitales ms importantes de su compaa: sus datos. Analicemos un poquito ms 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 aplicacin, 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 aplicacin de 3 capas, por ejemplo de un servicio (digamos poco crtico), pero que impacta a un sistema de autogestin de cara al pblico. Usualmente la arquitectura es de mltiples capas, donde una capa por ejemplo estar detrs de una DMZ (usualmente el servidor donde corre el portal de auto gestin de reclamos). Este impactar mediante algn canal jbdc o puerto de comunicaciones con sistemas de gestin internos, bases de datos, etc., que difcilmente quisiramos que estn al alcance del pblico en general en la misma red que el application server que soporta el sistema de gestin de reclamos. Como podemos ver, el trmino multi capas no aplica slo a las piezas de software instaladas en un servidor, sino tambin sobre los OTROS elementos de infraestructura, y la forma cmo stos se interconectan. Despus de todo, para lograr la comunicacin entre las capas, seguramente sea necesario abrir puertos en el firewall de la DMZ.

13

Adicionalmente, si recordamos que en la seccin Niveles de Servicio hablamos que existen distintos tamaos de despliegue (small, mdium, large) y niveles de servicio, la interaccin entre piezas puede incluir un Load Balancer, mltiples application servers funcionando en cluster, aprovisionar (y mantener) mltiples servidores e infraestructura de red. Recin ahora estamos en condiciones de evaluar el verdadero significado (y las complicaciones) que un servicio de Nube puede requerir, para poder simplemente apretar un botn y tener instantneamente 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. Despus de todo, y tal como sucede con un outsourcing de servicios informticos, estamos poniendo las llaves del reino en manos de terceros. Adicionalmente, cuando la nube es pblica, tambin lo es la visibilidad de nuestro aplicativo que corre en la nube.

La seguridad debe ser considerada como un elemento fundamental cuando ponemos nuestra operacin 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 tambin seleccionar SOLO los servicios necesarios para correr esta funcin. 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 estn clasificadas segn sistema operativo, donde luego se aprovisionarn las aplicaciones virtuales, casi como un men de restaurante. El problema con este mtodo (uno de ellos) es que dicha imagen puede ser utilizada de la misma forma para una base de datos, un servidor de correo electrnico o un servidor de desarrollo de aplicaciones. La complicacin 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. Despus de todo, no es seguro tener un DNS server instalado en una base de datos, ni un servicio de replicacin de Active Directory en un web server al que tendr acceso el pblico en general.

14

La capacidad de poder implementar plantillas de configuracin

Inclusive cuando hablamos de PaaS o SaaS, para garantizar la seguridad de la base del servicio. Estas plantillas en general son definidas por Seguridad Informtica, o bien las mejores prcticas de la industria, la organizacin, etc.

La utilidad de una arquitectura multi capas.

En una arquitectura multi-capas, la seguridad se refuerza al poder tener quizs una zona privada y otra pblica, donde la informacin importante nunca est al alcance del pblico en general, sino que slo puede ser accedida por el dueo 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 gestin de accesos, a la cual dependiendo el modelo de delivery el consumidor no tendr acceso. Dado que esta es una de las tareas ms comunes durante el ciclo de vida del servicio, y abarca a varios componentes, la necesidad de un proceso alineado que permita al gestionar fcilmente (en lo posible recurrir a la auto-gestin) es fundamental.

Cumplimiento regulatorio y auditoras

El trmino Compliance significa mantener un estado de control que satisfaga las normativas legales vigentes para un determinado tipo de servicio, en funcin de varios factores, como ser la industria (financiera, gobierno, petrleo, telecomunicaciones, etc.), el pas, u organismos que regulan la actividad comercial. Es una lnea base donde pueden existir multas, penalidades y hasta suspensin de actividades y crcel (en serio, crcel) 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 estndares, probablemente SUS CLIENTES s lo requieran, y debido a que en una nube pblica, 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 auditoras informticas 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 polticas de configuracin (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 segn corresponda. Como actividad posterior a la puesta en marcha de un servicio de negocio es aconsejable tomar una foto de todos los componentes, en trminos de configuracin (servidores, equipamiento de networking, storage, etc.). Esto, adems de saludable, puede ayudar a determinar si el consumidor ha modificado algn parmetro y puede ayudarnos a resolver disputas rpidamente al tener la capacidad de comparacin contra esta foto.

Enfoque PROACTIVO vs. REACTIVO en la nube.

Otra capacidad relacionada con las auditoras y que puede tener un gran valor en cuanto el tiempo de recupero ante cadas de servicio (MTTR) es la de AUTORREMEDIACION. Esta capacidad suele tener un impacto altamente positivo en la reduccin del tiempo de resolucin de problemas (relacionados con elementos de configuracin). 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 cadas de servicio u otros problemas relacionados con la consistencia de datos. Es por eso que la existencia de herramientas que puedan detectar TENDENCIAS, ms que eventos y que puedan aportar un anlisis predictivo es muy til para actuar rpidamente sobre los mismos, antes que ocasionen prdida de datos o servicios.

Definicin 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 vlido, y tiene sus beneficios (particularmente la facilidad de despliegue), tambin sera bueno

15

que pueda incluir los equipos que su organizacin 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 da 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 podra 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 estn 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 econmico y evitar el VENDOR-LOCK-DOWN, o sea la dependencia de un vendedor de plataformas

Asignacin eficiente de recursos

Supongamos ahora que definimos un servicio de negocios segn un modelo tradicional de aprovisionamiento. Tomemos por ejemplo un servidor de Apache, Medium (en modo PaaS). Aqu realizamos la descripcin del servicio desde el punto de vista del catlogo 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 pblica Conexin con una mquina privada que tendr la base de datos (IP a definir durante el proceso de aprovisionamiento)

Un enfoque tradicional tendra cableado o pre-definido los pasos de aprovisionamiento segn un flujo (workflow) pre-establecido pero mayormente esttico. por ejemplo: 1. 2. Aprovisionar 2 vCPU y 2 Gb en el ESX2 Clonar VM Windows 32 bits seguridad). (recuerde que este es un genrico, por lo que quizs tenga servicios instalados que pongan en riesgo su

3. 4. 5. 6.

Instalar Apache para Windows 32 bits. Asignar ethernet2, (que es la red pblica) Que cumpla con SOX 404 Luego alguien configurar los listeners y los canales JDBC, las reglas de firewall, etc.

A primera vista no hay nada incorrecto con este mtodo. Ahora suponga que en el servidor ESX2 no hay espacio para clonar una mquina, o que la mquina ESX2 no exista ms, 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 catlogo 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 parmetros, pero que fundamentalmente disocie las definiciones de servicio con la infraestructura operativa, pero que al mismo tiempo permita tomar decisiones sobre la locacin de los recursos al momento de solicitar el servicio. Un escenario deseable, poder elegir el servidor, ms 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 virtualizacin, etc.) est certificada en SOX 404. De all en ms, instalar el paquete correspondiente, no importa si se instala en ESX2, AIX1, o el servidor que se defina para esta tarea. Esta disociacin, entre un proceso de descripcin general del servicio y otro proceso que analice la infraestructura disponible presentara la ventaja adicional de que no sera necesario ir modificando los flujos de aprovisionamiento en forma continua, ya que la decisin de la locacin de los recursos se toma al momento de aprovisionar el servicio, en base al conocimiento de la infraestructura existente.

Gestin de la capacidad.
Planeamiento de la demanda.
Otro de los puntos fundamentales para una iniciativa de Cloud Computing es el proceso de Gestin de Capacidad. De muchas maneras este proceso es extremadamente crtico, debido a una de las caractersticas fundamentales de Cloud Computing: La capacidad de la auto-gestin 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 ms caro ir comprando componentes discretos de capacidad en forma continua y urgente, que planificar una compra importante en perodos de tiempo discretos, por ejemplo cada 6 meses. Podramos decir que el primer caso es altamente riesgoso debido a que la entrega puede retrasarse por cuestiones de disponibilidad, y que tambin debido al carcter de urgente y las escasas cantidades por transaccin, le ser mucho ms difcil pelear descuentos. Tambin 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 dnde aprovisionar este servicio en funcin del uso actual. Un ejemplo de esto, es el siguiente caso: Supongamos que tenemos que aprovisionar 2 Unidades de Cmputo en una plataforma determinada virtualizada, que podra estar compuesta por ms de un servidor. Asimismo supongamos que la utilizacin de los servidores al da de HOY es como sigue: Servidor Ser1 Ser2 Ser3 Uso 80% 50% 20%

Sera 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

Gestin 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 da 1 con 2procesadores, 2 gb de memoria, 300 gb de disco, y una fecha de vencimiento de da 30, es muy deseable saber, en base al comportamiento de este servicio, si cualquiera de estos recursos se agotarn antes de llegar al da 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 gestin de la capacidad alineado con Cloud Computing pueden ser:

Aviso de falta de capacidad al consumidor:

Si el anlisis de uso actual indica que la capacidad reservada por un determinado consumidor no es suficiente para alcanzar la fecha de trmino del servicio, es posible enviar un mail avisndole al mismo cunta capacidad ser necesaria para llegar a trmino, y gestionar el agregado de recursos en forma automtica.

Aprovisionamiento en el servidor menos utilizado.

Al momento de aprovisionar, es posible realizar un anlisis de impacto sobre cada una de las plataformas y ver cul es la que mejor puede contener es servicio requerido.

Extensin de locacin.
En caso que el consumidor desee ampliar el contrato de locacin 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 evaluacin 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 evaluacin financiera, es importante tener en cuenta ambos. Si las herramientas cubren slo una parte de las capacidades necesarias, o si las cubre de manera deficiente, stas debern ser cubiertas de alguna manera (usualmente manual), ya que el cliente paga por un servicio con tales caractersticas estandarizadas. Cuanto ms 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, contina con el proceso de cambios, incidencias, parches, mejora continua, y finaliza con la decomisin del servicio. Para cada estado de este ciclo, hay un proceso asociado. De cara a la gestin de la nube, es necesario verla como la interaccin de varios procesos de negocios, segn lo descripto en la seccin mecnica., y como tal, los procesos debern poder comunicarse entre s y funcionar en forma aceitada para que la entrega del servicio se realice lo ms rpido posible, sin perder la gobernabilidad del servicio. Tambin se puede mencionar, que los procesos de la nube en general son un subconjunto de los procesos de negocio de la compaa u organizacin, y de ninguna manera un proceso separado. La plataforma de Cloud Computing contendr SERVICIOS DE NEGOCIOS de nuestros consumidores. Como tal, estn compuestos no slo de las piezas individuales de hardware y software, sino tambin por la inter-relacin entre las mismas, y las mtricas 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 confen sus servicios de negocio. Por el contrario, si su nivel de confianza aumenta, nuevos servicios sern 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 gestin de capacidad no slo permite ser ms eficiente en la gestin de las plataformas, en cuanto al aprovisionamiento inicial, sino que le permitir bajar costos de adquisicin de hardware y software, al poder realizar compras peridicas, de volumen, y sin la urgencia, lo que le dar un poder de negociacin mayor con los proveedores de infraestructura.

19