COMPUTING OVER TIME
When we think about advances in computing power, most people think of Moore’s Law, Kryder’s Law, or Nielsen’s law, which are about the pace of technical development. Moore’s law is the most well known, and talks about the pace of computational intensity doubling every 18-24 months. Kryder’s law is about storage, and doesn’t have a speed attached, but notes that storage capacity increases at a much faster pace than Moore’s law. Finally, we have Nielsen’s law, which is about Network throughput. Essentially, Nielsen theorized that since Network performance was increasing slower than computational intensity, we would always be network-bound (ergo the network would always be the limitation) and for all intents and purposes this has proved to be pretty much true.
So we have the three immortal axioms of computing: processors double all the time, storage moves faster and networks move slower. That’s all well and good except for one thing…
MOORE’S LAW IS BROKEN
In case you didn’t get the memo, Intel hit the power wall in 2005. Basically, up until about 2005, Intel was just making one chip as fast as possible. Damn the torpedoes, Intel was going to make the biggest and baddest chips on the planet. One day they woke up and companies like Facebook were buying AMD processors because the performance to power ratio was so much better. In fact, the cost of operating Intel’s Beefy Single-Core chips was such that many companies were evaluating other computing platforms.
How were these companies beating Intel, the juggernaut of CPU systems? More cores. So in 2005, Moore’s law was really fractured, at least from the users perspective. Why? Computer programs were almost universally written for one core because Parallel computing is hard. It’s getting easier, but it’s still hard.
The companies that will dominate in the future are those that can consume many cores simultaneously for processing, versus the companies who dominated in the past simply by throwing more processors at the problem. You can still throw money at the problem, but your code has to change or you’ll suffer diminishing returns on your investment. That’s why Moore’s law ostensibly broke in 2005, because code doesn’t automatically scale with hardware anymore.
Yes, Moore’s law still holds true doubling speed every 18-24 months, but now you do so by adding ever-more cores. Right now, the programming languages many people use are not built to take up ever-more cores, or do so but with a lot of expensive overhead to make this transparent to the programmer and the user. So the limitation now is less infrastructure and more creativity (programs written for multi-core environments will now run exponentially faster than clumsily written ones).
AMAZON WEB SERVICES AND COMPUTING OVER TIME
AWS, coincidentally, was founded in 2006, launched by Jeff Bezos as an experiment in aggregated computing. The thesis was this: sell computing like a utility. Jeff and company benefited from a lot of trends, but none was more important than the shift in importance of power to performance ratios. Amazon wanted cheap chips that didn’t use a lot of power, and they wanted a lot of them. What many of us don’t realize is what a large component of the overall computing ecosystem electricity becomes at scale. Power, is everything.
AWS, like most Amazon services, is playing the long game. Jeff’s plan is pretty simple: If Amazon operates at 0 margin for a long enough time, no one will be able to compete. It’s an interesting idea, but one that can really only be proven over time. Which brings me to my idea of a new Law: Bezos’ Law.
The Cost of Cloud Computing will be cut in half every 18 months - Bezos’ Law
Like Moore’s law, Bezos’ Law is about exponential improvement over time. If you look at AWS history, they drop prices constantly. In 2013 alone they’ve already had 9 price drops. The difference; however, between Bezos’ and Moore’s law is this: Bezos’ law is the first law that isn’t anchored in technical innovation. Rather, Bezos’ law is anchored in confidence and market dynamics, and will only hold true so long as Amazon is not the aggregate dominant force in Cloud Computing (50%+ market share). Monopolies don’t cut prices.
So where does that leave us? I suppose that depends on how much you love infrastructure. If you love it, this is probably irrelevant to you, but if you don’t this means that the cost of your application will be cut in half every year and a half. That’s a big deal.
CONCLUSIONS AND/OR CONSIDERATIONS
If you’re a programmer, and if you believe in these predictions and the approaches people are taking to improved capacity and performance, your programming style may need to evolve with these changes, too. In short, write Parallel code because it’s better, and realize that the world is migrating towards more cores as quickly as they can because of power consumption patterns and operational considerations.
A QUICK NOTE
At 2600Hz, we think a guy named Joe Armstrong nailed it when he wrote the language Erlang. There’s a lot to love, but some of the key highlights for us are trivial parallelization, actor-model with per-actor garbage collection, and massive serialization. We use Erlang as the core of our stack, binding together our Border Controller, Media Servers, Databases, and Applications. It’s not always about the language you use but in our use case, we’ve found Erlang to be scalable, modular, and ultimately fit to the task of managing Global Communications Infrastructures. We feel that this tech, along with the engineers implementing it, give us a significant edge in getting to market and staying online. In addition, it’s a rough world out there and in short order companies that can’t parallelize will be left with massive legacy cost structures.
In a nutshell, Parallel code is where it’s at and at 2600Hz we leverage Erlang to help get us to many cores. We’re well on the way and we think this is the direction computing is heading. Parallel Computing ensures Moore’s Laws longevity.
Do you think parallel code is the right answer? Are you worried about your legacy communications system not scaling? Talk to us, we can help. Ring us at firstname.lastname@example.org to chat today!