Plataforma Open Source para múltiples proveedores cloud.

Presentación del tema: "Plataforma Open Source para múltiples proveedores cloud."— Transcripción de la presentación:

1 Plataforma Open Source para múltiples proveedores cloud.
Workshop Cloud Computing y Matemáticas Plataforma Open Source para múltiples proveedores cloud. Gorka Esnal Tecnalia Research & Innovation

2 Definir requerimiento
Cloud provider lock-in Definir requerimiento Buscar proveedor Implementar 1. Definir las necesidades de la aplicación 2. Buscar el proveedor “cloud” que mejor se adapta a las necesidades de la apli- cación. 3. Implementar la aplicación utilizando el conector del proveedor seleccionado.

3 Cloud provider lock-in
Aplicación desarrollada utilizando la API que ofrece el proveedor seleccionado Proveedor “A”

4 Definir requerimiento
Cloud provider lock-in Definir requerimiento Buscar proveedor Implementar 4. Surgen nuevas necesidades que el actual proveedor no puede satisfacer 5. Aparecen nuevos y mejores proveedores “cloud” en el mercado.

5 Cloud provider lock-in
Proveedor “B” Proveedor “A” Proveedor “C”

6 Cloud provider lock-in
mOSAIC ... Proveedor “A” Proveedor “B” Proveedor “C”

7 Objetivos de la API de mOSAIC
Conectar recursos y componentes cloud de manera sencilla e independiente a la tecnología utilizada. Abstraer el acceso a los recursos cloud. En la medida de lo posible es independiente al lenguaje de programación utilizado. Adquirir recursos de diversos proveedores cloud (Cloud federation).

8 Conceptos básicos Cloud Building Block: Cualquier entidad identificable dentro de un entorno cloud. Un Building Block puede ser tanto un recurso cloud controlado por un proveedor cloud, como un Cloud Component. Cloud Component: es un elemento desarrollado y controlado por el usuario, que exhibe un comportamiento bien definido, implementa y expone funcionalidades a otros componentes, y sus instancias se ejecutan bajo entornos cloud que donde pueden consumir recursos cloud. Cloud Application: un conjunto de Building Blocks conectados entre sí.

9 Arquitectura de mOSAIC
Cloudlet API: Aunque el desarrollador ya puede acceder a recursos cloud utilizando las capas inferiores, es necesario adaptar los desarrollos a un entorno cloud. Connector API: Aquí es donde mOSAIC nos proporciona el segundo nivel de uniformidad de los paradigmas de programación, ya que todas las implementaciones de la API tienen similares jerarquías de clase, firmas de métodos y patrones. Driver API: Wrapper de la API nativa. Proporciona el primer nivel de uniformidad: todos los recursos del mismo tipo se exportan mediante la misma interfaz. Capa más baja: Protocolo nativo de los recursos (servicios Web, RPC, ...) o API ofrecido por los proveedores Cloud para ciertos lenguajes de programación.

10 ¿Cómo verifico que tengo
La nube es como una tienda de ordenadores. Pero ... ¿Cómo verifico que tengo lo que he pedido? ¿Dónde compro? ¿Cuál compro? ¿Cómo pregunto?

11 Delegamos estas tareas al Cloud Agency
¿Cuál Compro? ¿Dónde compro? Delegamos estas tareas al Cloud Agency Las funcionalidades que ofrece son: Negociar con los proveedores Aprovisionar recursos cloud Benchmarking continuo Monitorización Reconfiguración de los recursos cloud

12 ¡ Necesitamos utilizar
¿Cómo pregunto? ¡ Necesitamos utilizar un lenguaje común ! $%&#” شعي ٣ څٺ Proveedor “A” Cloud Ontology פחס һף Cloud Agency Proveedor “B”

13 mOSAIC partners www.mosaic-cloud.eu Second University of Naples, Italy
Institute e-Austria Timisoara, Romania European Space Agency, France Terradue SRL, Italy AITIA International Informatics, Hungary Tecnalia, Spain

14 Gracias ! Gorka Esnal