You mention your background working on the Google File System, and Cohesity says its Data Platform uses a Google-like, web-scale architecture. Can you elaborate on how working on the Google File System has informed your ventures since then?
As I graduated with my Ph.D [in computer science from Rice University] I worked in a scale-out company called Zambeel in the early 2000s, and the architects had put in assumptions that if something failed then that something would probably come back up in a few minutes. When I worked at Google I saw a different view of the world. I saw a world where the smallest systems comprised 5,000 to 10,000 server nodes back when Google had millions rather than gazillions like now. When you're talking about that scale you cannot babysit these systems. When something goes down it will probably stay down for an extended period of time and there is no hope that an admin will come along and have time to fix it. One of the ways in which the Google File System was different in terms of interruptions is that it said hey, if any component fails and stays down for an extended period of time, you can design around that so that the system can heal, almost like if an organ of the body is going to die and you work around it, not waiting for the doctor to come and implant a second organ. That is one philosophy on which the Google File System works and has carried over to the systems I've worked on henceforth.
Another thing is a lot of systems, going back to the first company I joined, they used to have a database sitting on the side that all the transactions went through and the company used to claim scalability. But the reality was that this database was a bottleneck. So it became an exercise in making it work on the most powerful piece of hardware that we could, but eventually the scalability is limited by that. The philosophy behind the Google File System is that there's no single bottleneck [early versions did have a unique master but later versions eliminated that].
This stuff is not taught in textbooks. So unfortunately, people who come out of Stanford or [UC] Berkeley and feel they can build a cheaper system, they're in for a
surprise, and end up building something like my team did at my first company. Building a better system is an art that's only learned by doing it at a company like Google and that's what my team has and that's what we're building.
How can you claim your product is infinitely scalable? That's seems like an outrageous claim.
Sign up for CIO Asia eNewsletters.