Show HN: Gridspot, 10x cheaper cloud compute using distributed computing
gridspot.com
gridspot.com
https://gridspot.com/gridspot_safe
Doesn't work in the USA. Natural gas heating in the US averages $10.80/thousand cubic feet ~= $10/gigajoule [1]. Electricity averages $0.1179/kWh ~= $33/gigajoule [1] -- more than three as expensive for raw heat. Natural gas heating is twice as common in US homes, with about 55.6 million vs. 28.4 million using electric resistance heating [2] -- not including 9.8 million electric heat pumps.
In the common case, you're displacing cheap gas heating with expensive electric resistance heating; the cost "savings" on heating is small. At 100W power consumption, you're spending 1.2 cents/hour on electricity, saving 0.4 cents/hour on gas, for a net loss of 0.8 cents/hour. Meanwhile your CPU is being sold for 0.1 - 0.3 cents/hour [3] -- far less than the electricity needed to run it, apparently (?).
[1] http://www.eia.gov/forecasts/steo/report/prices.cfm (residential retail prices, 2011)
[2] (.xls) http://www.eia.gov/consumption/residential/data/2009/xls/HC6...
[3] https://gridspot.com/compute/
European costs for comparison:
[1] http://hothardware.com/Reviews/Intel-Core-i73770K-Ivy-Bridge...
Yeah, I don't think that is going to work, especially because you are for-profit organization not SETI
And empirically, it seems to be working. The number of contributing machines is currently in the six figures. The main risk right now is on the demand side, i.e. whether or not people want this type of compute.
http://answers.yahoo.com/question/index?qid=20120329124823AA...
It does in bring into question whether or not gridspot.exe was installed nefariously.
With enough people involved, the compute version of this could be self-sustaining, and the infrastructure guys just take a wee percentage. They are unlikely to be replaced by purely free infrastructure, because money is involved (even if in the form of credits). If there was a shortage at particular time, some people might supply that themselves, for extra cash. Distributed compute supply = local compute supply, with latency advantages.
People install their program, contribute the power of their computers for free and Gridspot takes money.
Why would anyone do this? Why would anyone contribute their computer resource for other people to make money from that? I would rather, I don't know, mine bitcoins or set up a Tor proxy.
With no credit card, I got an instance with 3 GB RAM running in less than 60 seconds. It costs $0.002 per hour.
One glitch: Both the UI and the API say there are 2 instances running, but they both have the same IP address and port. If there really are 2 instances, how do I ssh to the second one?
The 1.56 core-hours is mostly from inst_KGN6tZdFgoeL2C9KPKBsNA which has four physical cpus and has been running for almost an hour at this point.
Thanks so much for trying this out!!!
If `cat /proc/cpuinfo` or `top` only shows one CPU, I wouldn't expect to be charged for 4 of them.
(Note, the number of cpus might be higher than the number of physical cpus if the host cpu supports hyperthreading.)
The Add Credit Card link is pointing here:
The thing that excites me most about a distributed cloud is that it could turn the notion of elastic computing on its head. You can buy your peak compute requirement, and sell back the surplus. So you can get elastic computing not by re-engineering your own systems, but by selling excess capacity to those whose workloads are a good match.
Consumers don't care about $2/month but a business would care about getting paid $2/month thousands of times.
Edit: If a VM is too big to download all at once with a freeware product, you just install the seed software. Then, over the next few days, the seed software downloads the VM and slowly sets it up so there's no disruption to the customer's activity on the computer.
I would also suggest you reserve the space needed on the disk with an empty file, roughly the size of the VM file. This way it's clear just how much space this newly installed software is taking on the customer's computer.
This is all based on the idea that the customer agreed to this during the installation. To what extent "agreed" is left up to you to decide. I'd suggest a dedicated page during the installation with a prechecked box that explains what this is and what it's about to do.
Often, freeware software developers bundle toolbars and other spyware/crapware with their software to make money. My suggestion would be to allow them to include the VM with their software instead of spyware/crapware toolbars. These freeware authors would earn a commission for every VM install that makes money.
Freeware developers need to earn money but their main option is to bundle their code with crapware now. This would be a nice alternative to that awful option.
> We have designed the Gridspot Software...
Sorry if i missed but : Who are you ? Please put some information about "yourself" somewhere on your site. And if you can, please answer these questions on your page :
- What is your company name and legal type ?
- What is your location ?
- How can i contact to you ? No, support@gridspot.com doesn't count, put some landline numbers too.
- Who are your team members ?
And please don't use " Whois guard" ?
edit: Looks like, downvoting is easier than answering the questions. Seriously, can you explain to me : why do you trust some company which doesn't give any information about itself ?
[1]: Ars Technica seems to confirm: http://arstechnica.com/business/2012/05/skype-replaces-p2p-s...
However:
"All network traffic is proxied through a central data center we maintain."
If there are specific, legitimate uses for a large number of IPs, for example fighting DDOS, then that might be something we should build!
With this product you will have a very wide base of unicast addresses. Treat each node/address as disposable. Use fast failing health checks and an out of band control plane. As each node falls to attack remove it from your service discovery layer (DNS/http 302/etc). See "fast flux dns" for implementation ideas. The attacker will spend a disproportionate amount of resources (packets/s) attacking each of your disposable nodes. The majority of your "good" customers will continue to be served. In a traditional tiered architecture the L3->L7 routing layer (LB/Proxy) is very expensive to scale vertically. Your data store & compute end are clustered behind these choke points. Remove/minimize shared state and you can have independent units of compute. Remove those L3->L7 choke points and you can get a wider & flatter L1->L3 network fabric. Besides increased durability you get more aggregate bandwidth per $.
"SETI but paid" is a very tempting idea, but we could never get the back of the envelope math to work out to the point where we could pay the contributors anything compelling (e.g., enough to offset their power cost).
I guess you can get a few people to sign-up for fun, but we could never come up with a reason other than serendipity that would make people donate their CPU time for us to resell. I'll be interested to see how/if they respond to this challenge, or if there's something I'm not seeing that makes this point moot.
If the service was really successful you could be giving out n * $100k prizes every month. Just treat it like the (much cheaper) server hosting bill.
Please provide a standardish xen/kvm/vmware/vagrent client image. Being win32 exe only is probably costing you a lot of resource provides (like me). Clients running xen/kvm/vmware are also more likely to be providing higher value resources, like a colo'd host.
Move your API to a different (sub)domain ASAP. At some point you'll need to change your DNS architecture. Having your API tied to your zone apex is going to cause no end of grief. If it's in a (sub)domain you can easily delegate control to another authoritative name server. You might want to use a directional DNS product, CNAME to another resource, add another product api, add another API endpoint, etc.
Provide some sort of initialization hook. Every node I launch should be able to auto configure my stack without a "push" action, ssh or otherwise. I much prefer when each node can bootstrap and poll my instance/config management stack. For example EC2 provides this functionality through the UserData param of RunInstances.
"Sign in" doesn't have an option or link to "Sign up". From the docs I had to go back to the home page to find the sign up.
Support payment other than credit card. Paypal etc is nice in that I can create a balance without extending as much trust to an unknown party.
Don't get suckered in to providing 1:1 IPv4 with your proxy model. If the product's successful you'll quickly discover that even a /16 is expensive/unpossible. A 1:1 mapping with IPv6 is operationally plausible. As a bonus you'll get PR for a "shiny" feature.
Stay away domU egressing through the dom0 IPv4 for now. I guarantee you'll attract bad actors. A chinese gambling/porn site hosted on those domUs is going get DDOS'd all the little long day. If that takes out the dom0 internet connectivity you'll have a revenue generating customer who's upset.
Terminate long running domU instances. You can use this to shape customer expectations about the ephemeral nature of your product. Expose this to the instance owner the same way as a dom0 going offline. Try something like max(mean dom0 availability || 12 hours) + weighted random to get each domUs lifetime.
Provide a way to request & inspect network locality or latency. Three use case here I think. 1) Launch instances near $foo. Get decreased latency to a centralized endpoint, like a scheduler. 2) What is the location of $instance. I can determine the nearest S3 region for faster GET/PUTs. 3) Launch instances within $n ms of each other. If instances have shared state or messages during compute phase this can increase throughput
It’s not EC2 alternative, this is a different kind of service.
There's no requirement for the host to download the client image multiple times. I'd imagine you have something like ephemeral domu disk and use kmods to provide a control plane and network tunnel.
They should provide their image instead of the binary. Theirs, rather than their clients. Got you know!
But I don’t think their audience will have much use for it. Well it’s unlikely to be a priority, anyway.
> Don't get suckered in to providing 1:1 IPv4 with your proxy model.
BTW, he doesn’t. It’s all proxied through single IP on different ports. E.g. this is what I got:
ssh gridspot_user@69.4.239.76 -p 25502There are many applications for this - including fighting DDOS attacks. There are still huge technical challenges with that particular application, but as I understand it...the only way to fight a DDOS is to a) get bigger guns, or b) lie down and take your raping.
Having something like this, can (in theory) give you bigger guns.
Do you guys pay the people who have idle resources?
Or cheaply launching them. For a mere $100 you get 100,000 machines for an hour, that's more than enough to cause problems for a sad number of websites out there. Edit: Or not, given that all traffic goes through a centralized node.
That was another consideration that I looked at two years ago - which makes the model not as attractive. Although, I imagine that the holy grail is actually reaching a place where users are making money from their inet connection - I am sure that will drive adoption at an increasing rate.
Seems that that small set of computers and IP addresses could be used to do the ill deeds of a bad actor.
"Run anything"
"Get SSH root access to each Linux instance."
So exactly what is to prevent someone from spamming here and how would gridspot even know that was happening? To mention only one possibility.
If someone is doing something evil over e.g. HTTP, presumably GridSpot can also block that and/or ban them from the system.
If you're sending spam over e.g. Gmail via HTTPS, Gmail will shut you down.
The people running the nodes don't need to worry about e.g. someone downloading illegal content and getting them in trouble, because it is proxied through GridSpot.
I think it's a clever solution.
At $0.002 per hour I'm actually OK with zero security, but it will limit the types of jobs that I'll use Gridspot for.
> Gridspot is perfect for jobs that:
> • ...
> • Aren't privacy sensitive
It’s not exactly replacement for EC2, but there’s a lot of applications that would fit Gridspot just fine.
But I guess one has to be much more aware of all the security issues when writing for a platform like this. The Gridspot folks should perhaps consider creating solid list of best-practice guidelines.
Now can someone also create Gridspot for storage? :)
Some recent research [1] has shown that it's theoretically possible to delegate the ability to process your data, without giving away access to it. But from what I remember, in practice the computation becomes orders of magnitude slower than on the unencrypted counterpart.
The price will go As high it needs to, for suppliers to think it's worth while.
It would interesting to see what the resting price is. I.e what suppliers think is worth while. It will probably be at max slightly higher than amazon, because people will do arbitrage with amazon.
In the long run you would expect this would drive up the bidding for idle CPU time, meaning that having a couple of idle computers in your house would generate you a small amount of positive revenue, in much the same way that contributing electricity back to the grid using solar cells could. Of course, most people have no use for solar cells (which are expensive), whereas a lot of us have use for local CPU.
second to last word of the first section. Electricity.
At this point I'm somewhat unsure of their actual business model. Are they reselling VPS instances from real providers or are they sourcing computational power from home/office PC's? This seems entirely unclear based on the reactions of this thread and the mostly ambiguous stuff written on their website.
If they are sourcing computational power SETI@home style my question remains, and I encourage it to be upvoted and answered on such a technically competent site such as this. Marketing hype is cool, but I'm still an engineer when it comes to making choices.
Spot instances can be killed any time if your bid is too low. This will, of course, happen less often at Amazon, but the principle is the same. You must also be significantly more proactive about unreliable performance and poor security. But this may be worth it sometimes.
> At this point I'm somewhat unsure of their actual business model. Are they reselling VPS instances from real providers or are they sourcing computational power from home/office PC's?
They’re computational power scavengers :) Seems to be desktop PCs for now. Maybe in the future it would also make sense to also utilise smartphones plugged into a charger? I hope they will be successful, because unreliable and cheap computational power is a pretty cool resource, despite all of its shortcomings.
Network proxying While we allow Internet traffic from software doing compuations on our platform,
Should be 'computations'.
I would imagine that I would have to reinstall my tools whenever a new instance starts.
You can stop a running instance by shutting down the OS. If it's something people really want we can add an API/UI mechanism to do it.
Looks like a pretty sweet service though.
Edit: I just checked the ip 107.20.186.94, and it does look like it's hosted on Amazon.
They will get more people doing it to be part of a community if they can keep that community seeming "cool" in some way.