Keynote Roberto Delamora - AWS Cloud Experience Argentina
0 likes334 views
This document discusses digital transformation and moving to the cloud. It outlines some common blockers to innovation such as culture, skills, organization and finance. It then presents a pathway for digital transformation including gaining time to value quickly, distributing workloads for availability, optimizing costs with high utilization, and moving critical workloads off datacenter infrastructure. The document advocates adopting cloud native principles like pay for what you use, self-service automation, global distribution, high utilization and immutable infrastructure. It also discusses using a "chaos architecture" with chaos engineering practices to test resilience and build safety margins without outages.
Keynote Roberto Delamora - AWS Cloud Experience Argentina
- 1. 2 0 1 9
- 2. AWS: Unblocking Innovation for Digital Transformation Roberto D. De La Mora Principal Business Development - LATAM
- 3. OLD WORLD IT Employees at work Factories + supply chainSales channels Marketing analytics
- 4. Employees at work Factories + supply chainSales channels Marketing analytics OLD WORLD IT NEW WORLD IT
- 5. NEW WORLD IT Employees at work Factories + supply chain IoT connected things Online marketing Continuous supply tracking Just in time production Online sales + delivery Social media
- 6. Personalization Customer tracking New channels direct to customer More things, more scale, rapid change New Needs
- 7. “Through 2021, 75% of digital leaders will dominate a disruptive market segment that did not exist prior to their ascendance… disruption will become the norm.” —Gartner Predicts 2018, 21 December 2017
- 8. AWS: Unblocking Innovation for Digital Transformation with Enterprise Customers
- 10. Digital Transformation Is Key To Survival For Enterprises
- 11. Blockers for Innovation Culture Skills Organization Finance Leadership Systems and Feedback Training and Compensation Move from Projects to Product Teams Capex Versus Opex
- 12. Centralized decision making Lack of trust Inflexible policies and processes Leadership Systems and Feedback
- 13. Blockers for Innovation Culture Skills Organization Finance Leadership Systems and Feedback Training and Compensation Move from Projects to Product Teams Capex Versus Opex
- 14. Train existing staff on cloud tech Fund pathfinder teams Be prepared to pay more to keep the best people after training! Training and Compensation
- 15. Blockers for Innovation Culture Skills Organization Finance Leadership Systems and Feedback Training and Compensation Move from Projects to Product Teams Capex Versus Opex
- 16. Move from Projects to Product Teams Long term product ownership Continuous delivery DevOps and “run what you wrote” Reduce tech-debt and lock-in
- 17. Blockers for Innovation Culture Skills Organization Finance Leadership Systems and Feedback Training and Compensation Move from Projects to Product Teams Capex Versus Opex
- 18. Datacenter to Cloud Waterfall to Agile and DevOps Understand the impact Plan ahead, don’t surprise the CFO Capex Versus Opex
- 19. Pathway for Digital Transformation Speed Scale Strategic Time to Value Distributed Optimized Capacity Critical Workloads Datacenter Replacement !
- 20. The fast companies are 440x faster than the slow Months Hours We found that, compared to low performers, high performers have: 46 times more frequent code deployments 440 times faster lead time from commit to deploy 170 times faster mean time to recover from downtime 5.0 times lower change failure rate (1/5 as likely for a change to fail) https://itrevolution.com/book/accelerate/ Time to Value
- 21. Pathway for Digital Transformation Speed Scale Strategic ! Time to Value Distributed Optimized Capacity Critical Workloads Datacenter Replacement
- 22. Highly Scaled Distributed for Availability Cost Optimized High Utilization Cloud Native Architecture Distributed Optimized Capacity
- 23. Cloud Native Architecture Laura Caicedo Solutions Architect AWS MCO
- 24. Cloud Native Architecture Principles and Practices
- 26. Infrastructure Datacenter Native Architecture Lives for years DATACENTER
- 27. Cloud Migration Pay as you go DATACENTER Applications and data Pay up front and depreciate over three years Pay a month later for the number of seconds used
- 28. Cloud Native Principle Pay for what you used last month Not what you guess you will need next year
- 29. File tickets and wait for every step Self service, on-demand, no delays ! VS !!
- 30. File tickets and wait for every step Self service, on-demand, no delays ! VS !! Deploy by filing a ticket and waiting weeks or months Deploy by making an API call self service within minutes
- 31. Cloud Native Principle Self service, API driven, automated Move from request tickets at every step to a tracking ticket that records what happened
- 32. Cloud Native Principle Instant globally distributed deployments and data by default
- 33. Elasticity DATACENTER Hard to get over 30% utilization— need extra capacity in case of peak CLOUD Target over 70% utilization— no capacity overload issues
- 34. Autoscaling for predictable heavy workloads Serverless for spiky workloads with idle periods
- 35. Cloud Native Principle Turn it off when it’s idle Many times higher utilization Huge cost savings Avoids capacity overloads
- 36. Cloud Native Principle Immutable code Automated builds Ephemeral instances, containers, and functions Blue–Green deployments Versioned services
- 37. Pay as you go, afterwards Self service—no waiting Globally distributed by default Cross-zone/region availability models High utilization—turn idle resources off Immutable code deployments Cloud Native Principles
- 38. Pathway for Digital Transformation Speed Scale Strategic ! Time to Value Distributed Optimized Capacity Critical Workloads Datacenter Replacement
- 39. ! Core Banking Industrial Control Systems Transport Healthcare Critical Workloads Datacenter Replacement
- 40. How do you know if you have a good architecture for critical systems? Ask some awkward questions…
- 41. What should your system do when something fails? Stop? Carry on with reduced functionality?
- 42. How often do you failover apps to it? How often do you failover the whole datacenter at once? “Availability Theater” What should your system do when something fails? Do you have a backup datacenter?
- 43. A fairy tale… Once upon a time, in theory, if everything works perfectly, we have a plan to survive the disasters we thought of in advanceHow did that work out?
- 44. Datacenter flooded in hurricane Sandy… Finance company, Jersey City Didn’t update security certificate and it expired… Entertainment site Forgot to renew domain name… SaaS vendor Whoops! YOU, tomorrow
- 45. “You can’t legislate against failure, focus on fast detection and response.” —Chris Pinkham
- 46. How is it supposed to recover after the failure goes away? What is supposed to happen when part of the system fails?
- 47. The Network Is Reliable ACM Queue 2014 Bailiss & Kingsbury @pbailiss @aphyr ACM Queue is a bimonthly computer magazine founded and published by the Association for Computing Machinery. The magazine was established in 2003. https://queue.acm.org/detail.cfm?id=2655736
- 48. Drift Into Failure Sydney Dekker
- 49. Release It! Second Edition 2017 Michael Nygard
- 50. Chaos Architecture A Cloud Native Availability Model
- 53. I wonder why it did that? Let’s reboot it. Whoops! Now it’s really brokenUnexpected application behavior often causes people to intervene and make the situation worse People
- 54. A fire drill is a boring routine where we make everyone take the stairs and assemble in the parking lot People Training !
- 55. Fire drills save lives in the event of a real fire, because people are trained how to react People Training
- 56. Infrastructure Switching Application People Who runs the “fire drill” for I.T.?
- 59. Infrastructure Switching Application People Chaos Engineering Team Tools Security Red Team Tools Four layers Two teams An attitude— Break it to prove it’s resilient Chaos Architecture
- 60. Failures are a system problem— lack of safety margin Not something with a root cause of component or human error
- 61. Hypothesis testing We think we have safety margin in this dimension, let’s carefully test to be sure In production Without causing an issue
- 62. The New View of Safety Todd Conklin’s Pre-accident podcast John Allspaw’s stella.report Sydney Dekker—Drift into Failure
- 63. Experienced Staff Robust Applications Dependable Switching Fabric Redundant Service Foundation
- 64. Pathway for Digital Transformation Speed Scale Strategic ! Time to Value Distributed Optimized Capacity Critical Workloads Datacenter Replacement
- 65. ¡GRACIAS!