1. Cloud Age Time to change the programming paradigm?

2. Do we need to change programming paradigm to effectively use Cloud?

3. How did we get here? At the beginning programming was simple –f77, C, static linking Then it got more complicated… –OO, C++, shared libraries, dynamic linking, client-server, CORBA …and execution distributed… –HPC Clusters, MPI, RPC …worldwide –Grid, Web Services

4. Typical workflow In spite of substantial changes in computing infrastructure, the basic workflow remains unchanged –Write a program that sequentially invokes the function and subroutine calls that will be executed locally or perhaps remotely using some sort of the remote procedure call RPC/CORBA/XMLRPC/SOAP –The entire program has to be compiled, assuring that runtime dependencies are satisfied and environment is correctly configured –Everything has to be packaged and handed over to some scheduler to find an appropriate resource and run it This process got increasingly more complicated as we moved towards more distributed and heterogeneous resources –Failures in such systems are the rule and not an exception –Recovery can be costly

5. Cluster @ Cloud Cloud offers users access to virtualized resources that can be tailored to their application –Virtualization removes heterogeneous resource problem –CernVM approach eliminates problems related to software distribution and configuration Cloud simplifies deployment problem of a single application running on a single VM –But what if one wants to run jobs on many virtual machines? Possible (traditional) solution –Ad-hoc clusters per user (possible with CernVM and Condor) –Reduces scale of the problem –Decreases error probability Can we be smarter than that?

6. Elastic Cloud Elastic Cloud Model –Asynchronous, event driven paradigm –Application broken up into event handlers that receive, process and emit new messages –Messaging system is part of the infrastructure and assures reliable communication between components Why is this better? –Programming effort can be focused on individual components Components can be developed independently and even in different programming languages They can be kept reasonably small and comprehensible and replaceable –System can evolve by evolving the components –Event handlers instances can be dynamically added at runtime to remove bottlenecks –Individual component failures do not cause application failure