James Larus. Microsoft Research. Mysore-Park Workshop on . Cloud Computing. Mysore India, January 13, 2010. What is Cloud Computing?. More Than Amazon Web Services / Microsoft Azure / Google AppEngine. ID: 359463
DownloadNote - The PPT/PDF document "Cloud Programming" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentations text content in Cloud Programming
Slide1
Cloud Programming
James Larus
Microsoft Research
Mysore-Park Workshop on
Cloud Computing
Mysore India, January 13, 2010
Slide2
What is Cloud Computing?
More Than Amazon Web Services / Microsoft Azure / Google AppEngine
Platform as a service
On-demand, internet computing resources hosted by someone else
Commodification of distributed computing
More significant is software model enabled by platform
Inherently distributed
Range of clients (single purpose -> rich)
Multiple computers in the cloud
Ubiquitous access to information and computation
Slide3
Cloud Computing
Slide4
New Programming Model, New Problems(and some old, unsolved ones)
Concurrency
Parallelism
Message passing
Distribution
High available
Performance
Application partitioning
Defect detection
High-level abstractions
Slide5
Programming Languages / Compilers / Tools Research
What can these research communities contribute to the adoption of cloud computing?
Can new problems reinvigorate these areas?
Slide6
Concurrency
Inherently concurrent programming modelAsynchrony in message-driven modelProcessing multiple streams of requestsLong-standing divide between threads and eventsThreads offer familiar sequential programming modelBut, state can change when thread is preempted (=> synchronization)Cost of thread and context switch limits concurrencyHandlers respond to eventsStructure lost across sequences of event handlersCode explicitly manipulates local state (no stack frames)Also, higher-level (state machine, Actor, …) modelsLack of consensus inhibits research, development, reuse, interoperabilityParallel programming, redux
Slide7
Parallelism
Computers are parallelIncreased performanceIncreased power efficiencyComputers will be heterogeneousMultiple, non-isomorphic functional unitsData centers are vast message-passing clustersAvailability and throughputParallel programming is long-standing sore for computer scienceState of the art: threads and synchronizationNo consensus on shared memory semanticsLow level and error prone (assembly language)Interesting new research on higher level models (not panaceas)Transactional memoryDeterministic parallelismRadical proposal: abolish shared memoryMessage passing is inherent in distributed systemsWhy 2 modelsShared memory is more difficult and error prone
Slide8
Message Passing
Not only fundamental to distributed systems, but also a better parallel programming modelPerformance / correctness isolationWell-defined points of interactionScalable modelMore difficult to useLittle language supportErlang integrates message with pattern matchingSing# channel contractsSing# postbox semanticsMessage passing librariesFundamental mismatch: asynchronous strange in a synchronous worldOpen problemsControl structures for asynchronous messagesCommunications contractsIntegration of messages in type system and memory model
Slide9
Distribution
Distributed systems are rich source of difficult problemsReplicationConsistencyQuorumWell studied field produced good solutionsOutsider’s perspective: research is focused on fundamental problems and used in real systemsHow can these techniques be incorporated into programming model?LibrariesLanguage integrationNew models
Slide10
Availability
Services must be highly availableBlackberry outage gets national media attentionAffect millions of people simultaneouslyService can become part of national infrastructureHigh availability is challengeStarts with design and engineeringHard to eliminate all “single points of failure”Murphy’s law rulesAntithetical to rapid software evolutionProgramming models provide little support of systematic error handlingDisproportionate fraction of software defects in error handling codeAfterthoughtRun in inconsistent stateDifficult to testErlang has systematic philosophy of fail and notify (but is stateless)Could lightweight transactions simplify rollback for stateful languages?
Slide11
Performance
Performance is system-level concernGoes far beyond the code running on a machineMost performance tools focus on low-level detailsAutomatic optimization (compilers) is very granularCurrent approach is wasteful and uncertainBuild, observe, tweak, overprovision, prayPerformance should be specified as part of behaviorSLAs as well as pre-/post-conditionsNeed scalabilityGrow by adding machines, not rewriting softwareArchitecture should be the starting pointModel and simulate before building a systemWhat is equivalent of Big-O notation for scalability?AdaptivitySystems need to be introspective and capable of adapting behavior to loade.g., simplify home page when load spikes, defer low-priority tasks, provision more machines, …
Slide12
Application Partitioning
Static partition of functionality between client and serverDifficult to support range of clients with different architectures and capabilitiesDifficult to adapt to changing constraints (e.g., battery)Move computation to data, particularly when communications constrainedCode mobilityExists in data center (VMs), why not across data center boundary?Currently, client and server are two fundamentally different applicationsEvolution around interfacesVolta (Microsoft)Single program model, compiled for server and client
Slide13
Defect Detection
Considerable progress in past decade on defect detection toolsTools focused on local properties (e.g., buffer overruns, test coverage, races, etc.)Little work on system-wide propertiesModular checkingWhole program analysis expensive and difficultNot practical for servicesAssertions and annotations at module boundariesCan check global properties locallye.g., Rajamani & Rehof’s Conformance CheckingNew domain of defectsMessage passingCode robustnessPotential performance bottlenecks
Slide14
High-Level Abstractions
Map-reduce and dataflow abstractions simplify large-scale data analysis in data centers
Download this presentation
DownloadNote - The PPT/PDF document "Cloud Programming" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentations text content in Cloud Programming
Cloud Programming
James Larus
Microsoft Research
Mysore-Park Workshop on
Cloud Computing
Mysore India, January 13, 2010
Slide2What is Cloud Computing?
More Than Amazon Web Services / Microsoft Azure / Google AppEngine
Platform as a service
On-demand, internet computing resources hosted by someone else
Commodification of distributed computing
More significant is software model enabled by platform
Inherently distributed
Range of clients (single purpose -> rich)
Multiple computers in the cloud
Ubiquitous access to information and computation
Slide3Cloud Computing
Slide4New Programming Model, New Problems(and some old, unsolved ones)
Concurrency
Parallelism
Message passing
Distribution
High available
Performance
Application partitioning
Defect detection
High-level abstractions
Slide5Programming Languages / Compilers / Tools Research
What can these research communities contribute to the adoption of cloud computing?
Can new problems reinvigorate these areas?
Slide6Concurrency
Inherently concurrent programming modelAsynchrony in message-driven modelProcessing multiple streams of requestsLong-standing divide between threads and eventsThreads offer familiar sequential programming modelBut, state can change when thread is preempted (=> synchronization)Cost of thread and context switch limits concurrencyHandlers respond to eventsStructure lost across sequences of event handlersCode explicitly manipulates local state (no stack frames)Also, higher-level (state machine, Actor, …) modelsLack of consensus inhibits research, development, reuse, interoperabilityParallel programming, redux
Slide7Parallelism
Computers are parallelIncreased performanceIncreased power efficiencyComputers will be heterogeneousMultiple, non-isomorphic functional unitsData centers are vast message-passing clustersAvailability and throughputParallel programming is long-standing sore for computer scienceState of the art: threads and synchronizationNo consensus on shared memory semanticsLow level and error prone (assembly language)Interesting new research on higher level models (not panaceas)Transactional memoryDeterministic parallelismRadical proposal: abolish shared memoryMessage passing is inherent in distributed systemsWhy 2 modelsShared memory is more difficult and error prone
Slide8Message Passing
Not only fundamental to distributed systems, but also a better parallel programming modelPerformance / correctness isolationWell-defined points of interactionScalable modelMore difficult to useLittle language supportErlang integrates message with pattern matchingSing# channel contractsSing# postbox semanticsMessage passing librariesFundamental mismatch: asynchronous strange in a synchronous worldOpen problemsControl structures for asynchronous messagesCommunications contractsIntegration of messages in type system and memory model
Slide9Distribution
Distributed systems are rich source of difficult problemsReplicationConsistencyQuorumWell studied field produced good solutionsOutsider’s perspective: research is focused on fundamental problems and used in real systemsHow can these techniques be incorporated into programming model?LibrariesLanguage integrationNew models
Slide10Availability
Services must be highly availableBlackberry outage gets national media attentionAffect millions of people simultaneouslyService can become part of national infrastructureHigh availability is challengeStarts with design and engineeringHard to eliminate all “single points of failure”Murphy’s law rulesAntithetical to rapid software evolutionProgramming models provide little support of systematic error handlingDisproportionate fraction of software defects in error handling codeAfterthoughtRun in inconsistent stateDifficult to testErlang has systematic philosophy of fail and notify (but is stateless)Could lightweight transactions simplify rollback for stateful languages?
Slide11Performance
Performance is system-level concernGoes far beyond the code running on a machineMost performance tools focus on low-level detailsAutomatic optimization (compilers) is very granularCurrent approach is wasteful and uncertainBuild, observe, tweak, overprovision, prayPerformance should be specified as part of behaviorSLAs as well as pre-/post-conditionsNeed scalabilityGrow by adding machines, not rewriting softwareArchitecture should be the starting pointModel and simulate before building a systemWhat is equivalent of Big-O notation for scalability?AdaptivitySystems need to be introspective and capable of adapting behavior to loade.g., simplify home page when load spikes, defer low-priority tasks, provision more machines, …
Slide12Application Partitioning
Static partition of functionality between client and serverDifficult to support range of clients with different architectures and capabilitiesDifficult to adapt to changing constraints (e.g., battery)Move computation to data, particularly when communications constrainedCode mobilityExists in data center (VMs), why not across data center boundary?Currently, client and server are two fundamentally different applicationsEvolution around interfacesVolta (Microsoft)Single program model, compiled for server and client
Slide13Defect Detection
Considerable progress in past decade on defect detection toolsTools focused on local properties (e.g., buffer overruns, test coverage, races, etc.)Little work on system-wide propertiesModular checkingWhole program analysis expensive and difficultNot practical for servicesAssertions and annotations at module boundariesCan check global properties locallye.g., Rajamani & Rehof’s Conformance CheckingNew domain of defectsMessage passingCode robustnessPotential performance bottlenecks
Slide14High-Level Abstractions
Map-reduce and dataflow abstractions simplify large-scale data analysis in data centers
Convenient way to express problems
Hide complex details (distribution, failure, restart)
Allow optimization (speculation)
Need more abstractions for wider range of problems
Not appropriate for services
Slide15More, …
Consistency models
Persistence
Slide16Orleans
16
Application
Code
Specs
Verify
Compile
Slide17Orleans Architecture
17
Azure
Internet Application
DC#
Tools
Orleans Runtime
Geo-Distribution
Data Replication and Consistency
Performance Monitoring
Adaptive Control
Distributed Debugging
Runtime (Correctness) Monitoring
Deployment, Configuration, Maintenance
Slide18Channel
Shared State
Grain
Silo
Orleans Runtime (ORT)
Data Center 1
Data Center 2
Client
1
2
3
Orleans Programming Model
18
Slide19Data Model
19
Migration
Persistence
Directory
Replication
Mobility
Slide20Conclusion
Cloud computing is more than VMs, data centers, web services, …
New way of performing computation
New opportunity to correct problems with existing computing models
Cost, complexity, reliability, …
Slide21Slide22Slide23Slide24Slide25Slide26Slide27Slide28Slide29Slide30Slide31