Successfully reported this slideshow.
Your SlideShare is downloading. ×

Debunking Myths About Cloud Portability

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 42 Ad

Debunking Myths About Cloud Portability

Download to read offline

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

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

Advertisement
Advertisement

More Related Content

Similar to Debunking Myths About Cloud Portability (20)

More from VMware Tanzu (20)

Advertisement

Recently uploaded (20)

Debunking Myths About Cloud Portability

  1. 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. 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. 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. 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. 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. 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. 7. If it’s open source, I can port it wherever I need to Myth Image Credit: KLOTZ,CC BY-SA 3.0
  8. 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. 9. Cover w/ Image Berkholz Accordion Photo Credit: © Jorge Royan / http://www.royan.com.ar / CC BY-SA 3.0 Standards Innovation
  10. 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. 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. 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. 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. 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. 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. 16. Cloud portability is at odds with Developer Choice Myth Image credit: Wikipedia: The Judgement of Paris, Francois-Xavier Fabre
  17. 17. The best design uses gears from the middle of the list Feynman Gears http://bdml.stanford.edu/Main/FeynmanGears
  18. 18. Cover w/ Image McKenty’s Ratio How much choice do people really need? Photo Credit: lyzadanger, CC-BY-SA-2.0
  19. 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. 20. Cover w/ Image McKenty’s Ratio Sometimes you need the bespoke one-offs Photo Credit: Jacek Halicki, CC BY-SA 4.0
  21. 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. 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. 23. Cover w/ Image McKenty’s Ratio: Example Service Choice Instance Cluster Plan Binding RabbitMQ on-demand 3 nodes “Gold” My App
  24. 24. Every Additional Developer Choice You Support Adds Proportionate Ops Overhead Myth Image credit: Wikipedia, Sisyphus, by Franz von Stuck
  25. 25. Cover w/ Image Uli’s Separation Where possible, separate API’s/ protocols from engine implementation
  26. 26. Cover w/ Image Uli’s Separation Engine API/Protocol
  27. 27. Cover w/ Image Uli’s Separation Engine API/Protocol Let developers use the latest, native APIs/Protocols available…
  28. 28. Cover w/ Image Uli’s Separation Engine API/Protocol … But let operators simplify how they ensure availability
  29. 29. Cover w/ Image Uli’s Separation Engine API/Protocol
  30. 30. Cover w/ Image Uli’s Separation: Example CosmosDB MongoDB
  31. 31. Cover w/ Image Uli’s Separation: Example Azure Event Hub Kafka API
  32. 32. Prioritize To Modernize Applying the theory
  33. 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. 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. 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. 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. 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. 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. 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. 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. 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. 42. Transforming How The World Builds Software © Copyright 2018 Pivotal Software, Inc. All rights Reserved.

×