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.

1. Innovation and Architecture
Adrian Cockcroft @adrianco
Technology Fellow - Battery Ventures
January 2016

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. Why am I here?
%*&!”
By Simon Wardley http://enterpriseitadoption.com/

4. Why am I here?
%*&!”
By Simon Wardley http://enterpriseitadoption.com/
2009

5. Why am I here?
%*&!”
By Simon Wardley http://enterpriseitadoption.com/
2009

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. What I learned from my time at Netflix

8. What I learned from my time at Netflix
•Speed wins in the marketplace

9. What I learned from my time at Netflix
•Speed wins in the marketplace
•Remove friction from product development

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. 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. 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. 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. 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. “You build it, you run it.”
Werner Vogels 2006

16. In 2014 Enterprises finally embraced
public cloud and in 2015 began
replacing entire datacenters.

17. In 2014 Enterprises finally embraced
public cloud and in 2015 began
replacing entire datacenters.
Oct 2014

18. In 2014 Enterprises finally embraced
public cloud and in 2015 began
replacing entire datacenters.
Oct 2014 Oct 2015

19. In 2014 Enterprises finally embraced
public cloud and in 2015 began
replacing entire datacenters.
Oct 2014 Oct 2015

20. Key Goals of the CIO?
Align IT with the business
Develop products faster
Try not to get breached

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. What needs to
change?

23. Developer responsibilities:
Faster, cheaper, safer

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. Assumptions

26. Optimizations

27. Assumption:
Process prevents
problems

28. Organizations build up
slow complex “Scar
tissue” processes

29. Product
Development
Processes

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. 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. 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. 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. Observe
Orient
Decide
Act Continuous
Delivery

35. Observe
Orient
Decide
Act
Land grab
opportunity Competitive
Move
Customer Pain
Point
Measure
Customers
Continuous
Delivery

36. Observe
Orient
Decide
Act
Land grab
opportunity Competitive
Move
Customer Pain
Point
INNOVATION
Measure
Customers
Continuous
Delivery

37. Observe
Orient
Decide
Act
Land grab
opportunity Competitive
Move
Customer Pain
Point
Analysis
Model
Hypotheses
INNOVATION
Measure
Customers
Continuous
Delivery

38. Observe
Orient
Decide
Act
Land grab
opportunity Competitive
Move
Customer Pain
Point
Analysis
Model
Hypotheses
BIG DATA
INNOVATION
Measure
Customers
Continuous
Delivery

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. 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. 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. 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. 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. 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. Breaking Down the SILOs

46. Breaking Down the SILOs
QA DBA
Sys
Adm
Net
Adm
SAN
Adm
DevUX
Prod
Mgr

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. 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. 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. 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. 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. 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. 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. 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. Use monolithic apps for small teams,
simple systems and when you must,
to optimize for efficiency and latency

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. 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. 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. 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. 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. 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. Developer Developer
Run What You Wrote
Developer Developer

63. Developer Developer
Run What You Wrote
Micro
service
Micro
service
Micro
service
Micro
service
Micro
service
Micro
service
Micro
service
Developer Developer

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. 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. 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. 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. 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. Change One Thing
at a Time!

70. What Happened?
Rate of change
increased
Cost and size and
risk of change
reduced

71. Low Cost of Change Using Docker
Developers
• Compile/Build
• Seconds
Extend container
• Package dependencies
• Seconds
PaaS deploy Container
• Docker startup
• Seconds

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. Disruptor:
Continuous Delivery with
Containerized Microservices

74. Microservices

75. A Microservice Definition
Loosely coupled service oriented
architecture with bounded contexts

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. 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. Speeding Up The Platform
Datacenter Snowflakes
• Deploy in months
• Live for years

79. Speeding Up The Platform
Datacenter Snowflakes
• Deploy in months
• Live for years
Virtualized and Cloud
• Deploy in minutes
• Live for weeks

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. 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. 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. Inspiration

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. Microservice Concerns
ConfigurationTooling Discovery Routing Observability
Development: Languages and Container
Operational: Orchestration and Deployment Infrastructure
Datastores
Policy: Architectural and Security Compliance

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. ! 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. Cloud Native
Monitoring and
Microservices

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. 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. NetflixOSS Hystrix/Turbine Circuit Breaker
http://techblog.netflix.com/2012/12/hystrix-dashboard-and-turbine.html

92. NetflixOSS Hystrix/Turbine Circuit Breaker
http://techblog.netflix.com/2012/12/hystrix-dashboard-and-turbine.html

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. Metric to display latency needs to be
less than human attention span (~10s)

95. Challenges for
Microservice
Platforms

96. Managing Scale

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. 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. Failures

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. 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. 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. 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. 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. Flow

106. Some tools can show
the request flow
across a few services

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. 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. Zipkin Trace for One Flow

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. 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. Single Region Riak IoT

113. Single Region Riak IoT
IoT Ingestion Endpoint
Stream Endpoint
Analytics Endpoint

114. Single Region Riak IoT
IoT Ingestion Endpoint
Stream Endpoint
Analytics Endpoint
Load Balancer
Load Balancer
Load Balancer

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. 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. 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. 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. Two Region Riak IoT
IoT Ingestion Endpoint
Stream Endpoint
Analytics Endpoint
East Region Ingestion
West Region Ingestion
Multi Region TS Analytics

120. What’s Next?

121. Trends to watch for 2016:
Serverless Architectures - AWS Lambda
Teraservices - using terabytes of memory

122. Teraservices

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. 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. 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. Learn More…

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. 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