AWS re:Invent 2016: New Products and Punchlines

This year I attended AWS re:Invent in Vegas again. Before getting to the main topic, let me poke some fun at programmers.

Las Vegas is a place where adult hormones are let loose. There are all kinds of gambling games, countless seductive slot machines, beautiful women, hunky men, shows ranging from family-friendly to R-rated, even private shows—there is something for everyone. And yet this is how programmers do Vegas:

• At 8 p.m., after dinner, I specifically took an Uber back to the venue for the keynote… The Uber driver looked at me as if I had lost my mind: ‘Buddy, are you running a fever?’
• After the keynote, everyone headed back to their hotels. Along the way, the programmers entertained themselves like this: two guys who looked like troublemakers collected call-girl cards along the road, then secretly stuffed them into the backpack of another naive buddy—the kind who blushes at a glance at such a card as if he had just lost his virtue—and found this hilarious.
• At 9:30 I got back to the hotel, couldn’t connect to WiFi, couldn’t check email or fix bugs, and called the front desk with a bitter heart to ask for a room change. The front-desk girl probably dropped her jaw: ‘Is this seriously how programmers do Vegas?’
• At 6 a.m. I got up and did a 5K run into the morning sun. Thanks to the organizers for their thoughtful effort to make everyone contemplate a philosophical question: Have you ever seen the Las Vegas sun at 6 a.m.?
• The keynote starts at 8 a.m., so most programmers—even those unwilling to run—get up at 7 to queue after breakfast. The restaurant server simply could not understand why these bald and almost-bald men were more excited about another bald man’s talk than about seeing Crazy Horse.

…

Okay, none of this is made up. It is real.

Last year’s re:Invent, as I recall, had over 10,000 people, beating the 2014 record; this year was even more hardcore—last night’s keynote said 32,000. Last year the Venetian alone could hold all the young bucks; this year it couldn’t, so they added the Mirage and the Encore just to manage. Serving a passable lunch to that many people (from salad to assorted dishes to mains and desserts, not one sandwich or hot dog per person) is a systems engineering problem, as you can see:

I posted this photo on WeChat Moments, and a friend’s wife felt relieved: it was wall-to-wall men. True—the women here are even more one-in-a-hundred than the women at ChinaJoy—oh no, one-in-ten-thousand. The gender imbalance is rivaled only by the Chinese army.

This morning’s keynote had basically no bathroom-break moments; you can watch it on YouTube. I’ll talk about a few that stunned me.

F1 instance

I think this is an epoch-making product that will make FPGA engineers weep. The internet era has lifted excellent software engineers to the heavens: they either draw huge salaries and wear proper imperial rank and peacock feathers while living the easy life at big companies, or they found their own products and become local warlords. Hardware engineers have it rough. FPGA is something only big companies—or at least those with large funding—can afford to play with; the supporting equipment is too expensive for individuals. If you want to tinker with something yourself, good luck—unlike software engineers, who can spend a few dozen dollars and soar freely through the sea of clouds. Now the F1 instance gives hardware engineers a path like the one software engineers have: you only need skills, an idea, and a little money to build your own product—and even sell your finished FPGA designs on a marketplace. Perhaps in the not-too-distant future, all kinds of high-performance hardware HTTP-layer load balancers, even web servers, will be born.

AI as a service

When TensorFlow came out last year, many friends around me were loudly talking about starting deep learning / AI startups. My view at the time was: unless the team has a badass PhD in this field, it’s better not to touch it. Now I don’t know how many startups Amazon has slapped in the face. Mr. Xiong of China Growth Capital said on WeChat Moments with lingering fear: ‘This is why we say startups must find industry applications.’ Let the pictures speak: Amazon launched three major services—image recognition (Rekognition), text-to-speech (Polly), and speech-to-text (Lex).

Rekognition

This thing uses deep learning to tag images appropriately. For example, the image of a beautiful car and a beautiful woman above was tagged along two dimensions: Object & scene (car, outdoors, daytime, driving), Faces (female, smiling, sunglasses). The use cases are enormous. A travel site, for instance, could call the API to tag every user-uploaded image and store the tags in an RDBMS; later it could run thrillingly rich queries—for example: ‘National Day is so boring; I want a place with mountains, water, and lush bamboo groves.’ Biang—matching photos are recommended right before your eyes.

Polly

Polly looks like text-to-speech technology from ten or twenty years ago, but it isn’t. Text-to-speech is a lifeless mechanical voice; according to Amazon, Polly is lifelike. To be lifelike, it not only has to segment words accurately and understand semantics, but also restore the sentimental (the original puns this as ‘three steamers of buns’) quality in the text. The live demo seemed very good, but I haven’t seen the actual service yet, so I won’t presume to judge.

Lex

Lex is the reverse engineering of Polly: speech to text. This is likewise a problem Microsoft and IBM ‘solved’ back in the 1990s—raise your hand if you used ViaVoice! I remember that after sufficient system training it could reach 96% recognition accuracy. I used it to digitize many of my childhood diaries. And yet—nothing. With speech recognition, if the accuracy cannot get infinitely close to 100%, the use cases are severely limited; at best it becomes simple voice control or an aid for text input. Likewise, I haven’t tried Lex myself, and Amazon didn’t give a recognition rate—but more than twenty years have passed; if they are still citing 96%, that definitely won’t fly.

Amazon engineers built a demo using Polly + Lex. Roughly: an engineer wants to book a flight to London. The voice assistant recognizes it, holds a conversation that basically passes the Turing test, and then books the engineer a 5 p.m. flight for $500.

If Polly + Lex can really support the above use cases, then I have to say:

Amazon is starting to cut off the livelihood of startups like Magic.

The service industry, especially call centers, now has endless room for imagination. Perhaps after autonomous vehicles reshape transportation (with countless transport workers sacrificed), call centers will be reshaped too.

Snowball

Last year at re:Invent, Snowball left a huge impression on me: data transfer by legs was actually faster than by fiber optics! Recently, our TubiTV had hundreds of TB of data and enjoyed Snowball’s first-class service. A quick primer: Snowball is a data upload service where Amazon gives you a device, you copy large volumes of data into it, then ship it to Amazon via FedEx and other couriers, where it is uploaded to S3. Not by network—by legs! It solves the problem of large data uploads being too slow (at current internet speeds, even with a 10 Gbps dedicated line, how long would it take to copy 100TB? About 100,000 seconds—23 days!) while ensuring data is neither leaked nor lost in transit.

Andy, an AWS VP, said proudly that as soon as this service launched, Amazon had to increase its hardware orders tenfold to resolve the contradiction between the people’s ever-growing material and cultural needs and backward productive forces. This year Snowball was upgraded: not only did capacity double, but it also came with compute. At first I wondered why a storage tool needed compute, and then Andy slapped my face with an example of ocean biological monitoring. In such scenarios, data is stored on Snowball while some real-time, shallow analysis is performed; when the ship docks, the Snowball is handed to FedEx, uploaded to AWS, and deep processing follows.

Hmm, very reasonable. But what if the data going to the cloud, or coming down from it, is simply too large? For a small company like ours with PB-scale data, dozens or a hundred Snowballs can handle it—but what about bigger companies? All the data is on Amazon; someday we want to build our own data center—how do we get the data back?

Andy waved his hand, and a truck slowly drove into the venue to strange music.

At first we chuckled, thinking it was a joke. Then Andy said, this is our solution: one truck holds 100 PB of data. In other words, 1 EB (exabyte) of data—ten trucks and you’re done! With Snowballs, 1 EB takes six months; over a 10 Gbps network, 26 years. Pinterest and Netflix no longer need to worry that their data on Amazon is too large to get back, leaving them vendor-locked. Meanwhile, when traditional Fortune 500 and Global 2000 companies with massive data migrate to the cloud, CIOs no longer have the excuse that ‘the data is too big to migrate’ [facepalm].

I am woefully ignorant and had no sense of how big an EB is. I checked Wikipedia and learned that the entire internet in 2011 held 525 EB. In other words, 5,000 trucks could carry off all of humanity’s wisdom from 2011… What a beautiful image.

That’s enough for now—tips welcome.