What I tell people about hobby projects is that I tend to do them only if I'm not getting my software ya-yas out at work. Keep me busy with interesting work and almost 100% of my development energy will be yours.

That said, I do write a bit of software outside of work even when work is good. Those cases are the little things that pop up when I have a need I can't easily find something to satisfy.

Which is, amusingly, exactly Tesla's business plan.

Google isn't bound by the Constitution.

Hee hee. I worked for Jack in the early 1980s when he had a teeny little company called Softaid. He had a very down-to-earth take on things, and I suppose that extended to today, he'd advocate picking the tools that make sense. The zealots seem to be the ones that adopt things blindly and hope they'll work, all while declaring those who don't adhere to the "one, true way" as apostates.

'Cept that the order is "worldwide."

Google can comply, but if I put a copy of it up on my web server in the U.S. and refuse to remove it, how are the courts in Ireland going to force me to take them down if I have no interests there?

When you sign up for a Facebook account, you enter into a legally-binding contract that says you'll abide by the terms of service. The terms of service say you won't allow others access. Washington would, essentially, be making it legal for employers to ask employees to breach a contract with a third party, putting themselves at risk of being sued.

Thanks, I'll pass.

Me? I don't figure anything. I do a cost-benefit analysis for the situation at hand. Then I use the results to make a decision about which way would be better for my business. There's a term for a CBA that doesn't take the potential for outages and the time to resolve them into account: "incomplete."

I can think of a half-dozen situations where it might be a better thing to put your business systems out in "the cloud" and another half-dozen where it would be better to keep them in-house. Being able to argue both sides of the argument is usually a good qualifier for participating in a debate.

If you think for a minute the same situation doesn't crop up when your systems are in-house and your IT staff is trying like mad to figure out the problem, please think again. Your seven-figure people will still be twiddling their thumbs. If you've outsourced to someone else and you didn't write the contract so it gives you the uptime you need and people to yell at when you don't get it, you failed.

Thanks, but people who use exclamation points in the middle of sentences and make a lot of generalizations probably need to keep their career advice to themselves. I've already put in scads of time doing critical systems in shops where downtime can be measured in dollars or lives, so I already have a good appreciation for what it costs when things don't work and how to avoid those situations.

These are all problems that can be solved. 30 years ago, nobody ever figured the Internet would be able to sustain things like phone calls and streaming video, but it happened.

Point is, don't dismiss it because it's not practical right now. Somebody has to think about these things.

And like anything else, it all depends on how a cost-benefit analysis falls out. People making these decisions without doing their homework first are... well... stoopid.

The last statement is absolutely true. In-house systems have outages, too. Sometimes the cost of outages is more than made up for by not having to run a room with a raised floor.

Neither. What I meant is that clouds need to be Tinkertoys that can be used to assemble services with no single point of failure. S3's Achilles heel is that it's all Amazon. If Amazon has a widespread failure or decide to stop doing business with you, your service is instantly, irrevocably dead in the water.

If you're able to spread your storage among multiple providers as S3 does among Amazon's own machinery, you're no longer at the mercy of one provider. Contract with P1, P2 and P3 to do your raw block storage. Contract with P4 and P5 to run the storage service against what you have stored at P1, P2 and P3. If P2 goes poof, you keep running, contract with P6 for new bulk storage, tell your storage services at P4 and P5 you have new space at P6 and it gets loaded up, same as Amazon would do if a machine holding your data fails. If P4 goes away, you fail over to P5 and contract with P7 to run your aggregation service.

I wrote a whole article about this topic a couple of years ago, including some discussion about what will have to happen for something like this to come to fruition. Not wanting to be a blog link ho, I didn't post it here.

Actually, the biggest mistake companies make is using the *same* data centers for its core business. If you're in bed with a single provider, then you break when they break. Until there's a standard way to provision and operate things across multiple providers, this is going to be a problem. What we need isn’t a lot of clouds providing services. We need services being provided by a lot of clouds.

More likely because a filler that isn't round will become damaged a lot quicker than one that is.

I'm sorry, but this is so incorrect that it isn't funny. The Internet was commercialized in 1995 when NSFNET was decommissioned. Since then, what you know as "The Internet" in the U.S. has been carried on private equipment and circuits. The exception is the U.S. government's own infrastructure, and they're just like any other ISP, carrying traffic for their own departments and agencies.