Application and Data Portability in Cloud Computing The Cirrocumulus Way

1. Application and Data Portability in Cloud ComputingThe Cirrocumulus Way AjithRanabahuand AmitSheth Ohio Center of Excellence in Knowledge enabled Computing (Kno.e.sis) http://knoesis.org Wright State University, Dayton OH, USA

2. Agenda • Issues in Cloud computing and its adoption • Vendor lock-in problem • Understanding cloud heterogeneity • Using Domain Specific Languages to implement application portability • Using RDFS based modeling to implement data portability • Two Example applications • Where are the semantics ?

3. What is Cloud computing ?

4. Cheap No upfront cost Utility style Resources Service oriented provisioning over the Web APIs enabling programmatic access Numerous support services Data access (Amazon RDS, Amazon simple DB, Google Big Table Automatic scaling (Amazon Elastic Beanstalk)

5. Did it change the world ? Why not ?

6. Multiple Issues in Wide Adoption

7. Almost always heterogeneous platforms Supported programming languages Data representation Resource provisioning and Management Workflow

8. Writing one application is not enough !

9. Amazon EC2 accepts almost any language Windows Azure support .NET (other languages need workarounds) Google App Engine only supports Java and Python

10. Vendor Lock-in

11. Users locked into clouds proprietary APIs Limited language support Custom tools and workflows

12. We need a better way of doing things !

13. Write applications in cloud agnostic ways : "Write once - Run on any cloud"

14. Access cloud resources with a uniform workflow

15. Move applications and data across clouds when the need arises

16. Understanding Heterogeneity : Where does it exist ?

17. Vertical and Horizontal

18. Vertical Within the same type of clouds - Say Infrastructure service providers

19. Horizontal Across different types of clouds - Say Infrastructure clouds and platform clouds

20. Some examples

21. Amazon EC2 vs Rackspace Both are infrastructure providers Process of starting a VM in EC2 is very different from doing the same in Rackspace

22. Google App Engine vs Windows Azure Both are platforms Supports differentlanguages (Java/Python vs C#/.NET) Requires using different custom libraries Requires adhering to different data models (document-oriented vs Relational)

23. How can Portable Applications be developed ?

24. DSLs to the rescue !

25. Domain Specific Languages (DSL) are specialized, mini languages that address problems in a limited domain. • Matlab (Mathematics) • SQL (Data definitions and manipulation) • Ant / Make (build scripts)

26. What 'Domain' are we talking about ?

27. Many !

28. Each domain has to have its own DSL

29. Some example domains of Interest (in the Cloud context) Enterprise data retrieval applications Data driven mobile applications Statistical Scientific Workflows

30. What is the catch ?

31. DSLs are not universal applicable: Useful only in a supported domain

32. Forcing a top-down (model driven) development method

33. The case of the "smallest common set of features" When using an abstraction over multiple platforms, only the smallest common set of features can be effectively supported.

34. Its not as serious as it sounds !

35. The number of unique features across the major platforms is quite small [quantification needed !]

36. In case platform specific features are needed Use the DSLs as boiler-plate code generators Use Bison-like conditional code additions to insert specific code fragments

37. Two Examples

38. MobiCloud Generating hybrid applications that have pieces running on clouds and mobile devices http://mobicloud.knoesis.org

40. SCALE : Scalable Cloud AppLicationgEnerator Generating statistical workflows for biologists http://metabolink.knoesis.org/SCALE

41. What kind of Heterogeneity are we talking about ?

42. An Example for a simple class [ Code generated by MobiCloud for task manager example ] package bean; import com.google.appengine.api.datastore.Key; import javax.jdo.annotations.IdGeneratorStrategy; import javax.jdo.annotations.IdentityType; import javax.jdo.annotations.PersistenceCapable; import javax.jdo.annotations.Persistent; import javax.jdo.annotations.PrimaryKey; @PersistenceCapable(identityType = javax.jdo.annotations.IdentityType.APPLICATION) public class Todoitem { @PrimaryKey @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) private Key key; public Key getKey() { return key; } @Persistent private java.lang.String time; public java.lang.StringgetTime() { return time; } public void setTime(java.lang.Stringlocal_time) { this.time = local_time; } …….. } package bean; public class Todoitem { /* PrimaryKey */ private int key; public intgetKey() { return key; } public void setKey(intlocalkey) { this.key = localkey; } private java.lang.String time; public java.lang.StringgetTime() { return time; } public void setTime(java.lang.Stringlocal_time) { this.time = local_time; } … } Code for Local / EC2 version Code for Google App Engine version

43. The DSL code fragment relevant to the generated code model(:todoitem,{:time => :string,:location => :string, :description => :string,:name => :string}) Taking care of proper annotations and adhering platform specific restrictions Is taken care of by the generators !

44. Porting data across clouds

45. Issues caused by the difference in data models Often more crucial than porting the application code

46. We are in luck ! We already followed a model-driven development process

47. We get to define data at a higher level of abstraction Data transformations can be generated along with the application code

49. Our Choice for Data Definitions ?

50. RDF Schema (RDFS)