You aren't the first company to try grid computing on personal computers, so once people stop talking about how cool the idea of grid computing is or how to protect the web surfers rights, they'll start asking the hard questions. Like, how you're going to make money.
How do your paying customers feel about their data being strewn about the Internet? How does your processing interfere with the game that the user is playing? What kind of problems have you earmarked as being particularly parallelizable like this (ie what is your marketing plan?), and how usable is your API?
At the end of the day, is going through the effort to rewrite a program to work on distributed Java applets going to produce substantially more processing for the customer dollar than a $150 headless dual-core 1gz board with a gig of RAM running C++? You say that you can provide a $1500/yr savings over EC2, but this is only for applications that are "embarrassingly parallel", and will certainly require hiring a programmer to write code to run in tiny chunks on lots of clients. Will this cost less than $1,500? Worse, it will be money up front instead of spread out over a year.
You could say that the system is best leveraged by clients looking for a lot of compute power on a budget, but those are the people most likely to build their own grid. When you can get linux running on a dual-core 2.0gz for $200 / node, spending that money every year on an untested platform that will require substantial development work and vendor tie in, your service is going to be a tough sell.
You will be the only people interested in writing code for this platform, so please repost when you know which algorithm you can run to gross $10 million a year.
These are all very good questions and we certainly know that we're not the first company to do grid computing on PCs. :)
First, $1500/node-year (or even $200/node-year) comes to a very substantial amount of money for our target customers. These customers use 10000s of nodes and buy high-end computers and pay a ton for network, power, cooling, and support personnel.
My background is in HPC and I've faced and solved these issues many times. We have a multi-pronged approach to using the compute power:
1) We are definitely writing our own apps on top of Plura. It's a great source of compute power and we have lots of ways we want to use it ourselves.
2) We have a short list of very high impact embarrassingly parallel customers that are evaluating Plura. We intend to help our customers absorb the porting cost associated with Plura.
3) We are open to letting students and universities use Plura's excess capacity for free. We've had several nibbles at this already.
That being said, we realize Plura is not for everyone. It is for a subset of the class of embarrassingly parallel applications out there.
PC-based grid computing has already been made profitable. The trick is to make it both profitable and legal. Perhaps some variant on fast-flux name resolution could help with a particular subset of content delivery. Perhaps some other legal-but-Russian Business Network-inspired maneuver. Botnets are naturally limited because they're stamped out with extra vigor when they get big and famous; this could have staying power to leverage for tasks even Storm would've find impractical.
How do your paying customers feel about their data being strewn about the Internet? How does your processing interfere with the game that the user is playing? What kind of problems have you earmarked as being particularly parallelizable like this (ie what is your marketing plan?), and how usable is your API?
At the end of the day, is going through the effort to rewrite a program to work on distributed Java applets going to produce substantially more processing for the customer dollar than a $150 headless dual-core 1gz board with a gig of RAM running C++? You say that you can provide a $1500/yr savings over EC2, but this is only for applications that are "embarrassingly parallel", and will certainly require hiring a programmer to write code to run in tiny chunks on lots of clients. Will this cost less than $1,500? Worse, it will be money up front instead of spread out over a year.
You could say that the system is best leveraged by clients looking for a lot of compute power on a budget, but those are the people most likely to build their own grid. When you can get linux running on a dual-core 2.0gz for $200 / node, spending that money every year on an untested platform that will require substantial development work and vendor tie in, your service is going to be a tough sell.
You will be the only people interested in writing code for this platform, so please repost when you know which algorithm you can run to gross $10 million a year.