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.

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