Google Reveals Its Cloud Computing Vision

http://www.51zero.com/blog/google-reveals-its-cloud-computing-vision

by 51zero • 10 years ago

70 30 10 years ago

kinai• 10 years ago

NoOps...how about no?

vicpara• 10 years ago

Google App Engine is rubbish compared to most of other PaaS or SaaS providers. Rubbish because of the unreliable infrastructure (instances that get quickly out of sync), slow reads and writes, memory footprint your instances are allowed to have so that Google scales better and their API usability.

I really doubt they will be able to come up with something meaningful.

matt40772• 10 years ago

I'm not orchestrating a 1000k-node cluster, but for my needs, the google cloud has been excellent. It seems they are doing something right if they're attracting Linode/DO customers like me and AWS customers at the same time.

From the benchmarks I've seen, their computing instances also over much better perfomance/$ than AWS, especially in IO.

(But I have no experience with app engine so we could both be right)

tyingq2• 10 years ago

AppEngine is a somewhat clunky experience because of the walled garden nature it presents. For example, you can't write to a local filesystem in the way that you normally would, no listen sockets, etc.

And, while I don't have as drastic an opinion as others, there are operational issues. The most recent one was mysteriously disappearing outbound emails. These are worse than they should be, because there's no real way to escalate and get someone's attention, even if you're willing to pay for it. The support model is not the same as for the newer Cloud services.

astazangasta• 10 years ago

I'm not orchestrating a 1000k-node cluster

Is this right? Do you really mean 1 million nodes? Even if only 1000 nodes, who are the people using the high end of computing power, and for what?

crb• 10 years ago

I work on Google Cloud Platform, and I don't see any of the things you mentioned about App Engine. If you want a larger memory footprint, I suggest you look at the Flexible Environment (formerly Managed VMs), which lets you use any size VM you like.

We also have new Cloud Platform client libraries for many languages - start at https://cloud.google.com/docs/ for Go, PHP, Java, Python, .NET, Ruby and Javascript (Node.js)

App Engine hasn't stood still. I'd encourage you to take another look.

babo• 10 years ago

Could you share some fact with us?

mooreds2• 10 years ago

A bit breathless for my taste.

People have been trying to get rid of developers since COBOL was invented. The issue isn't that development is hard (though it is), it's that you have to translate human, squishy requirements that have unconsidered edge cases to machine considerations which have no room for ambiguity.

That's what a good developer does, and that's what machine learning/serverless architectures/4gl/COBOL can't do.

igravious2• 10 years ago

Agree with you on the article but have to part ways with you from there.

The issue isn't that development is hard (though it is), it's that you have to translate human, squishy requirements that have unconsidered edge cases to machine considerations which have no room for ambiguity.

This is a tired old meme. And I didn't believe it when it was a young whipper-snapper neither.

Define 'squishy'. You can't, can you?

What is it about information machines (as opposed to humans) that make them unable to handle ambiguity?

Why can't a machine handle ambiguous input? It could defer to the operator, did you mean this? did you mean that? It could randomly choose from a number of possible ways to continue. It could deal in probabilities rather than only 100% certainty (both true and false are epistemic locations of absolute certainty).

rorykoehler• 10 years ago

It could randomly choose from a number of possible ways to continue. It could deal in probabilities rather than only 100% certainty.

Essentially this is how humans operate already. How many times a day do you have minor but insignificant misunderstandings with people? Probably quite often, especially if you are in a foreign country and yet we all get along just fine.

arethuza• 10 years ago

"squishy" is about as good a word for most initial requirements as I have ever heard.

Turning squishy requirements into something specific enough to actually design a solution around is a pretty important step in any project.

coldtea• 10 years ago

Define 'squishy'. You can't, can you?

Is that supposed to be a counter-argument?

Because, that's the parent's whole point: that the same (they can't be defined or at least defined easily) holds for those "squishy human requirements".

What is it about information machines (as opposed to humans) that make them unable to handle ambiguity?

Obviously the fact that they only follow specific instructions at their lower level, and thus any ambiguity has to be explicitly translated to a non-ambiguous set of commands.

A fellow human does this translation automatically in their mind (and even they, not always perfectly).

Why can't a machine handle ambiguous input? It could defer to the operator, did you mean this? did you mean that? It could randomly choose from a number of possible ways to continue. It could deal in probabilities rather than only 100% certainty (both true and false are epistemic locations of absolute certainty).

Most of these sound recipes for disaster in any practical application...

And even that's besides the point, since all of these need to be programmed just as well as non ambiguous commands, but with more branching and special casing -- again explaining why handling ambiguity is hard.

Oh, and "randomly choose from a number of possible ways to continue" sounds like Clippy from hell...

mooreds2• 10 years ago

Thanks for the feedback. I find it generally interesting because most technical folks I've talked to have the same attitude I do. (Upvoted.)

What is it about information machines (as opposed to humans) that make them unable to handle ambiguity?

Of course, if designed for ambiguity, information machines can handle it.

But in my experience, solving a problem with software first involves defining the problem. Most problems are "squishy", in that they are ill defined. The end user has needs and knows those needs, but hasn't thought through all the ramifications of automation.

I've started a requirements process many a time with the question: "what do you want this to do", and then diving down to specify each behavior, including critical path functionality, error conditions, alternate paths, roles in the system, performance, timeframes, and other attributes. All of these are fundamental pieces of automating information flow, but aren't typically considered by a non technical person. Hence my use of the term "squishy". (I wrote a blog post in 2003 about how software crystallizes business processes: http://www.mooreds.com/wordpress/archives/46 )

And I don't know of any software process that can handle that. Even tools designed for non developers like Excel and Zapier force users to go through edge cases.

Finally, I'm certainly no expert on some of the new AI technologies that might be game changers. (I did enjoy reading The Master Algorithm, which talks about the schools of AI and some of the achievements.)

gherkin0• 10 years ago

Define 'squishy'. You can't, can you?

Underspecified.

Understanding, correctly, what an underspecified system should do is a strong AI problem (in most cases, at least). All (or nearly all) unbuilt systems are underspecified (as well as many built ones). We do not yet have strong AI. Hence, we have developers who will continue to collect paychecks for the foreseeable future (your "tired meme").

What is it about information machines (as opposed to humans) that make them unable to handle ambiguity? Why can't a machine handle ambiguous input?

Your focus on "ambiguous input" misleads you. The difficulty is more like ambiguous output.

niels_olson• 10 years ago

A bit breathless for my taste.

It seems like it's written for extremely rich grandmothers who go to board meetings for the dessert table.

They might be a little out of touch, but no too out of touch to vote, and their vote counts.

Honestly, if you're writing for people at the top, this is an enviable style of writing.

clebio• 10 years ago

Off-topic, I know, but what a stellar example of a sanitized, neutered corporate website. The picture of light bulbs on the About Us page.... bravo, you faceless, "elite" consulting company, bravo.

fauigerzigerk• 10 years ago

I don't get the pricing model of the leading cloud providers. Their data transfer pricing in particular makes zero sense. Running data intensive applications on Google's or Microsoft's or Amazon's cloud costs 10 times as much as running them on vultr or DO. I find that huge difference baffling.

tiffanyh• 10 years ago

+ vultr.com

I really wish more people knew about them. They are great.

kumarm• 10 years ago

We are looking for alternatives to S3 (for static hosting) since price of data transfer is way too high in all 3 leading cloud services. Any suggestions?

teh• 10 years ago

https://www.backblaze.com/b2/cloud-storage-pricing.html is a bit cheaper but you'll still pay $50 / terabyte. Using DO just for data might work but then you can't run fast computations on your data.

ddorian43• 10 years ago

https://www.ovh.ie/cloud/storage/object-storage.xml

vidarh• 10 years ago

Depends very much on your requirements. If this is data that is rarely changing, and that you have complete copies of, that is exactly what S3 is not good for. In that case: Any dedicated host that's cheap and with reasonable latency (or put a CDN in front). Two copies for failover/ha if you need it.

If you pay more than 20% of the advertised rates of AWS bandwidth, you're being robbed. 10% or less is doable.

If you need durability guarantees, consider if the cost problem is storage or bandwidth. If the problem is bandwidth costs (in other words: your data set is small and accessed often), store at S3 or Backblazer or similar, and place a server or two at a cheap bandwidth host with Nginx and aggressive caching policies.

I've done this for a couple of customers who did not trust other data storage options with their data, and you can rent a server + multiple TB of transfer for a fraction of a the cost of 1TB transfer from S3....

kefka• 10 years ago

Yes.

Look into IPFS, interplanetary file system. You still need machines to serve files. However, the system has some definite advantages:

    1. A file/directory is referred to its immutable hash.
    2. A request for a specific hash is made to the network, not a single machine.
    3. All machines that have that hash can swarm-download, like bittorrent
    4. All communication is point-to-point encrypted
    5. For backend, you can mount IPFS directly to the file system, via /ipfs and /ipns

The gist behind this is allows you to create a backend CDN of whoever is cheapest right now, and then load the images on your webpages (as gateways). It's still alpha, but so far my stability (and others running it) have shown that this system can easily handle large archives (800GB and up).

sudo-i• 10 years ago

I have a vision of ending up with a long legged Swedish blonde model, doesn't mean it will happen though...

outside1234• 10 years ago

What a joke - if this is what Google's vision is for the cloud then it is clear they have no idea who their customers are and what they want (hint: Enterprises)

tyingq2• 10 years ago

>“Instead of programming a computer you teach it what it [Google’s cloud] wants to know and it learns to give you what you want,” explained Eric Schmidt, software engineer and executive chairman of Google's Alphabet, Inc.

Skeptical on this. To date, nothing has even emerged that would allow non-technical people to create the basic CRUD apps that we create over and over. Quickbase/Filemaker/etc are somewhat close, as was the now-dead DabbleDB, ...but, most of the people using those were developers :)

If nobody has solved this, it seems a pretty big reach to say Google is going to produce something an order of magnitude more complex.

Google Reveals Its Cloud Computing Vision

Related Stories