Your SlideShare is downloading. ×
The Multiple Dimensions of Cross-Cloud Computing
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

The Multiple Dimensions of Cross-Cloud Computing

187

Published on

Slides from the keynote talk at the IEEE CrossCloud'14 workshop, part of IEEE INFOCOM'14

Slides from the keynote talk at the IEEE CrossCloud'14 workshop, part of IEEE INFOCOM'14

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
187
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. The Multiple Dimensions of Cross-Cloud Computing Andrew Phillips | 28 April 2014
  • 2. 2 Copyright 2014. Agenda ▪ Introduction ▪ What is “Cross-Cloud Computing”? ▪ Cloud History: Technology Evolution ▪ Cloud History: User Evolution ▪ The Cloud Monoculture Pitfall ▪ Multi-Cloud: Technology Benefits ▪ Multi-Cloud: Knowledge Benefits ▪ Q & A
  • 3. 3 Copyright 2014. FirstThings First Thanks!
  • 4. 4 Copyright 2014. About Me ▪ Apache jclouds PMC member ▪ During office hours, VP Products for XebiaLabs ▪ Lots of enterprise software development on high-performance systems ▪ Active open source contributor and committer: jclouds, Akka, Gradle, Scala and others ▪ Cloud, PaaS & Scala fan ▪ Regular meetup, conference etc. presenter
  • 5. 5 Copyright 2014. About Me ▪ Apache jclouds PMC member ▪ During office hours, VP Products for XebiaLabs ▪ Lots of enterprise software development on high-performance systems ▪ Active open source contributor and committer: jclouds, Akka, Gradle, Scala and others ▪ Cloud, PaaS & Scala fan ▪ Regular meetup, conference etc. presenter ▪ Opinions expressed are my own, not “official” positions of the Apache jclouds PMC, the ASF, XebiaLabs etc.
  • 6. 6 Copyright 2014. About XebiaLabs ▪ Leading provider of delivery automation software focused on helping companies deliver higher quality software faster. ▪ Reduce development applications costs ▪ Accelerate application time to market ▪ Bridge the gap between Development and Operations Global Customers, Global Success and more…
  • 7. 7 Copyright 2014. What is “Cross-Cloud Computing”? ▪ …in the context of this talk, at least. ▪ Some terminology: ▪ Abstraction or view − a type of service or functionality available in the cloud − e.g. blob storage, compute
  • 8. 8 Copyright 2014. What is “Cross-Cloud Computing”? ▪ …in the context of this talk, at least. ▪ Some terminology: ▪ Abstraction or view − a type of service or functionality available in the cloud − e.g. blob storage, compute ▪ API − a defined mechanism for communicating with a cloud endpoint − e.g. the EC2 API
  • 9. 9 Copyright 2014. What is “Cross-Cloud Computing”? ▪ …in the context of this talk, at least. ▪ Some terminology: ▪ Abstraction or view − a type of service or functionality available in the cloud − e.g. blob storage, compute ▪ API − a defined mechanism for communicating with a cloud endpoint − e.g. the EC2 API ▪ Provider − a specific cloud endpoint, offered by a vendor/product − e.g. Amazon EC2
  • 10. 10 Copyright 2014. What is “Cross-Cloud Computing”? ▪ So a Provider implements one or more APIs which support one or more Views − e.g. Amazon EC2 implements (a flavour of) the EC2 API which supports the “compute” view
  • 11. 11 Copyright 2014. What is “Cross-Cloud Computing”? ▪ So a Provider implements one or more APIs which support one or more Views − e.g. Amazon EC2 implements (a flavour of) the EC2 API which supports the “compute” view ▪ In the context of this talk, “Cross-Cloud Computing” is: “writing applications that leverage one or more Views using one or (potentially) more Providers”
  • 12. 12 Copyright 2014. Cloud History:Then… Abstraction diversity API diversity
  • 13. 13 Copyright 2014. Cloud History: …and Now Abstraction diversity API diversity
  • 14. 14 Copyright 2014. Cloud History:Technology Evolution ▪ Started out with a small number of available abstractions: blobstore & compute ▪ Large variation of available APIs − Pretty much a different API per provider
  • 15. 15 Copyright 2014. Cloud History:Technology Evolution ▪ Started out with a small number of available abstractions: blobstore & compute ▪ Large variation of available APIs − Pretty much a different API per provider ▪ Consolidation and commoditization has resulted in harmonization of APIs for the most widely-used abstractions − E.g. S3 for blob storage, EC2 for compute ▪ Growing use of cloud has lead to a large number of additional services/abstractions − Some more “niche” than others − E.g. load balancing, routing, caching, provisioning etc. etc.
  • 16. 16 Copyright 2014. Cloud History:Technology Evolution ▪ In short: within a particular abstraction, it’s easier to identify a (semi-)standard API…
  • 17. 17 Copyright 2014. Cloud History:Technology Evolution ▪ In short: within a particular abstraction, it’s easier to identify a (semi-)standard API… ▪ …but there are also many more abstractions in the mix
  • 18. 18 Copyright 2014. Cloud History:Technology Evolution ▪ In short: within a particular abstraction, it’s easier to identify a (semi-)standard API… ▪ …but there are also many more abstractions in the mix ▪ How has this affected the “cloud user demographic”?
  • 19. 19 Copyright 2014. Cloud History: User Evolution ▪ Original use case for cross-cloud computing: how to handle the variation among APIs? − Different authentication schemes − Different payloads − Different namespace models − Etc. etc.
  • 20. 20 Copyright 2014. Cloud History: User Evolution ▪ Original use case for cross-cloud computing: how to handle the variation among APIs? − Different authentication schemes − Different payloads − Different namespace models − Etc. etc. ▪ Choosing a single API = locked-in to a single provider − Business risk especially for companies looking to deliver a cloud-based service where the choice of underlying provider should be transparent to the end-user − Feature disparity between providers not massive, so no significant advantage to choosing a single provider only
  • 21. 21 Copyright 2014. Cloud History: User Evolution ▪ Original use case for cross-cloud computing: how to handle the variation among APIs? − Different authentication schemes − Different payloads − Different namespace models − Etc. etc. ▪ Choosing a single API = locked-in to a single provider − Business risk especially for companies looking to deliver a cloud-based service where the choice of underlying provider should be transparent to the end-user − Feature disparity between providers not massive, so no significant advantage to choosing a single provider only ▪ Cross-cloud/multi-cloud libraries such as jclouds especially interesting for PaaS, SaaS etc. companies
  • 22. 22 Copyright 2014. Cloud History: User Evolution ▪ AWS wins the “feature race” − So many additional features mean that going for an AWS-only solution is an acceptable tradeoff ▪ AWS APIs become “de-facto standards” − Other providers are forced to support the S3 and EC2 APIs, either as the only APIs or as a compatibility option ▪ Many different types of cloud services appear − Also in an attempt to differentiate from the increasingly commoditized compute & blobstore markets − E.g. config management, logging, monitoring, ESBs, LXC containers etc. “as as Service” ▪ Leveraging cloud services becomes more common in “general business applications”
  • 23. 23 Copyright 2014. Cloud History: User Evolution ▪ The use case for cross-cloud computing changes: − For the most common abstractions, there seem to be standard APIs
  • 24. 24 Copyright 2014. Cloud History: User Evolution ▪ The use case for cross-cloud computing changes: − For the most common abstractions, there seem to be standard APIs ▪ Many new types of cloud service to deal with from within your application…how to do this?
  • 25. 25 Copyright 2014. The Cloud Monoculture Pitfall ▪ Q: Are compatible APIs fully compatible? − We seldom program directly against the API, we often use provider-supplied libraries instead − Writing an application using the API libraries of a provider doesn’t mean it will run unchanged against a different provider
  • 26. 26 Copyright 2014. The Cloud Monoculture Pitfall ▪ Q: Are compatible APIs fully compatible? − We seldom program directly against the API, we often use provider-supplied libraries instead − Writing an application using the API libraries of a provider doesn’t mean it will run unchanged against a different provider ▪ Q: Is feature X in the “compatible set” or the “provider-specific extension set”? − With APIs that are “de-facto standards” rather than published standards, it’s difficult/impossible to tell the difference
  • 27. 27 Copyright 2014. The Cloud Monoculture Pitfall ▪ Q: Are compatible APIs fully compatible? − We seldom program directly against the API, we often use provider-supplied libraries instead − Writing an application using the API libraries of a provider doesn’t mean it will run unchanged against a different provider ▪ Q: Is feature X in the “compatible set” or the “provider-specific extension set”? − With APIs that are “de-facto standards” rather than published standards, it’s difficult/impossible to tell the difference ▪ Q: Are “foundation ecosystems” safe from vendor lock-in? − Foundation members can be under commercial pressure, too
  • 28. 28 Copyright 2014. Multi-Cloud:Technology Benefits ▪ Handling cross-cutting concerns consistently − Logging, caching, failure handling, proxies etc. etc. − Working with N libraries for N services, each one of which handles these differently, is not so much fun
  • 29. 29 Copyright 2014. Multi-Cloud:Technology Benefits ▪ Handling cross-cutting concerns consistently − Logging, caching, failure handling, proxies etc. etc. − Working with N libraries for N services, each one of which handles these differently, is not so much fun ▪ “Positioning guide” for new services − Multi-cloud tools can either “map” a new service to an existing view, create a new abstraction type, or decide that the service is too new/unique to merit an abstraction type of its one − Helps see the new service in the context of more well-known services, and gauge its maturity level
  • 30. 30 Copyright 2014. Multi-Cloud:Technology Benefits ▪ Handling cross-cutting concerns consistently − Logging, caching, failure handling, proxies etc. etc. − Working with N libraries for N services, each one of which handles these differently, is not so much fun ▪ “Positioning guide” for new services − Multi-cloud tools can either “map” a new service to an existing view, create a new abstraction type, or decide that the service is too new/unique to merit an abstraction type of its one − Helps see the new service in the context of more well-known services, and gauge its maturity level ▪ Still cross-cloud use cases within commodity abstractions − Esp. for some of the commercial providers, e.g. VMware
  • 31. 31 Copyright 2014. Multi-Cloud: Knowledge Benefits ▪ Significant knowledge and experience of cross-cloud use cases − Real-world knowledge of using multiple providers and APIs − Ability to compare and gauge maturity of multiple providers and APIs
  • 32. 32 Copyright 2014. Multi-Cloud: Knowledge Benefits ▪ Significant knowledge and experience of cross-cloud use cases − Real-world knowledge of using multiple providers and APIs − Ability to compare and gauge maturity of multiple providers and APIs ▪ Learning and teaching resource − Gain insight into what functionality is shared, and what is provider-specific, across views − “Free” training and guidance through the community
  • 33. 33 Copyright 2014. Multi-Cloud: Knowledge Benefits ▪ Significant knowledge and experience of cross-cloud use cases − Real-world knowledge of using multiple providers and APIs − Ability to compare and gauge maturity of multiple providers and APIs ▪ Learning and teaching resource − Gain insight into what functionality is shared, and what is provider-specific, across views − “Free” training and guidance through the community ▪ Expert network − Learn about tools and services that deliver cross-cloud functionality − No need to waste time building it yourself if a suitable tool already exists out there!
  • 34. 34 Copyright 2014. Q & A ▪ Over to you!
  • 35. Thank You!
  • 36. Thank You! jclouds.apache.org

×