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