Presentation is loading. Please wait.

Presentation is loading. Please wait.

Developing Applications for Cloud Computing Platforms Jeremy Cohen Department of Computing Imperial College London The Influence and Impact of Web 2.0.

Similar presentations


Presentation on theme: "Developing Applications for Cloud Computing Platforms Jeremy Cohen Department of Computing Imperial College London The Influence and Impact of Web 2.0."— Presentation transcript:

1 Developing Applications for Cloud Computing Platforms Jeremy Cohen Department of Computing Imperial College London The Influence and Impact of Web 2.0 on e-Research Infrastructure, Applications and Users NeSC, Edinburgh 24th March 2009

2 Why migrate my apps to the Cloud?Why migrate my apps to the Cloud? Application / Usage profilesApplication / Usage profiles ChallengesChallenges Client / Server-side TechnologiesClient / Server-side Technologies ExamplesExamples Outline

3 Need more compute power / storage than easily accessible locally / free up local resourcesNeed more compute power / storage than easily accessible locally / free up local resources Avoid costs/problems of local resource hostingAvoid costs/problems of local resource hosting Power, cooling, space, maintenance, … Power, cooling, space, maintenance, … Flexibility / ScalabilityFlexibility / Scalability Discontinuous demandDiscontinuous demand Rapid growth / declineRapid growth / decline Provisioning resources in-house takes too longProvisioning resources in-house takes too long Why migrate?

4 Pay only for what you usePay only for what you use Local networking / bandwidth constraintsLocal networking / bandwidth constraints Move some/most costs from Capex to OpexMove some/most costs from Capex to Opex Greater control – firewalls, resource types, etc.Greater control – firewalls, resource types, etc. Transparent technology refreshTransparent technology refresh Why migrate?

5 Unsuitable application modelUnsuitable application model Security concerns – confidential data / algorithms / …Security concerns – confidential data / algorithms / … Specific hardware/infrastructure requirements (e.g. high- performance inter-node linking)Specific hardware/infrastructure requirements (e.g. high- performance inter-node linking) Infrastructure location issuesInfrastructure location issues Latency concernsLatency concerns Resource/data storage locationsResource/data storage locations SLA guarantees not satisfactorySLA guarantees not satisfactory Why not migrate?

6 Limited number of raw infrastructure providersLimited number of raw infrastructure providers Increasing numbers of higher level service providersIncreasing numbers of higher level service providers Infrastructure – dynamic DNS, load balancing, etc.Infrastructure – dynamic DNS, load balancing, etc. Brokering / MarketplaceBrokering / Marketplace Software toolkitsSoftware toolkits Simplified resource management – APIs, GUIsSimplified resource management – APIs, GUIs Consultants / Application enablersConsultants / Application enablers Different payment models Different payment models What services are on offer?

7 Application Profiles Where does your app fit in? Application Profiles Where does your app fit in?

8 Batch applications – limited / no interactivityBatch applications – limited / no interactivity HPC applicationsHPC applications Client / server – Web 2.0 apps, Software-as-a-ServiceClient / server – Web 2.0 apps, Software-as-a-Service Standalone interactive applicationsStandalone interactive applications Application profiles Data in Results out

9 Batch applicationsBatch applications Code takes some input data and carries out processing, returning result dataCode takes some input data and carries out processing, returning result data Generally no interactivityGenerally no interactivity Individual tasks may beIndividual tasks may be Computationally intensive – long runningComputationally intensive – long running Computationally simple but high throughputComputationally simple but high throughput May require significant data to carry out processing – either as input or from third-party sourceMay require significant data to carry out processing – either as input or from third-party source Likely to be produced as a native executable so may require a specific CPU type for executionLikely to be produced as a native executable so may require a specific CPU type for execution Application profiles

10 Web 2.0 apps – client / server modelWeb 2.0 apps – client / server model High throughput, interactivityHigh throughput, interactivity May be data intensive / processor intensiveMay be data intensive / processor intensive Loosely-coupled, client/server designLoosely-coupled, client/server design Message-based communication between application componentsMessage-based communication between application components Handle state / sessions for support of multiple concurrent clientsHandle state / sessions for support of multiple concurrent clients SaaSSaaS Service enabled application coreService enabled application core Client-side (web) application provides remote GUIClient-side (web) application provides remote GUI Application profiles

11 Standalone interactive applicationsStandalone interactive applications Traditional desktop applicationsTraditional desktop applications Highly interactive but generally not highly processor intensiveHighly interactive but generally not highly processor intensive Tight coupling between application functionality and user interfaceTight coupling between application functionality and user interface Generally not designed for access by multiple (concurrent) usersGenerally not designed for access by multiple (concurrent) users Application profiles ?

12 HPC ApplicationsHPC Applications Processor/Memory intensiveProcessor/Memory intensive Data intensiveData intensive Generally batch applications but may have elements of interactivityGenerally batch applications but may have elements of interactivity May be parallelised – operation across multiple CPUs (e.g. MPI, OpenMP, Hadoop, …)May be parallelised – operation across multiple CPUs (e.g. MPI, OpenMP, Hadoop, …) May require extensive communication between parallel nodes (high performance interconnects required)May require extensive communication between parallel nodes (high performance interconnects required) Visualisation / steering of output often necessaryVisualisation / steering of output often necessary Application profiles

13 FrequencyFrequency How frequently an application is usedHow frequently an application is used Is usage predictable?Is usage predictable? LoadLoad Does application require significant processing power?Does application require significant processing power? Is the processing requirement similar for each application run?Is the processing requirement similar for each application run? Is it dependent on input data?Is it dependent on input data? Can required processing capacity be identified programmatically in advance of an application run?Can required processing capacity be identified programmatically in advance of an application run? Usage profiles

14 Data volume / proximity / couplingData volume / proximity / coupling How much data is involved in a run of the application?How much data is involved in a run of the application? Is data proximity of importance – if there is a lot of transfer of data between storage and execution resource, data should be stored close to where the app is runIs data proximity of importance – if there is a lot of transfer of data between storage and execution resource, data should be stored close to where the app is run How tightly coupled is the data – can data transfer be optimised?How tightly coupled is the data – can data transfer be optimised? Availability / Reliability – need SLA?Availability / Reliability – need SLA? Are guarantees on uptime / reliability needed?Are guarantees on uptime / reliability needed? If the resources running the application go down, how long will it take / how complex will it be to restart it?If the resources running the application go down, how long will it take / how complex will it be to restart it? Usage profiles

15 Information SecurityInformation Security How critical is data/code security?How critical is data/code security? IP in code (algorithms, etc.), dataIP in code (algorithms, etc.), data Data protection issues – where can data be sent / stored?Data protection issues – where can data be sent / stored? Is third party data being used? Can this be transferred to another location for processing?Is third party data being used? Can this be transferred to another location for processing? Latency requirementsLatency requirements Real time data processing applicationsReal time data processing applications Are there specific requirements for latency on network connections?Are there specific requirements for latency on network connections? Are these catered for under SLA?Are these catered for under SLA? Usage profiles

16 Challenges – Preparing Your Application for the Cloud

17 What are you aiming for?What are you aiming for? One-off/occasional manual execution of an application on a remote resource from a terminalOne-off/occasional manual execution of an application on a remote resource from a terminal e.g. long running HPC app, dont want to hog CPU on local resource for a long period of timee.g. long running HPC app, dont want to hog CPU on local resource for a long period of time Use a Cloud platform such as Amazon EC2 to create an instance of a Cloud resource and interact with it via a terminal to upload and run your applicationUse a Cloud platform such as Amazon EC2 to create an instance of a Cloud resource and interact with it via a terminal to upload and run your application Full remote deployment of applicationFull remote deployment of application Remote execution / interactionRemote execution / interaction Preparing your application

18 Batch applications (e.g. scientific HPC codes)Batch applications (e.g. scientific HPC codes) If native code, need to ensure CPU/OS requirements are supportedIf native code, need to ensure CPU/OS requirements are supported Same goes for apps based on JIT / interpreted languagesSame goes for apps based on JIT / interpreted languages Does application have a GUI?Does application have a GUI? Data transfer issues – if very data intensive, data transfer may present problemsData transfer issues – if very data intensive, data transfer may present problems Dynamic deployment / wrapping?Dynamic deployment / wrapping? Preparing your application

19 Web 2.0 / SaaS applicationsWeb 2.0 / SaaS applications Deploy necessary application server and server-side codeDeploy necessary application server and server-side code If supported by Cloud provider, bundle deployed system in platform wrapper for easy restart / creating additional nodesIf supported by Cloud provider, bundle deployed system in platform wrapper for easy restart / creating additional nodes Storage considerationsStorage considerations How much output data is there?How much output data is there? Where are you going to put it?Where are you going to put it? Preparing your application

20 Aim for loosely-coupled SOA modelAim for loosely-coupled SOA model Preparing your application - Web 2.0 Application Component Interface Client Decoupling of GUI from backendDecoupling of GUI from backend

21 Getting native executables onto remote platform and controlling executionGetting native executables onto remote platform and controlling execution Deploy app at runtime – e.g. via job manager / middleware installed on Cloud instanceDeploy app at runtime – e.g. via job manager / middleware installed on Cloud instance Preparing your application - Batch Lightweight application wrappingLightweight application wrapping Provide service interface for basic execution control of appsProvide service interface for basic execution control of apps e.g. start, getOutput, getErrore.g. start, getOutput, getError Static deployment of application into Cloud instanceStatic deployment of application into Cloud instance Service Wrapper Messaging APIs Native Code Executable Interface Native Libraries

22 Technologies – Server-side / Client-side Service-enabling your application Technologies – Server-side / Client-side Service-enabling your application

23 Cloud environments may provide a managed interface to physical hardware, or a virtualised platform on which you install your own OS/application imageCloud environments may provide a managed interface to physical hardware, or a virtualised platform on which you install your own OS/application image An Application Server / Servlet Container may be needed to host your application and provide the messaging infrastructure to communicate with itAn Application Server / Servlet Container may be needed to host your application and provide the messaging infrastructure to communicate with it e.g. Apache Tomcat, Glassfish, JBoss, etc.e.g. Apache Tomcat, Glassfish, JBoss, etc. Server side software / technologies

24 Services / Messaging / Transport – Getting messages to Cloud appsServices / Messaging / Transport – Getting messages to Cloud apps Web Services (WSDL, SOAP) –Web Services (WSDL, SOAP) – Apache Axis, JAX-WS, …Apache Axis, JAX-WS, … Server-side software / technologies Client App Server Service Description (e.g. WSDL) App Server Service Description (e.g. WSDL) Messaging (e.g. SOAP over HTTP) HTTP GET/POSTHTTP GET/POST JMSJMS Adobe BlazeDSAdobe BlazeDS RMIRMI CORBA, …CORBA, …

25 Client-side software / technologies Client-side tools / RIA PlatformsClient-side tools / RIA Platforms Web development – e.g.Web development – e.g. HTML, Javascript, AJAX, …HTML, Javascript, AJAX, … RIA platforms – e.g.RIA platforms – e.g. Adobe FlexAdobe Flex Sun JavaFXSun JavaFX Microsoft SilverlightMicrosoft Silverlight … JavaScript Libraries – e.g.JavaScript Libraries – e.g. Prototype, jQuery, YahooPrototype, jQuery, Yahoo Dojo, Script.aculo.us, … Dojo, Script.aculo.us, …

26 Examples – The MESSAGE Project Dynamic Application Deployment Examples – The MESSAGE Project Dynamic Application Deployment

27 3 year project starting October year project starting October 2006 Funded jointly by EPSRC and DfT (~£4m), under EPSRCs e-Science demonstration programmeFunded jointly by EPSRC and DfT (~£4m), under EPSRCs e-Science demonstration programme 5 Universities, 19 industrial partners5 Universities, 19 industrial partners Pioneering combination and extension of leading edge grid, sensor, communication and positioning technologiesPioneering combination and extension of leading edge grid, sensor, communication and positioning technologies Create radically new sensing infrastructure based on combination of ad-hoc mobile and fixed sensorsCreate radically new sensing infrastructure based on combination of ad-hoc mobile and fixed sensors The MESSAGE Project Mobile Environmental Sensing System Across a Grid EnvironmentMobile Environmental Sensing System Across a Grid Environment

28 To extend existing e-Science, sensor, communication and modelling technologies to enable the integration of data from heterogeneous fixed and mobile environmental sensor grids in real time to provide dynamic estimates of pollutant and hazard concentrations. To demonstrate how these data can be usefully correlated with a wide range of other complementary dynamic data on, for example, weather conditions, transport network performance, vehicle mix and performance, driver behaviour, travel demand, pollutant exposure and health outcomes. To implement relevant e-Science tool sets and (fixed and mobile) sensor and communication system in a number of selected real-world case study applications, involving close collaboration with business and the public sector, and to thereby to demonstrate their value to the research and policy community. MESSAGE Objectives

29 Architecture Overview Three Layer Architecture Application Layer Application Layer Realtime Data Layer Realtime Data Layer Sensor Layer Sensor Layer

30 MESSAGE Project – Data Capture Data Capture Platform Reliable, efficient capture of data from an environment with an unreliable communications infrastructure and varying load. Different types of sensors, different pre-processing requirements Different types of sensors, different pre-processing requirements Different communications technologies Different communications technologies Real time streaming and intermittent burst Real time streaming and intermittent burst Multiple DBs distributed across several sites. Scalable Cloud-based processing infrastructure Multiple sensor and communications technologies.

31 Sensors join and leave the network stochasticallySensors join and leave the network stochastically Joining sensors need to know where to send their data – this information is provided by the Root Gateway:Joining sensors need to know where to send their data – this information is provided by the Root Gateway: Processing data from sensors Root Gateway Sensor ?? Difficult to know how many sensors active at any timeDifficult to know how many sensors active at any time Scalable infrastructure = more flexibility, less wasteScalable infrastructure = more flexibility, less waste

32 Using Amazon EC2 (http://aws.amazon.com/ec2) to provide scalable computing infrastructure for MESSAGEUsing Amazon EC2 (http://aws.amazon.com/ec2) to provide scalable computing infrastructure for MESSAGEhttp://aws.amazon.com/ec2 An Amazon Machine Image (AMI) has been prepared for the Sensor Gateway softwareAn Amazon Machine Image (AMI) has been prepared for the Sensor Gateway software Sensor Gateway AMI is stored in the Amazon S3 Simple Storage ServiceSensor Gateway AMI is stored in the Amazon S3 Simple Storage Service Resources based on this image can be started on-demandResources based on this image can be started on-demand Paid for on a CPU-hour basisPaid for on a CPU-hour basis MESSAGE Project – Cloud Computing

33 Minimal Linux distribution to reduce image size and provide faster start upMinimal Linux distribution to reduce image size and provide faster start up Image contains only necessary software to run Sensor Gateway:Image contains only necessary software to run Sensor Gateway: Java, Glassfish Application Server, Sensor Gateway Web ServiceJava, Glassfish Application Server, Sensor Gateway Web Service Start up scripts start application server and Sensor Gateway service when image boots upStart up scripts start application server and Sensor Gateway service when image boots up Root Gateway Service has uses embedded client to start / stop Sensor Gateway instances as requiredRoot Gateway Service has uses embedded client to start / stop Sensor Gateway instances as required Pre-processing may be carried out by Sensor Gateway nodes, data then sent on to database for storagePre-processing may be carried out by Sensor Gateway nodes, data then sent on to database for storage MESSAGE Project – Cloud Computing

34 Sensor Scalable Sensor Gateway Pool Cloud Computing Resources Data Storage Visualisation/Application Platform

35 Dynamic application deployment

36 Have varying application requirementsHave varying application requirements Avoid preparing separate Cloud resources for each applicationAvoid preparing separate Cloud resources for each application Use Cloud resources with a generic configurationUse Cloud resources with a generic configuration Use a deployment service to move application executables into execution environment as required, at runtimeUse a deployment service to move application executables into execution environment as required, at runtime Well suited to HPC, batch type applications that need to be run occasionallyWell suited to HPC, batch type applications that need to be run occasionally Potential for automating workflow execution on Cloud resourcesPotential for automating workflow execution on Cloud resources Dynamic application deployment

37 Application 2 (Executable, Libraries) Application 1 (Executable, Libraries) Input Data Cloud Computing Resource Service Interface GridSAM Job Submission and Monitoring Service using local fork launcher JSDL Job Description JSDL Job description sent to GridSAM service on execution resourceJSDL Job description sent to GridSAM service on execution resource Application and input files staged onto execution resource for executionApplication and input files staged onto execution resource for execution JSDL Job Description

38 Many different considerations when moving applications to a Cloud environmentMany different considerations when moving applications to a Cloud environment Not necessarily suited to all apps but new models/services emergingNot necessarily suited to all apps but new models/services emerging U Use a deployment service to move application executables into execution environment as required, at runtimeUse a deployment service to move application executables into execution environment as required, at runtime Well suited to HPC, batch type applications that need to be run occasionallyWell suited to HPC, batch type applications that need to be run occasionally Potential for automating workflow execution on Cloud resourcesPotential for automating workflow execution on Cloud resources Conclusions

39 THANK YOU!


Download ppt "Developing Applications for Cloud Computing Platforms Jeremy Cohen Department of Computing Imperial College London The Influence and Impact of Web 2.0."

Similar presentations


Ads by Google