No Better Time by Molly Knight Raskin

No Better Time is the story of Akamai’s founder, Danny Lewin. It is at once fascinating and ultimately heartbreaking.

Akamai is a company that set out to solve the problem of World Wide Wait. Molly Knight Raskin’s book is the story of the man behind the algorithms that helped transform the internet … and the story of the startup called Akamai.

Akamai provides caching and route optimization to ensure fault tolerance and speed across the internet. In this reviewer’s day job, his company is an Akamai customer. The technology works exceedingly well.

The Internet in it’s early days, experienced explosive growth and wasn’t scaling well. Her elegant explanation is worth quoting here at length.

The root of the problem lay in the Internet’s architecture, originally designed like highways connected by various tunnels, or a “network of networks.” The inner workings of this architecture are highly technical and complex, but a basic understanding of how the web works is surprisingly easy using a familiar analogy: the Pony Express.

When you click on a web link, think of it as the act of dispatching a rider from your browser to a storage facility known as a Web server. The first thing the rider has to figure out where the storage facility is. To get the address, the rider consults the Internet address book, also known as the Domain Name System (DNS). just as your address book can tell you that your friend Joe Smith lives at 10 High St., Cambridge, DNS can tell the rider that www.fool.com “lives” at IP address 198.83.60.1. With the address, the rider is off to that destination.

As with the Pony Express, the trip to the storage location and back is not direct. The rider has to stop at several locations (known as routers or “hops”) between the starting point (your browser) and final destination (the Web server) to ask for directions. There can be 20 or more stops for each trip. At each stop, the rider has to ask for directions to the final address. Unfortunately, the staff at the stop does not actually know how to get to the final destination. Rather, they use a tool called the Border Gateway Protocol begin (BGB), which tells them only the next stop on the journey. Eventually, the rider makes it to the storage facility, asks for the Web file, retrieves it, then heads back to your browser using the same method used to get there – traversing the various “hops” and routes along the way. The rider may stop at the same locations on the return trip or take a completely different route.

Once the rider returns, your browser opens the file and notices there are a bunch of related objects needed to view the complete webpage – pictures, videos, ads, etc. In this case, the rider must be dispatched again to the same storage facility, this time to retrieve all the component parts. Each page can have 20 to 30 related objects – only one of which the rider can collect at a time – and the storage facility can be thousands of miles a way. All of this makes the process of getting a complete webpage time-consuming and cumbersome. It’s worth noting that, while the initial webpage file is usually pretty small, the related objects can be really big and unwieldy (videos, for example), making them difficult to transport.

While much of the traffic on the internet travels at the speed of light, through fiber-optic cables. There are significant problems to overcome:

The potential problems with this system include the following:

1. Lots of riders may be asking the VNS server for addresses, leading to delays.
2. The stops might be closed, forcing the rider to backtrack and find an alternate route.
3. There might be a lot of riders on the roads between the stops, leading to congestion and delays.
4. There might be a lot of riders at the stops asking for directions leading to further delays.
5. The storage facility itself might be closed.
6. There might be lots of riders at the storage facility asking for files, leading to more delays.

Raskin doesn’t overwhelm the reader with technical details, but does a good job of explaining the scope and complexity of the problem that Lewin set out to solve while pursuing his PHd at MIT. She provides a very clear high level explanation of consistent hashing, the algorithm behind the magic Lewin developed to solve these problems.

A useful, non-mathematical metaphor for understanding consistent hashing is the storage of files. Say you are given a task which, at the outset, appears easy: to store a large stack of files in several cabinets in some particular order, a system you can remember later when you want to retrieve a particular file. Obviously, there are several ways the files can be organized. One of the most straightforward is by alphabet – the A’s on one shelf, the B’s on the next, and so on. This strategy functions well until there is a surplus of a files. Suddenly that cabinet is full, and you’re left with no logical place to store them. If they go into the cabinet for the B files, the B’s might get squeezed out, meaning some of these would have to be shifted to the C cabinet, some C’s would move to the D cabinet, and so on. To make matter worse, what if two of the filing cabinets break, forcing you to remove all of the files they contain and stuff them into cabinets with extra room? There would no longer be a clear destination for any one file. The system, was working smoothly, now becomes messy. Using algorithms, consistent hashing offered a way of organizing files – or any kind of data – optimally. Consistent hashing meant that when a new “cabinet” was added or a new set of files was introduced, they would be spread evenly and consistently across said “cabinets.”

Setting the stage with this explanation of Lewin’s work gives the reader sufficient background to appreciate the significance of her subject’s work.

Lewin was born in Colorado but uprooted in his teens to move to Israel with his family. His father decided to move the family there for religious and philosophical reasons. The move was not an easy one for a teenager used to life in the U.S. Nevertheless, Lewin excelled in school, and even did a stint in the Israeli military, making it into the elite special forces, the Israeli equivalent to the American Seals.

Following this, he applied to and was accepted into a prestigious program at MIT, where he met his mentor, future friend and business partner, Professor Tom Leighton (a fascinating character, in his own right.)

While at MIT Lewin came up with the idea of consistent hashing, and parlayed it into one of the most successful dot com boom start-ups ever.

By the end of the book, the reader has good understanding of what an unusual and driven individual Danny Lewin was. While Raskin’s admiration for her subject is undeniable, she has good reason to be enamored with Lewin.

Lewin was charismatic, energetic and brilliant. The success of Akamai is stunning, but it wasn’t easy. Lewin didn’t live to see the magnitude of his accomplishment. In fact, at the end of his life, things at Akamai were almost at their lowest point. The dot com bubble had burst, and Akamai got lumped in with the rest of the technology sector. It lost a big chunk of its customer base, market confidence, and was in the process of restructuring and laying off a third of its work force.

Nevertheless, Lewin was moving forward. He had a new product called EdgeSuite, which would prove so successful that it would eventually save the company.

According to inadvertently released documents about the flight that Lewin was on, he was apparently one of the first to die at the hands of the terrorists. One of the flight attendants on the plane told flight control that the passenger in 9B, the seat assigned to Lewin, had his throat slashed by one of the terrorists.

…. the 9/11 Commission concluded that, in those first 20 minutes of the flight, Mohammed Atta – the only terrorist on board trained to fly a jet – probably moved to the cockpit from his business class seat (located within arms reach of Lewin’s seat) possibly accompanied by Abdulaziz Al Omari. As this was happening, according to the report, passenger Daniel Lewin, who was seated in the row just behind Atta and al-Omari, was stabbed by one of the hijackers – probably Satam al Suqami, who was seated directly behind Lewin. Lewin served four years as an officer in the Israeli military. He may have made an attempt to stop the hijackers in front of him.

Those who knew Lewin are convinced of this.

Ironically, the value of Akamai was proven on that fateful day in September when Lewin and 3,000 other Americans lost their lives. Internet traffic exploded as people frantically sought news on line. Akamai customers like CNN used its technology to keep the information flowing.

Lewin’s legacy lives on:

At the time of this book’s publication, Akamai has offices around the world, more than 3,500 employees, and a market capitalization of $6.9 billion. In 2012, the company opened its first office in Israel outside Tel Aviv. Akamai is by no means a household name, but most who people regularly make use of the Internet actually visit one of Akamai servers on a regular basis. Akamai’s customers include tech giants Facebook and Microsoft, and on a good day, it shoulders the weight of 30% of the world’s web traffic. Akamai’s core technology still relies on Lewin and Leighton’s early algorithms.

Raskin has written a great book about a great man.