The Multiple Dimensions of Cross-Cloud Computing

485 views

Published on

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
485
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The Multiple Dimensions of Cross-Cloud Computing

  1. 1. The Multiple Dimensions of Cross-Cloud Computing Andrew Phillips | 28 April 2014
  2. 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. 3 Copyright 2014. FirstThings First Thanks!
  4. 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. 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. 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. 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. 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. 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. 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. 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. 12 Copyright 2014. Cloud History:Then… Abstraction diversity API diversity
  13. 13. 13 Copyright 2014. Cloud History: …and Now Abstraction diversity API diversity
  14. 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. 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. 16 Copyright 2014. Cloud History:Technology Evolution ▪ In short: within a particular abstraction, it’s easier to identify a (semi-)standard API…
  17. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 34 Copyright 2014. Q & A ▪ Over to you!
  35. 35. Thank You!
  36. 36. Thank You! jclouds.apache.org

×