2. In the ideal world . . .
. . . we want to be here
cost
work
3. But in the “real” world . . .
. . . we usually find ourselves here
cost
work
4. Big “jumps” are possible in a relatively short timeframe!
requestspersecond
~ 2009 - 2012
joules
~ 2013 - ???
RPS/dollar: 4.1x
RPS/joule: 4.3x
RPS/rack: 10.4x
13. We end up with an ever increasing amount
of our cheap DRAM is used to hide the
terrible latency of our cheap storage.
14. This growing split between the bandwidth and latency of
our storage systems only becomes apparent at large scale.
15. CPU DRAM LAN Disk
Bandwidth 1.50 1.27 1.39 1.28
Latency 1.17 1.07 1.12 1.09
Annual Bandwidth and Latency Improvements (Patterson, 2004)
* Extracted from leading commodity components over the last 25 years and what is reported is the multiplicative performance increase per year.
➔ CPU fastest to change and DRAM is the slowest.
16. CPU DRAM LAN Disk
Bandwidth 1.50 1.27 1.39 1.28
Latency 1.17 1.07 1.12 1.09
Annual Bandwidth and Latency Improvements (Patterson, 2004)
* Extracted from leading commodity components over the last 25 years and what is reported is the multiplicative performance increase per year.
➔ CPU fastest to change and DRAM is the slowest.
➔ Latency is driven by physical limits whereas bandwidth can be
addressed through parallelism.
17. CPU DRAM LAN Disk
Bandwidth 1.50 1.27 1.39 1.28
Latency 1.17 1.07 1.12 1.09
Annual Bandwidth and Latency Improvements (Patterson, 2004)
* Extracted from leading commodity components over the last 25 years and what is reported is the multiplicative performance increase per year.
➔ CPU fastest to change and DRAM is the slowest.
➔ Latency is driven by physical limits whereas bandwidth can be
addressed through parallelism.
➔ Bountiful bandwidth with lagging latency!
18. CPU DRAM LAN Disk
Bandwidth 1.50 1.27 1.39 1.28
Capacity -- 1.52 -- 1.48
Annual Bandwidth and Capacity Improvements (Patterson, 2004)
* Extracted from leading commodity components over the last 25 years and what is reported is the multiplicative performance increase per year.
➔ Widening gap between bandwidth and capacity.
19. ➔ Widening gap between bandwidth and capacity.
➔ Time to read a complete disk with random IO is increasing 22x /
decade or 36% / year.
CPU DRAM LAN Disk
Bandwidth 1.50 1.27 1.39 1.28
Capacity -- 1.52 -- 1.48
Annual Bandwidth and Capacity Improvements (Patterson, 2004)
* Extracted from leading commodity components over the last 25 years and what is reported is the multiplicative performance increase per year.
20. ➔ Widening gap between bandwidth and capacity.
➔ Time to read a complete disk with random IO is increasing 22x /
decade or 36% / year.
➔ Now our applications cannot afford to have a cache miss!
CPU DRAM LAN Disk
Bandwidth 1.50 1.27 1.39 1.28
Capacity -- 1.52 -- 1.48
Annual Bandwidth and Capacity Improvements (Patterson, 2004)
* Extracted from leading commodity components over the last 25 years and what is reported is the multiplicative performance increase per year.
29. Avoid the problem entirely by using more servers with
cheaper, lower powered processors that more closely
match the capabilities of the memory subsystem.
30. ➔ Leverages the massive volume economics of the smart device (e.g., cell phones
and tablets) market.
31. ➔ Leverages the massive volume economics of the smart device (e.g., cell phones
and tablets) market.
➔ Most workloads are not pushing CPU limits but are IO (disk, network or
memory) bound so spending more on a faster CPU will not deliver results.
32. ➔ Leverages the massive volume economics of the smart device (e.g., cell phones
and tablets) market.
➔ Most workloads are not pushing CPU limits but are IO (disk, network or
memory) bound so spending more on a faster CPU will not deliver results.
➔ Price/performance in the device market is far better than current
generation server CPUs because there is far less competition in server
processors prices tend to be higher and price/performance relatively low.
33. ➔ Leverages the massive volume economics of the smart device (e.g., cell phones
and tablets) market.
➔ Most workloads are not pushing CPU limits but are IO (disk, network or
memory) bound so spending more on a faster CPU will not deliver results.
➔ Price/performance in the device market is far better than current
generation server CPUs because there is far less competition in server
processors prices tend to be higher and price/performance relatively low.
➔ Server CPU = ~$300 - ~$1000
34. ➔ Leverages the massive volume economics of the smart device (e.g., cell phones
and tablets) market.
➔ Most workloads are not pushing CPU limits but are IO (disk, network or
memory) bound so spending more on a faster CPU will not deliver results.
➔ Price/performance in the device market is far better than current
generation server CPUs because there is far less competition in server
processors prices tend to be higher and price/performance relatively low.
➔ Server CPU = ~$300 - ~$1000
➔ ARM CPU = ~$15 / Intel Atom S1200 = ~$65
35. ➔ Leverages the massive volume economics of the smart device (e.g., cell phones
and tablets) market.
➔ Most workloads are not pushing CPU limits but are IO (disk, network or
memory) bound so spending more on a faster CPU will not deliver results.
➔ Price/performance in the device market is far better than current
generation server CPUs because there is far less competition in server
processors prices tend to be higher and price/performance relatively low.
➔ Server CPU = ~$300 - ~$1000
➔ ARM CPU = ~$15 / Intel Atom S1200 = ~$65
➔ ~25% the processing rate @ ~10% the cost!
36. ➔ Leverages the massive volume economics of the smart device (e.g., cell phones
and tablets) market.
➔ Most workloads are not pushing CPU limits but are IO (disk, network or
memory) bound so spending more on a faster CPU will not deliver results.
➔ Price/performance in the device market is far better than current
generation server CPUs because there is far less competition in server
processors prices tend to be higher and price/performance relatively low.
➔ Server CPU = ~$300 - ~$1000
➔ ARM CPU = ~$15 / Intel Atom S1200 = ~$65
➔ ~25% the processing rate @ ~10% the cost!
➔ Volume of the device ecosystem fuels innovation so the performance gap
shrinks each generation!
37. ➔ These machines also help with one of the biggest and most certainly the
fastest growing cost of any data center -- power!
38. ➔ These machines also help with one of the biggest and most certainly the
fastest growing cost of any data center -- power!
➔ Your typical 8-core server uses ~200W idle and above 600W TDP (full tilt
boogie)!
39. ➔ These machines also help with one of the biggest and most certainly the
fastest growing cost of any data center -- power!
➔ Your typical 8-core server uses ~200W idle and above 600W TDP (full tilt
boogie)!
➔ Bringing 30A @ 208V to each rack that is a 6.2 kW rack (and I know of folks
provisioning 12 - 14 kW racks just to fill it up 50%!)
40. ➔ These machines also help with one of the biggest and most certainly the
fastest growing cost of any data center -- power!
➔ Your typical 8-core server uses ~200W idle and above 600W TDP (full tilt
boogie)!
➔ Bringing 30A @ 208V to each rack that is a 6.2 kW rack (and I know of folks
provisioning 12 - 14 kW racks just to fill it up 50%!)
➔ If you can save a lot on op-ex by spending a little more on cap-ex it’s a great
bargain! (ask your CFO!)
41. ➔ People costs dominate the enterprise player’s data centers but it is very easy
and cheap to not let them dominate your costs.
42. ➔ People costs dominate the enterprise player’s data centers but it is very easy
and cheap to not let them dominate your costs.
➔ The barrier to entry into automation tools (Puppet, Chef, etc) has never been
lower and their penetration into existing systems (networking devices, etc)
has never been higher.
43. Lesson #2
Understand that distributed systems are
fundamentally about dealing with
distance and having more than one thing.
44. Currently writing distributed applications is usually not
indistinguishable from writing non-distributed applications.
45. Despite the non-zero probability of failure within a
nearly every aspect of modern computers;
developers of non-distributed applications do not
routinely maintain a concept of failing hardware.
49. The difference between an entire data center and a single
computer should only be quantitative not qualitative.
50. Since software development is an entirely
quantitative pursuit we should be able to conceal the
entire complexity of the Internet within software.
51. A clear trajectory in the same direction …
➔ Erlang OTP (Ericsson) and GoCircuit (Tumblr).
52. A clear trajectory in the same direction …
➔ Erlang OTP (Ericsson) and GoCircuit (Tumblr).
➔ General-purpose distributed file systems (and protocols)
spanning multiple globally distributed data centers.
53. A clear trajectory in the same direction …
➔ Erlang OTP (Ericsson) and GoCircuit (Tumblr).
➔ General-purpose distributed file systems (and protocols)
spanning multiple globally distributed data centers.
➔ Datacenter-scale job schedulers also abound (Google’s
Borg/Omega, Apache Mesos, Airbnb’s Chronos, etc.)
54. A clear trajectory in the same direction …
➔ Erlang OTP (Ericsson) and GoCircuit (Tumblr).
➔ General-purpose distributed file systems (and protocols)
spanning multiple globally distributed data centers.
➔ Datacenter-scale job schedulers also abound (Google’s
Borg/Omega, Apache Mesos, Airbnb Chronos, etc.)
➔ nanomsg scalability protocols (M. Sustrik).
55. A clear trajectory in the same direction …
➔ Erlang OTP (Ericsson) and GoCircuit (Tumblr).
➔ General-purpose distributed file systems (and protocols)
spanning multiple globally distributed data centers.
➔ Datacenter-scale job schedulers also abound (Google’s
Borg/Omega, Mesos, Airbnb, etc.)
➔ nanomsg scalability protocols (M. Sustrik).
➔ Not only possible but the clear “silent” choice of the
majority!
56. So how to play “big” when you’re “small”?
➔ You need to understand your technical substrate both
broadly and deeply so you know where to focus all your
resources most effectively.
57. So how to play “big” when you’re “small”?
➔ You need to understand your technical substrate both
broadly and deeply so you know where to focus all your
resources most effectively.
➔ That understanding will allow to you operate at
economies of scale that free up your most important
resource -- people.
58. So how to play “big” when you’re “small”?
➔ You need to understand your technical substrate both
broadly and deeply so you know where to focus all your
resources most effectively.
➔ That understanding will allow to you operate at
economies of scale that free up your most important
resource -- people.
➔ But remember the focus of our resources is not
necessarily where your resources should be focused nor is
anyone elses.
59. So how to play “big” when you’re “small”?
➔ Look for areas where a qualitative difference could easily
become merely a quantitative difference.
60. So how to play “big” when you’re “small”?
➔ Look for areas where a qualitative difference could easily
become merely a quantitative difference.
➔ Quantitative problems are easy to solve through
technology, however, qualitative problems are very
intractable through technology alone.
