Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
SELF-ORGANISING, SELF-MANAGING
HETEROGENEOUS CLOUD
The CloudLightning Service Description Language
CloudLightning Gateway
Service – API & Definition
Language
Marian Neagul / marian@ieat.ro
Institute e-Austria / www.ieat.r...
Overview
• A different perspective to the CloudLightning Architecture
• The CloudLightning Gateway Service
Main Functiona...
The CloudLightning Architecture
Gateway Service Perspective
GatewayService
Gateway Service UI
OrchestratorEngine
Blueprint...
The CloudLightning Architecture
Gateway Service Perspective
GatewayService
Operator
CSP
Acquire/Deploy Blueprint
Register ...
CloudLightning Gateway Service
Overall functionality
• Represents the interface between the Operator and the
Self Organizi...
CloudLightning Gateway Service
Gateway UI (Web Console)
• The Web Console is aimed to provide
user interface for Blueprin...
CloudLightning Gateway Service
Catalogues
• We have several kinds:
Service Catalogues: holding service definitions provid...
CloudLightning Gateway Service
Service Decomposition Engine
• The Service Decomposition Engine is the component of
the Gat...
CloudLightning Gateway Service
Apache Brooklyn
• We build upon the Apache incubated Brooklyn Project
We extend it to supp...
CloudLightning Gateway Service
Service Definition Language
• As previously mentioned represents the main construct
for spe...
Structure of the Blueprint / SDL
The API view
Example Blueprint / SDL
location: cloudlightning-1:ro.ieat
name: My Cool Raytracing Solution
requirements:
- ....
services...
Implementation Schedule
• Specification of the requirements for the Service
Definition Language is expected to be formulat...
Questions ?
THANK YOU
Marian Neagul
Upcoming SlideShare
Loading in …5
×

CloudLightning Service Description Language

381 views

Published on

Dr Marian Neagul (Institute e-Austria Timisoara, Romania) presented the CloudLightning Service Description Language at the Fifth National Conference on Cloud Computing and Commerce in Dublin City University on 12th April 2016.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

CloudLightning Service Description Language

  1. 1. SELF-ORGANISING, SELF-MANAGING HETEROGENEOUS CLOUD The CloudLightning Service Description Language
  2. 2. CloudLightning Gateway Service – API & Definition Language Marian Neagul / marian@ieat.ro Institute e-Austria / www.ieat.ro Timișoara / Romania
  3. 3. Overview • A different perspective to the CloudLightning Architecture • The CloudLightning Gateway Service Main Functionalities API Model • The CloudLightning Service Description Language
  4. 4. The CloudLightning Architecture Gateway Service Perspective GatewayService Gateway Service UI OrchestratorEngine Blueprint Decomposition Engine Apache Brooklyn ServiceCatalogues
  5. 5. The CloudLightning Architecture Gateway Service Perspective GatewayService Operator CSP Acquire/Deploy Blueprint Register Offers Catalogues Brooklyn Service Decomposition Console/UI QueryyDeploy SelfOrganizingCloud Deploy Services Trigger Self Organization
  6. 6. CloudLightning Gateway Service Overall functionality • Represents the interface between the Operator and the Self Organizing Cloud The Gateway Service also serves the CSP, allowing him to register new blueprints (definitions of applications) and services • Abstracts the inner workings of the self organizing system (effectively hiding most of the internal details like vRacks, Cells, etc) • It’s functionality is wrapped around a custom tailored Service Definition Language ☞ What is an application ?
  7. 7. CloudLightning Gateway Service Gateway UI (Web Console) • The Web Console is aimed to provide user interface for Blueprint definition service service registration and, most importantly, for triggering the deployment of the blueprint  • The Console builds upon the capabilities of the Brooklyn component This allows us to reuse already existing Apache Brooklyn features • It aims to hide the intricacies of the self organization systems
  8. 8. CloudLightning Gateway Service Catalogues • We have several kinds: Service Catalogues: holding service definitions provided by the CSP or, eventually, by the Operator Blueprint Catalogues: holding blueprint definitions (compositions of registered services or blueprints) • The catalogues are consumed by: The decomposition engine, aiming to optimize the service choice according to various criteria The console, for presentation and management purposes The Apache Brooklyn component for triggering the effective service orchestration and deployment
  9. 9. CloudLightning Gateway Service Service Decomposition Engine • The Service Decomposition Engine is the component of the Gateway Service responsible with the interaction with the self organizing system • It’s main function: Transforming abstract specifications to concrete implementations according to user requirements; This is achieved by tight integration with the self organizing system; The Decomposition Engine is the facilitator for achieving some of CloudLightning main aspirations: as for example energy efficiency or performance
  10. 10. CloudLightning Gateway Service Apache Brooklyn • We build upon the Apache incubated Brooklyn Project We extend it to support our concept of “meta” services We extend it in order to properly interact with the Service Decomposition Engine • Brooklyn's Blueprint language serves as the “backbone” of the CloudLightning Service Definition Language We add custom constructs for referencing “meta” services and specifying service requirements ☞
  11. 11. CloudLightning Gateway Service Service Definition Language • As previously mentioned represents the main construct for specifying application and service requirements • Is build on top of the Apache Brooklyn Blueprint Extended to support meta services Extended to support the specification of requirements at various levels: service or application level
  12. 12. Structure of the Blueprint / SDL The API view
  13. 13. Example Blueprint / SDL location: cloudlightning-1:ro.ieat name: My Cool Raytracing Solution requirements: - .... services: - type: io.cloudlightning.entity.meta.RayTracingComputeService id: RayTracingComputeService brooklyn.config: cloudlightning.soso.min_performance: 100gflops cloudlightning.soso.placement-policy: same-broadcast-domain cloudlightning.config: hints: prefer: ['GPU', "FPGA", "CPU"] # List of preferences requirements: ... - type: io.cloudlightning.entity.meta.raytracing.controller id: raytracingController brooklyn.config: messos_cluster.head_node: $brooklyn:component("RayTracingComputeService")
  14. 14. Implementation Schedule • Specification of the requirements for the Service Definition Language is expected to be formulated by end of M15 (End of April 2016) • The complete implementation of the Gateway Service is expected by end of M24 (February 2017) We plan to push relevant patches upstream (Brooklyn)
  15. 15. Questions ?
  16. 16. THANK YOU Marian Neagul

×