Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Innovation and Architecture

10,710 views

Published on

Updated slides for 2016 presentation on innovation in large organizations, why microservices and Docker can be useful, thoughts on monitoring for large complex architectures, some discussion of new topics - serverless architectures AWS Lambda and teraservices.

Published in: Technology

Innovation and Architecture

  1. 1. Innovation and Architecture Adrian Cockcroft @adrianco Technology Fellow - Battery Ventures January 2016
  2. 2. What does @adrianco do? @adrianco Technology Due Diligence on Deals Presentations at Conferences Presentations at Companies Technical Advice for Portfolio Companies Program Committee for Conferences Networking with Interesting PeopleTinkering with Technologies Maintain Relationship with Cloud Vendors
  3. 3. Why am I here? %*&!” By Simon Wardley http://enterpriseitadoption.com/
  4. 4. Why am I here? %*&!” By Simon Wardley http://enterpriseitadoption.com/ 2009
  5. 5. Why am I here? %*&!” By Simon Wardley http://enterpriseitadoption.com/ 2009
  6. 6. Why am I here? @adrianco’s job at the intersection of cloud and Enterprise IT, looking for disruption and opportunities. %*&!” By Simon Wardley http://enterpriseitadoption.com/ 20142009 Disruptions in 2016 coming from server- less computing and teraservices.
  7. 7. What I learned from my time at Netflix
  8. 8. What I learned from my time at Netflix •Speed wins in the marketplace
  9. 9. What I learned from my time at Netflix •Speed wins in the marketplace •Remove friction from product development
  10. 10. What I learned from my time at Netflix •Speed wins in the marketplace •Remove friction from product development •High trust, low process, no hand-offs between teams
  11. 11. What I learned from my time at Netflix •Speed wins in the marketplace •Remove friction from product development •High trust, low process, no hand-offs between teams •Freedom and responsibility culture
  12. 12. What I learned from my time at Netflix •Speed wins in the marketplace •Remove friction from product development •High trust, low process, no hand-offs between teams •Freedom and responsibility culture •Don’t do your own undifferentiated heavy lifting
  13. 13. What I learned from my time at Netflix •Speed wins in the marketplace •Remove friction from product development •High trust, low process, no hand-offs between teams •Freedom and responsibility culture •Don’t do your own undifferentiated heavy lifting •Use simple patterns automated by tooling
  14. 14. What I learned from my time at Netflix •Speed wins in the marketplace •Remove friction from product development •High trust, low process, no hand-offs between teams •Freedom and responsibility culture •Don’t do your own undifferentiated heavy lifting •Use simple patterns automated by tooling •Self service cloud makes impossible things instant
  15. 15. “You build it, you run it.” Werner Vogels 2006
  16. 16. In 2014 Enterprises finally embraced public cloud and in 2015 began replacing entire datacenters.
  17. 17. In 2014 Enterprises finally embraced public cloud and in 2015 began replacing entire datacenters. Oct 2014
  18. 18. In 2014 Enterprises finally embraced public cloud and in 2015 began replacing entire datacenters. Oct 2014 Oct 2015
  19. 19. In 2014 Enterprises finally embraced public cloud and in 2015 began replacing entire datacenters. Oct 2014 Oct 2015
  20. 20. Key Goals of the CIO? Align IT with the business Develop products faster Try not to get breached
  21. 21. Security Blanket Failure Insecure applications hidden behind firewalls make you feel safe until the breach happens… http://peanuts.wikia.com/wiki/Linus'_security_blanket
  22. 22. What needs to change?
  23. 23. Developer responsibilities: Faster, cheaper, safer
  24. 24. “It isn't what we don't know that gives us trouble, it's what we know that ain't so.” Will Rogers
  25. 25. Assumptions
  26. 26. Optimizations
  27. 27. Assumption: Process prevents problems
  28. 28. Organizations build up slow complex “Scar tissue” processes
  29. 29. Product Development Processes
  30. 30. Value Chain Mapping Simon Wardley http://blog.gardeviance.org/2014/11/how-to-get-to-strategy-in-ten-steps.html Related tools and training http://www.wardleymaps.com/
  31. 31. Value Chain Mapping Simon Wardley http://blog.gardeviance.org/2014/11/how-to-get-to-strategy-in-ten-steps.html Related tools and training http://www.wardleymaps.com/ Your unique product - Agile
  32. 32. Value Chain Mapping Simon Wardley http://blog.gardeviance.org/2014/11/how-to-get-to-strategy-in-ten-steps.html Related tools and training http://www.wardleymaps.com/ Your unique product - Agile Best of breed as a Service - Lean
  33. 33. Value Chain Mapping Simon Wardley http://blog.gardeviance.org/2014/11/how-to-get-to-strategy-in-ten-steps.html Related tools and training http://www.wardleymaps.com/ Your unique product - Agile Undifferentiated utility suppliers - 6sigma Best of breed as a Service - Lean
  34. 34. Observe Orient Decide Act Continuous Delivery
  35. 35. Observe Orient Decide Act Land grab opportunity Competitive Move Customer Pain Point Measure Customers Continuous Delivery
  36. 36. Observe Orient Decide Act Land grab opportunity Competitive Move Customer Pain Point INNOVATION Measure Customers Continuous Delivery
  37. 37. Observe Orient Decide Act Land grab opportunity Competitive Move Customer Pain Point Analysis Model Hypotheses INNOVATION Measure Customers Continuous Delivery
  38. 38. Observe Orient Decide Act Land grab opportunity Competitive Move Customer Pain Point Analysis Model Hypotheses BIG DATA INNOVATION Measure Customers Continuous Delivery
  39. 39. Observe Orient Decide Act Land grab opportunity Competitive Move Customer Pain Point Analysis JFDI Plan Response Share Plans Model Hypotheses BIG DATA INNOVATION Measure Customers Continuous Delivery
  40. 40. Observe Orient Decide Act Land grab opportunity Competitive Move Customer Pain Point Analysis JFDI Plan Response Share Plans Model Hypotheses BIG DATA INNOVATION CULTURE Measure Customers Continuous Delivery
  41. 41. Observe Orient Decide Act Land grab opportunity Competitive Move Customer Pain Point Analysis JFDI Plan Response Share Plans Incremental Features Automatic Deploy Launch AB Test Model Hypotheses BIG DATA INNOVATION CULTURE Measure Customers Continuous Delivery
  42. 42. Observe Orient Decide Act Land grab opportunity Competitive Move Customer Pain Point Analysis JFDI Plan Response Share Plans Incremental Features Automatic Deploy Launch AB Test Model Hypotheses BIG DATA INNOVATION CULTURE CLOUD Measure Customers Continuous Delivery
  43. 43. Observe Orient Decide Act Land grab opportunity Competitive Move Customer Pain Point Analysis JFDI Plan Response Share Plans Incremental Features Automatic Deploy Launch AB Test Model Hypotheses BIG DATA INNOVATION CULTURE CLOUD Measure Customers Continuous Delivery
  44. 44. Observe Orient Decide Act Land grab opportunity Competitive Move Customer Pain Point Analysis JFDI Plan Response Share Plans Incremental Features Automatic Deploy Launch AB Test Model Hypotheses BIG DATA INNOVATION CULTURE CLOUD Measure Customers Continuous Delivery
  45. 45. Breaking Down the SILOs
  46. 46. Breaking Down the SILOs QA DBA Sys Adm Net Adm SAN Adm DevUX Prod Mgr
  47. 47. Breaking Down the SILOs QA DBA Sys Adm Net Adm SAN Adm DevUX Prod Mgr Product Team Using Monolithic Delivery Product Team Using Monolithic Delivery
  48. 48. Breaking Down the SILOs QA DBA Sys Adm Net Adm SAN Adm DevUX Prod Mgr Product Team Using Microservices Product Team Using Monolithic Delivery Product Team Using Microservices Product Team Using Microservices Product Team Using Monolithic Delivery
  49. 49. Breaking Down the SILOs QA DBA Sys Adm Net Adm SAN Adm DevUX Prod Mgr Product Team Using Microservices Product Team Using Monolithic Delivery Platform TeamProduct Team Using Microservices Product Team Using Microservices Product Team Using Monolithic Delivery
  50. 50. Breaking Down the SILOs QA DBA Sys Adm Net Adm SAN Adm DevUX Prod Mgr Product Team Using Microservices Product Team Using Monolithic Delivery Platform Team A P I Product Team Using Microservices Product Team Using Microservices Product Team Using Monolithic Delivery
  51. 51. Breaking Down the SILOs QA DBA Sys Adm Net Adm SAN Adm DevUX Prod Mgr Product Team Using Microservices Product Team Using Monolithic Delivery Platform Team Re-Org from project teams to product teams A P I Product Team Using Microservices Product Team Using Microservices Product Team Using Monolithic Delivery
  52. 52. Release Plan Developer Developer Developer Developer Developer QA Release Integration Ops Replace Old With New Release Monolithic service updates Works well with a small number of developers and a single language like php, java or ruby
  53. 53. Release Plan Developer Developer Developer Developer Developer QA Release Integration Ops Replace Old With New Release Bugs Monolithic service updates Works well with a small number of developers and a single language like php, java or ruby
  54. 54. Release Plan Developer Developer Developer Developer Developer QA Release Integration Ops Replace Old With New Release Bugs Bugs Monolithic service updates Works well with a small number of developers and a single language like php, java or ruby
  55. 55. Use monolithic apps for small teams, simple systems and when you must, to optimize for efficiency and latency
  56. 56. Developer Developer Developer Developer Developer Old Release Still Running Release Plan Release Plan Release Plan Release Plan Immutable microservice deployment scales, is faster with large teams and diverse platform components
  57. 57. Developer Developer Developer Developer Developer Old Release Still Running Release Plan Release Plan Release Plan Release Plan Deploy Feature to Production Deploy Feature to Production Deploy Feature to Production Deploy Feature to Production Immutable microservice deployment scales, is faster with large teams and diverse platform components
  58. 58. Developer Developer Developer Developer Developer Old Release Still Running Release Plan Release Plan Release Plan Release Plan Deploy Feature to Production Deploy Feature to Production Deploy Feature to Production Deploy Feature to Production Bugs Immutable microservice deployment scales, is faster with large teams and diverse platform components
  59. 59. Developer Developer Developer Developer Developer Old Release Still Running Release Plan Release Plan Release Plan Release Plan Deploy Feature to Production Deploy Feature to Production Deploy Feature to Production Deploy Feature to Production Bugs Deploy Feature to Production Immutable microservice deployment scales, is faster with large teams and diverse platform components
  60. 60. Configure Configure Developer Developer Developer Release Plan Release Plan Release Plan Deploy Standardized Services Standardized container deployment saves time and effort https://hub.docker.com
  61. 61. Configure Configure Developer Developer Developer Release Plan Release Plan Release Plan Deploy Standardized Services Deploy Feature to Production Deploy Feature to Production Deploy Feature to Production Bugs Deploy Feature to Production Standardized container deployment saves time and effort https://hub.docker.com
  62. 62. Developer Developer Run What You Wrote Developer Developer
  63. 63. Developer Developer Run What You Wrote Micro service Micro service Micro service Micro service Micro service Micro service Micro service Developer Developer
  64. 64. Developer Developer Run What You Wrote Micro service Micro service Micro service Micro service Micro service Micro service Micro service Developer Developer Monitoring Tools
  65. 65. DeveloperDeveloper Developer Run What You Wrote Micro service Micro service Micro service Micro service Micro service Micro service Micro service Developer Developer Monitoring Tools
  66. 66. DeveloperDeveloper Developer Run What You Wrote Micro service Micro service Micro service Micro service Micro service Micro service Micro service Developer Developer Site Reliability Monitoring Tools Availability Metrics 99.95% customer success rate
  67. 67. DeveloperDeveloper Developer Run What You Wrote Micro service Micro service Micro service Micro service Micro service Micro service Micro service Developer Developer Manager Manager Site Reliability Monitoring Tools Availability Metrics 99.95% customer success rate
  68. 68. DeveloperDeveloper Developer Run What You Wrote Micro service Micro service Micro service Micro service Micro service Micro service Micro service Developer Developer Manager Manager VP Engineering Site Reliability Monitoring Tools Availability Metrics 99.95% customer success rate
  69. 69. Change One Thing at a Time!
  70. 70. What Happened? Rate of change increased Cost and size and risk of change reduced
  71. 71. Low Cost of Change Using Docker Developers • Compile/Build • Seconds Extend container • Package dependencies • Seconds PaaS deploy Container • Docker startup • Seconds
  72. 72. Low Cost of Change Using Docker Fast tooling supports continuous delivery of many tiny changes Developers • Compile/Build • Seconds Extend container • Package dependencies • Seconds PaaS deploy Container • Docker startup • Seconds
  73. 73. Disruptor: Continuous Delivery with Containerized Microservices
  74. 74. Microservices
  75. 75. A Microservice Definition Loosely coupled service oriented architecture with bounded contexts
  76. 76. A Microservice Definition Loosely coupled service oriented architecture with bounded contexts If every service has to be updated at the same time it’s not loosely coupled
  77. 77. A Microservice Definition Loosely coupled service oriented architecture with bounded contexts If every service has to be updated at the same time it’s not loosely coupled If you have to know too much about surrounding services you don’t have a bounded context. See the Domain Driven Design book by Eric Evans.
  78. 78. Speeding Up The Platform Datacenter Snowflakes • Deploy in months • Live for years
  79. 79. Speeding Up The Platform Datacenter Snowflakes • Deploy in months • Live for years Virtualized and Cloud • Deploy in minutes • Live for weeks
  80. 80. Speeding Up The Platform Datacenter Snowflakes • Deploy in months • Live for years Virtualized and Cloud • Deploy in minutes • Live for weeks Container Deployments • Deploy in seconds • Live for minutes/hours
  81. 81. Speeding Up The Platform Datacenter Snowflakes • Deploy in months • Live for years Virtualized and Cloud • Deploy in minutes • Live for weeks Container Deployments • Deploy in seconds • Live for minutes/hours Lambda Deployments • Deploy in milliseconds • Live for seconds
  82. 82. Speeding Up The Platform AWS Lambda is leading exploration of serverless architectures in 2016 Datacenter Snowflakes • Deploy in months • Live for years Virtualized and Cloud • Deploy in minutes • Live for weeks Container Deployments • Deploy in seconds • Live for minutes/hours Lambda Deployments • Deploy in milliseconds • Live for seconds
  83. 83. Inspiration
  84. 84. http://www.infoq.com/presentations/Twitter-Timeline-Scalability http://www.infoq.com/presentations/twitter-soa http://www.infoq.com/presentations/Zipkin http://www.infoq.com/presentations/scale-gilt Go-Kit https://www.youtube.com/watch?v=aL6sd4d4hxk http://www.infoq.com/presentations/circuit-breaking-distributed-systems https://speakerdeck.com/mattheath/scaling-micro-services-in-go-highload-plus-plus-2014 State of the Art in Web Scale Microservice Architectures AWS Re:Invent : Asgard to Zuul https://www.youtube.com/watch?v=p7ysHhs5hl0 Resiliency at Massive Scale https://www.youtube.com/watch?v=ZfYJHtVL1_w Microservice Architecture https://www.youtube.com/watch?v=CriDUYtfrjs New projects for 2015 and Docker Packaging https://www.youtube.com/watch?v=hi7BDAtjfKY Spinnaker deployment pipeline https://www.youtube.com/watch?v=dwdVwE52KkU http://www.infoq.com/presentations/spring-cloud-2015
  85. 85. Microservice Concerns ConfigurationTooling Discovery Routing Observability Development: Languages and Container Operational: Orchestration and Deployment Infrastructure Datastores Policy: Architectural and Security Compliance
  86. 86. Microservices Edda Archaius Configuration Spinnaker SpringCloud Tooling Eureka Prana Discovery Denominator Zuul Ribbon Routing Hystrix Pytheus Atlas Observability Development using Java, Groovy, Scala, Clojure, Python with AMI and Docker Containers Deployment Orchestration with Spinnaker on AWS or Google Cloud Ephemeral datastores using Dynomite, Memcached, Astyanax, Staash, Priam, Cassandra Policy via the Simian Army - Chaos Monkey, Chaos Gorilla, Conformity Monkey, Security Monkey
  87. 87. ! Edda - the “black box flight recorder” for configuration state ! Chaos Monkey - enforcing stateless business logic ! Chaos Gorilla - enforcing zone isolation/replication ! Chaos Kong - enforcing region isolation/replication ! Security Monkey - watching for insecure configuration settings ! See over 50 NetflixOSS projects at netflix.github.com ! Get “Technical Indigestion” reading techblog.netflix.com Trust with Verification
  88. 88. Cloud Native Monitoring and Microservices
  89. 89. Cloud Native Microservices ! High rate of change Code pushes can cause floods of new instances and metrics Short baseline for alert threshold analysis – everything looks unusual ! Ephemeral Configurations Short lifetimes make it hard to aggregate historical views Hand tweaked monitoring tools take too much work to keep running ! Microservices with complex calling patterns End-to-end request flow measurements are very important Request flow visualizations get overwhelmed
  90. 90. Whoops! I didn’t mean that! Reverting…
 
 Not cool if it takes 5 minutes to see it failed and 5 more to see a fix
 No-one notices if it only takes 5 seconds to detect and 5 to see a fix
  91. 91. NetflixOSS Hystrix/Turbine Circuit Breaker http://techblog.netflix.com/2012/12/hystrix-dashboard-and-turbine.html
  92. 92. NetflixOSS Hystrix/Turbine Circuit Breaker http://techblog.netflix.com/2012/12/hystrix-dashboard-and-turbine.html
  93. 93. Low Latency SaaS Based Monitors https://www.datadoghq.com/ http://www.instana.com/ www.bigpanda.io www.vividcortex.com signalfx.com wavefront.com sysdig.com
  94. 94. Metric to display latency needs to be less than human attention span (~10s)
  95. 95. Challenges for Microservice Platforms
  96. 96. Managing Scale
  97. 97. A Possible Hierarchy Continents Regions Zones Services Versions Containers Instances How Many? 3 to 5 2-4 per Continent 1-5 per Region 100’s per Zone Many per Service 1000’s per Version 10,000’s It’s much more challenging than just a large number of machines
  98. 98. Simulated Microservices Model and visualize microservices Simulate interesting architectures Generate large scale configurations Eventually stress test real tools See github.com/adrianco/spigo Simulate Protocol Interactions in Go Visualize with D3 ELB Load Balancer Zuul API Proxy Karyon Business Logic Staash Data Access Layer Priam Cassandra Datastore Three Availability Zones
  99. 99. Failures
  100. 100. ELB Load Balancer Zuul API Proxy Karyon Business Logic Staash Data Access Layer Priam Cassandra Datastore Simple NetflixOSS style microservices architecture on three AWS Availability Zones
  101. 101. ELB Load Balancer Zuul API Proxy Karyon Business Logic Staash Data Access Layer Priam Cassandra Datastore Simple NetflixOSS style microservices architecture on three AWS Availability Zones
  102. 102. ELB Load Balancer Zuul API Proxy Karyon Business Logic Staash Data Access Layer Priam Cassandra Datastore Simple NetflixOSS style microservices architecture on three AWS Availability Zones Zone partition/failure What should you do? What should monitors show?
  103. 103. ELB Load Balancer Zuul API Proxy Karyon Business Logic Staash Data Access Layer Priam Cassandra Datastore Simple NetflixOSS style microservices architecture on three AWS Availability Zones Zone partition/failure What should you do? What should monitors show? By design, everything works with 2 of 3 zones running. This is not an outage, inform but don’t touch anything! Halt deployments perhaps?
  104. 104. ELB Load Balancer Zuul API Proxy Karyon Business Logic Staash Data Access Layer Priam Cassandra Datastore Simple NetflixOSS style microservices architecture on three AWS Availability Zones Zone partition/failure What should you do? What should monitors show? By design, everything works with 2 of 3 zones running. This is not an outage, inform but don’t touch anything! Halt deployments perhaps? Challenge: understand and communicate common microservice failure patterns.
  105. 105. Flow
  106. 106. Some tools can show the request flow across a few services
  107. 107. Flow Trace Recording riak2 us-east-1 zoneC riak9 us-west-2 zoneA Put s896 Replicate riak3 us-east-1 zoneA riak8 us-west-2 zoneC riak4 us-east-1 zoneB riak10 us-west-2 zoneB us-east-1.zoneC.riak2 t98p895s896 Put us-east-1.zoneA.riak3 t98p896s908 Replicate us-east-1.zoneB.riak4 t98p896s909 Replicate us-west-2.zoneA.riak9 t98p896s910 Replicate us-west-2.zoneB.riak10 t98p910s912 Replicate us-west-2.zoneC.riak8 t98p910s913 Replicate staash us-east-1 zoneC s910 s908s913 s909s912
  108. 108. Open Zipkin A common format for trace annotations A Java tool for visualizing traces Standardization effort to fold in other formats Driven by Adrian Cole (currently at Pivotal) Extended to load Spigo generated trace files
  109. 109. Zipkin Trace for One Flow
  110. 110. Interesting architectures have a lot of microservices! Flow visualization is a big challenge. See http://www.slideshare.net/LappleApple/gilt-from-monolith-ruby-app-to-micro-service-scala-service-architecture
  111. 111. Riak IoT Architecture { "arch": "riak", "description":"Riak IoT ingestion example for the RICON 2015 presentation", "version": "arch-0.0", "victim": "", "services": [ { "name": "riakTS", "package": "riak", "count": 6, "regions": 1, "dependencies": ["riakTS", "eureka"]}, { "name": "ingester", "package": "staash", "count": 6, "regions": 1, "dependencies": ["riakTS"]}, { "name": "ingestMQ", "package": "karyon", "count": 3, "regions": 1, "dependencies": ["ingester"]}, { "name": "riakKV", "package": "riak", "count": 3, "regions": 1, "dependencies": ["riakKV"]}, { "name": "enricher", "package": "staash", "count": 6, "regions": 1, "dependencies": ["riakKV", "ingestMQ"]}, { "name": "enrichMQ", "package": "karyon", "count": 3, "regions": 1, "dependencies": ["enricher"]}, { "name": "analytics", "package": "karyon", "count": 6, "regions": 1, "dependencies": ["ingester"]}, { "name": "analytics-elb", "package": "elb", "count": 0, "regions": 1, "dependencies": ["analytics"]}, { "name": "analytics-api", "package": "denominator", "count": 0, "regions": 0, "dependencies": ["analytics-elb"]}, { "name": "normalization", "package": "karyon", "count": 6, "regions": 1, "dependencies": ["enrichMQ"]}, { "name": "iot-elb", "package": "elb", "count": 0, "regions": 1, "dependencies": ["normalization"]}, { "name": "iot-api", "package": "denominator", "count": 0, "regions": 0, "dependencies": ["iot-elb"]}, { "name": "stream", "package": "karyon", "count": 6, "regions": 1, "dependencies": ["ingestMQ"]}, { "name": "stream-elb", "package": "elb", "count": 0, "regions": 1, "dependencies": ["stream"]}, { "name": "stream-api", "package": "denominator", "count": 0, "regions": 0, "dependencies": ["stream-elb"]} ] } New tier name Tier package Region count: 1 Node count List of tier dependencies
  112. 112. Single Region Riak IoT
  113. 113. Single Region Riak IoT IoT Ingestion Endpoint Stream Endpoint Analytics Endpoint
  114. 114. Single Region Riak IoT IoT Ingestion Endpoint Stream Endpoint Analytics Endpoint Load Balancer Load Balancer Load Balancer
  115. 115. Single Region Riak IoT IoT Ingestion Endpoint Stream Endpoint Analytics Endpoint Load Balancer Normalization Services Load Balancer Load Balancer Stream Service Analytics Service
  116. 116. Single Region Riak IoT IoT Ingestion Endpoint Stream Endpoint Analytics Endpoint Load Balancer Normalization Services Enrich Message Queue Riak KV Enricher Services Load Balancer Load Balancer Stream Service Analytics Service
  117. 117. Single Region Riak IoT IoT Ingestion Endpoint Stream Endpoint Analytics Endpoint Load Balancer Normalization Services Enrich Message Queue Riak KV Enricher Services Ingest Message Queue Load Balancer Load Balancer Stream Service Analytics Service
  118. 118. Single Region Riak IoT IoT Ingestion Endpoint Stream Endpoint Analytics Endpoint Load Balancer Normalization Services Enrich Message Queue Riak KV Enricher Services Ingest Message Queue Load Balancer Load Balancer Stream Service Riak TS Analytics Service Ingester Service
  119. 119. Two Region Riak IoT IoT Ingestion Endpoint Stream Endpoint Analytics Endpoint East Region Ingestion West Region Ingestion Multi Region TS Analytics
  120. 120. What’s Next?
  121. 121. Trends to watch for 2016: Serverless Architectures - AWS Lambda Teraservices - using terabytes of memory
  122. 122. Teraservices
  123. 123. Terabyte Memory Directions Engulf dataset in memory for analytics Balanced config for memory intensive workloads Replace high end systems at commodity cost point Explore non-volatile memory implications
  124. 124. Terabyte Memory Options Now: Diablo DDR4 DIMM containing flash 64/128/256GB Migrates pages to/from companion DRAM DIMM Shipping now as volatile memory, future non-volatile Announced but not shipped for 2016 AWS X1 Instance Type - over 2TB RAM Easy availability should drive innovation
  125. 125. Diablo Memory1: Flash DIMM NO CHANGES to CPU or Server NO CHANGES to Operating System NO CHANGES to Applications ✓ UP TO 256GB DDR4 MEMORY PER MODULE ✓ UP TO 4TB MEMORY IN 2 SOCKET SYSTEM TM
  126. 126. Learn More…
  127. 127. Q&A Adrian Cockcroft @adrianco http://slideshare.com/adriancockcroft Technology Fellow - Battery Ventures See www.battery.com for a list of portfolio investments
  128. 128. Security Visit http://www.battery.com/our-companies/ for a full list of all portfolio companies in which all Battery Funds have invested. Palo Alto Networks Enterprise IT Operations & Management Big DataCompute Networking Storage

×