The Multiple Dimensions of Cross-Cloud Computing
0 likes651 views
The document discusses the benefits of cross-cloud computing and using multiple cloud providers. It describes how cloud technologies and user needs have evolved over time, moving from diverse APIs across providers to more standardized APIs within common abstractions like storage and computing. However, using a single provider still poses risks of vendor lock-in. Multi-cloud approaches help address these risks by providing consistent ways to work with different cloud services and gain experience/knowledge using multiple providers.
The Multiple Dimensions of Cross-Cloud Computing
- 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!