When moving workloads to the cloud, enterprise architects often ask things like, “Are we losing the ability to choose our stack and change vendors? How easily can I move my workloads in and out of the cloud? To keep workloads portable, do I lose out on innovation?” There are a lot of misconceptions about cloud portability. The term itself implies moving workloads with no work (not true), suggests completeness in what’s moved (mileage may vary), and ignores the laws of data gravity (at your peril!). Platforms, like Pivotal Cloud Foundry (PCF), can make it much simpler to move workloads between clouds. But PCF fits within a broader set of concerns and decisions that need to be made. In this webinar, Pivotal’s Joshua McKenty and Microsoft’s Ulrich Homann will debunk some common misconceptions about cloud portability, while explaining things like: - The framework of developer efficiency (versus operational efficiency) tradeoffs across levels of abstraction - The spectrum of standards that exist to support movability, and the tradeoffs therein - Emerging abstractions at the data layer that simplify data access and digital twin development… and the realities of the cloud movability they support This event is jointly operated by Pivotal and Microsoft, and both companies are committed to protecting your privacy. Any personal information we collect from you on this site may be shared between Pivotal and Microsoft. For complete information on the data collection and use practices of each company, please read the full privacy statements by clicking on the links below. Ulrich Homann, Distinguished Architect at Microsoft and Josh McKenty, Vice President of Technology at Pivotal

1. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0
Ulrich Homann, Distinguished Architect at Microsoft
Josh McKenty, Vice President of Technology at Pivotal
May 31, 2018
Debunking Myths About
Cloud Portability

2. If I only use the most basic
cloud services, my application
is portable
Myth
Image Credit: Ad Meskens,CC BY-SA 3.0

3. Cover w/ Image
Seroter’s Theory
You can’t avoid lock-in
everywhere. Portability
versus lock-in is a
business decision, not a
technical one.
Image credit: Flickr, pshutterbug, CC 2.0

4. Cover w/ Image
Seroter’s Theory
Image credit: Flickr, pshutterbug, CC 2.0
Standards
What I build
Standards
What I build
Proprietary
Stuff
More
portability
Less
portability

5. Cover w/ Image
Seroter’s Theory
Image credit: Flickr, pshutterbug, CC 2.0
Standards
What I build
Standards
What I build
Proprietary
Stuff
More
portability
Less
portability
Differentiating code
(above the “value line”)

6. Cover w/ Image
Seroter’s Theory
Image credit: Flickr, pshutterbug, CC 2.0
Standards
$$$$
Standards
$$$
$
More
portability
Less
portability
How much are you spending
“below the value line” in this
scenario?

7. If it’s open source, I can port it
wherever I need to
Myth
Image Credit: KLOTZ,CC BY-SA 3.0

8. Cover w/ Image
Berkholz Accordion
IT is like an accordion
and at any moment,
there are parts of it that
are expanding and
parts of it that are
contracting.
Photo Credit: © Jorge Royan / http://www.royan.com.ar / CC BY-SA 3.0

9. Cover w/ Image
Berkholz Accordion
Photo Credit: © Jorge Royan / http://www.royan.com.ar / CC BY-SA 3.0
Standards
Innovation

10. Cover w/ Image
Technical Tradeoffs
Photo Credit: © Jorge Royan / http://www.royan.com.ar / CC BY-SA 3.0
Standards
Innovation
More choices
More portability

11. Cover w/ Image
Business Tradeoffs
Photo Credit: © Jorge Royan / http://www.royan.com.ar / CC BY-SA 3.0
Standards
Innovation
More differentiation
More efficiency

12. Cover w/ Image
For Example (today)
Photo Credit: © Jorge Royan / http://www.royan.com.ar / CC BY-SA 3.0
Standards
Innovation
AI/ML, Serverless
TCP, HTTP, 19” rack
Linux, Windows, MySQL
K8s, Tensorflow

13. Cover w/ Image
Along the spectrum
Photo Credit: © Jorge Royan / http://www.royan.com.ar / CC BY-SA 3.0
Standards
Innovation
Discoveries
De jure standards
De facto standards
Community

14. Cover w/ Image
Beware of the Grey Zone
Photo Credit: © Jorge Royan / http://www.royan.com.ar / CC BY-SA 3.0
Standards
Innovation
Discoveries
De jure standards
De facto standards
The Grey Zone

15. Cover w/ Image
The Fat Middle Problem
Photo Credit: © Jorge Royan / http://www.royan.com.ar / CC BY-SA 3.0
Innovation
Bespoke one-offs
Mass operationalize
No Man’s Land:
Pick a direction!

16. Cloud portability is at odds
with Developer Choice
Myth
Image credit: Wikipedia: The Judgement of Paris, Francois-Xavier Fabre

17. The best design uses gears
from the middle of the list
Feynman Gears
http://bdml.stanford.edu/Main/FeynmanGears

18. Cover w/ Image
McKenty’s Ratio
How much choice do
people really need?
Photo Credit: lyzadanger, CC-BY-SA-2.0

19. Cover w/ Image
McKenty’s Ratio
5:2
No more than five
categories.
No more than two
options per category.
Photo Credit: lyzadanger, CC-BY-SA-2.0

20. Cover w/ Image
McKenty’s Ratio
Sometimes you need
the bespoke one-offs
Photo Credit: Jacek Halicki, CC BY-SA 4.0

21. Cover w/ Image
McKenty’s Ratio
Image Credit: Ashley Pomeroy, CC-BY-SA-4.0
Where possible, offer
de facto standards with
options that meet a
wide range of developer
needs

22. Cover w/ Image
McKenty’s Ratio: Example
Image Credit: Ashley Pomeroy, CC-BY-SA-4.0
DataManagement
Document
database
Cache
MongoDB
CouchDB
GemFire
Redis
SQL
Database
SQL Server
PostgreSQL

23. Cover w/ Image
McKenty’s Ratio: Example
Service Choice
Instance
Cluster
Plan
Binding
RabbitMQ
on-demand
3 nodes
“Gold”
My App

24. Every Additional Developer
Choice You Support Adds
Proportionate Ops Overhead
Myth
Image credit: Wikipedia, Sisyphus, by Franz von Stuck

25. Cover w/ Image
Uli’s Separation
Where possible,
separate API’s/
protocols from engine
implementation

26. Cover w/ Image
Uli’s Separation
Engine
API/Protocol

27. Cover w/ Image
Uli’s Separation
Engine
API/Protocol
Let developers use the latest, native
APIs/Protocols available…

28. Cover w/ Image
Uli’s Separation
Engine
API/Protocol
… But let operators simplify how they
ensure availability

29. Cover w/ Image
Uli’s Separation
Engine
API/Protocol

30. Cover w/ Image
Uli’s Separation: Example
CosmosDB
MongoDB

31. Cover w/ Image
Uli’s Separation: Example
Azure Event
Hub
Kafka API

32. Prioritize To Modernize
Applying the theory

33. First, optimize for unlocking business value
Two dimensions matter for
unlocking business value
1. Velocity of change
i.e. How often does this
application need to change?
2. Developer productivity/
efficiency
i.e. How many people does it
take to change this application
Lots of
changes
Few
changes
High Dev Efficiency
Low Dev Efficiency

34. Later, evaluate for operational efficiency (and other)
Two dimensions matter AFTER
unlocking business value
1. Operational Efficiency
i.e. How much does it cost to
keep it running?
2. Other (e.g. industry specific
requirements, etc.)
Lots of
changes
Few
changes
High Dev Efficiency
Low Dev Efficiency
We’ll come back to cost later...

35. First, optimize for unlocking business value
Few Changes Needed, Low Dev
Efficiency
Bias towards leaving it where it
is…
UNLESS the cost to operate is
high
Low ops cost?
Leave it!
Lots of
changes
Few
changes
High Dev Efficiency
Low Dev Efficiency

36. First, optimize for unlocking business value
Few Changes Needed, High Dev
Efficiency
Also, leave it where it is… unless it
has a high cost to operate
Low ops cost?
Leave it!
Low ops cost?
Leave it!
Lots of
changes
Few
changes
High Dev Efficiency
Low Dev Efficiency

37. Low ops cost?
Leave it!
Replatform
+
CI/CD
Low ops cost?
Leave it!
First, optimize for unlocking business value
Lots Changes Needed, High Dev
Efficiency
Replatform
Invest in CI/CD pipelines
4 Factors:
● One process, one port
● No local filesystem usage
● All logging is to STDERR and
STDOUT
● Unceremonial startup script
Lots of
changes
Few
changes
High Dev Efficiency
Low Dev Efficiency

38. Invest
Low ops cost?
Leave it!
Replatform
+
CI/CD
Low ops cost?
Leave it!
First, optimize for unlocking business value
Lots Changes Needed, Low Dev
Efficiency
Invest in modernizing
- Decompose monoliths
- Build CI/CD pipelines
- Run on a cloud-native platform
Lots of
changes
Few
changes
High Dev Efficiency
Low Dev Efficiency

39. Invest
Low ops cost?
Leave it!
Replatform
+
CI/CD
Low ops cost?
Leave it!
Decisions on the Margin: Apps That Drive Business Value
Lots of
changes
Few
changes
High Dev Efficiency
Low Dev Efficiency
Degree of abstraction/level of innovation
Developerefficiencypotential
What innovations will let
developers unlock
business value faster?

40. Portability is Tertiary to Maximizing Dev and Ops Efficiency
Physical VMs Containers 4-Factor PaaS 12-Factor Platform Serverless
Efficiencypotential
Maximize the Ops
efficiency for a given
innovation
Ops
Dev

41. Steps to Cloud Mobile
A Framework for Navigating Trade-offs
● No such thing as “cloud portability”. There are only degrees of
re-work required.
● Standardize where possible for maximum operational efficiency
● Provide developers choices within manageable guardrails
● Look for implementations of Uli’s Separation to further
maximize developer choice with operational efficiency
● Analyze your application portfolio to prioritize what needs
modernization and how movable it needs to be

42. Transforming How The World Builds Software
© Copyright 2018 Pivotal Software, Inc. All rights Reserved.