He was Inc. magazine’s 2009 Entrepreneur of the Year, and on CNBC’s list of the top 15 innovators of the decade. He’s been awarded 23 patents, and he was named a tech pioneer by the World Economic Forum in Davos. He’s a serial entrepreneur, with interests ranging from energy efficiency to mobile medical technology to soundproof drywall. Now, at the apex of his storied technology career, he’s devoting himself to … Web app performance testing?
I’m referring to Kevin Surace, whose latest venture is Appvance, a Web app performance testing company in San Jose where he serves as CEO. I spoke with Surace earlier this week, and I opened the conversation by noting I had a hunch that given his background, a technology concept would have to be pretty extraordinary to capture his interest to the extent Appvance’s work has. So I asked him what it is about Web app performance testing that enticed him and stirred his passion. My take away from his response is that it’s about as much of a sure thing as you’ll ever find emanating from Silicon Valley:
When you look at the Web and at Internet companies today, neither you nor I would have picked WhatsApp to be worth $19 billion. The reason is, at least out here [in Silicon Valley], at any one time there are thousands of startups, and maybe not a single one of those will ever make it big. It’s really hard to pick what’s really going to be big, because consumers are very fickle. If we could pick them, we all would have invested in WhatsApp, but we didn’t. The interesting thing is, when you step back from that and ask what kind of tools all these people are going to need, and, more importantly, what enterprises are going to need across the board in IT, to be able to push these apps out as fast as they want to, and change them as fast as they want to, and you look around at the toolsets, you find some holes. One of the holes is in automated testing around functional performance, stress, and load.
Surace went on to express the view that the reason why it’s one of the holes is because the granddaddy of this space—Mercury Interactive, which was acquired by Hewlett-Packard in 2006—is simply an old platform:
It’s not wrong, it’s not bad, they’re not bad people—it’s just old. And it’s not getting a lot of support from HP—you see a gaping hole, where the 10,000 customers they have are spending $1 billion a year on a 20-year-old toolset. So you think, if we were to re-architect this, and really do it for modern apps, and really do it in an agile fashion, it wouldn’t look anything like that toolset. It would look like a brand new platform—it would be quick, it would be easy to learn, you’d get much more data on where your bottlenecks are, because unlike 20 years ago, when a five-second response time was good, today, everything better be at 100 milliseconds—that’s what people shoot for. The bar is higher, so the tools have to be higher. My view is, you never go wrong being in the pick-and-shovel space.
Beyond all that, Surace said, the business model was very appealing:
Our customers—people like Pepsi and 7-Eleven and McKesson—these aren’t small companies. They’re big companies who in a prior life used those old toolsets and said, “It got me where I am, but I can’t go forward with it without risking my brand and my apps.” That’s what’s exciting about it—it’s a tractable play. I sell to the enterprise, they send me a check. I sell them something useful, it’s a lot better than what they were buying, it’s probably half the cost of what they were buying, and they send me a check. I know that business model. I’m not that young anymore—this is what I can understand.
Surace has said that he believes many prominent Web apps are “built on a house of cards.” I asked him if that was just PR hyperbole, or if he truly is convinced of that. He said he wasn’t convinced before coming to run Appvance, but he is now:
I’ve seen some of the largest companies in the world license a platform and test their best app, and they say, “We’re going to launch this in three weeks, and it’s going to have a hundred thousand or a million users on it, and we’ve hired the best team doing the QA, and we’re ready to go,” and they test it and it falls apart with 58 users. I’m not exaggerating—it’s really bad. So what I realized is, as companies brought on more coders from around the world, many of them with just a two-year certificate, they’ve gotten people who have zero skills in scalability—nobody trained them in it, they’ve never done it, they don’t know how it works. So there’s no training in scalability—they write it, it works for them, they get a couple of their buddies on it and it seems to work, and they go, “OK, I guess we’re set.” And the answer is, you’re not. It’s not that they’re going to crash servers—they just get slow. You wait a few seconds and you leave, or you keep clicking “refresh,” which makes it worse. People need to get to [a response time of] 100 milliseconds, and they’re not going to get it without simulating loads that start to push that to the limit, and find out where the bottlenecks are, and rewrite those bottleneck areas.
Surace also shared his insights on the four key reasons why companies typically fail in app performance testing. I’ll cover that topic in a forthcoming post.